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

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!