Skip to main content

Doh! - figure out return values before coding for them

Many developers will tell you "Development is full of "aha" moments" - those moments when something clicks and everything falls into place. What they don't tell you is that there are also a few "doh" moments - moments where you see code (usually your old code from years back) and instantly see why it wasn't doing what it should have been doing in the first place.

So here's a recent "doh" moment in VFP.

I'm tracking some strange behavior issues in some CursorAdapter code and figure I can use the AfterRecordRefresh event to see if I did get a refresh or not.

I have a lot of my code wrapped in a TRY CATCH LOOP but I had a little piece of code outside of it that I wanted to trap why a record was not refreshed.

The AfterRecordRefresh event gets three parameters:
nRecords - The number of records to refresh (passed to the recordrefresh method)
nRecordOffset - The record offset passed
nRefreshed - the return value from the RecordRefresh method

So the code was...

IF nRefreshed = 0
    ** Log this so we can see why no records were refreshed
ENDIF

Anyone catch the "doh"?

(for one, the documentation is this case is incredibly convoluted to follow. The AfterRecordRefresh method gives you some basic description but essentially says "See RecordRefresh" - once a doc goes into "see this" mode, it can often get overlooked.)

If you refreshed one record, nRefreshed would be 1, right?
If it didn't succeed, it would be .....

The "doh" is that RecordRefresh returns zero if there were no records were refreshed and there were no errors. If there were errors, it returns -1. Now, that's what I wanted to track down with.

So the code was recording any time an update was done, even when there were no changes.

Who reads the docs anyways, right? RTFM!

Comments

Popular posts from this blog

Blogs and RSS come to Microsoft.com

MS has just introduced their portal and it's pretty comprehensive. Nothing quite like learning that some people use AIM instead of MSN messenger, or that there really may be a need for supporting 4 monitors ( Cyrus Complains ) However, it's really a great sign that MS is serious about supporting the blogging community which seems to have um, exploded in size in the past year. Blogs and RSS come to Microsoft.com

Elevating Project Specifications with Three Insightful ChatGPT Prompts

For developers and testers, ChatGPT, the freely accessible tool from OpenAI, is game-changing. If you want to learn a new programming language, ask for samples or have it convert your existing code. This can be done in Visual Studio Code (using GitHub CoPilot) or directly in the ChatGPT app or web site.  If you’re a tester, ChatGPT can write a test spec or actual test code (if you use Jest or Cypress) based on existing code, copied and pasted into the input area. But ChatGPT can be of huge value for analysts (whether system or business) who need to validate their needs. There’s often a disconnect between developers and analysts. Analysts complain that developers don’t build what they asked for or ask too many questions. Developers complain that analysts haven’t thought of obvious things. In these situations, ChatGPT can be a great intermediary. At its worst, it forces you to think about and then discount obvious issues. At best, it clarifies the needs into documented requirements. ...

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction...