yeah - but I can handle problems with error handling/codes and then determine what I want to do. For example, with my local table apps, If The server dies for instance, and I can't get data, I can show a friendly notification telling that the data is unavailable in lieu of bringing up the form - which wouldn't work any way.

with a 'net' connection (remember Rick, most of us aren't doing this yet!) I might approach it differently.

Ken


>Ok. I seem to remember testing this when I was writing the RDS code and
>I don't remember offhand why or how this didn't work. I guess it shows I
>don't do much UI programming these days <s>...
>
>It doesn't really help the cause though. If the RDS query fails I really
>wouldn't want to not show the form since a no data returned thing may
>be a very common scenario with the 'net connection.
>
>+++ Rick ---
>
>
>>Rick,
>>
>>Returning .f. in load prevents form from instantiating. If it were not so, none of my (custom) DE stuff could kill the form if I had a data problem!
>>
>>Ken
>>
>>>>In Rick Strahl's white paper, he states that you cannot bind objects to RDS data because originally when you create the RDS object and build your cursor, the cursor can fail.
>>>>
>>>>You couldn't do this in the init, of course because the your form objects have already been initialized and the form would fail, being unable to bind the objects.
>>>>
>>>>He then goes on to say that you could place the code in the load but there is no easy way to abort the process if the cursor fails to load. This is the part I do not understand. If the cursor fails to load, why can't you just return a .F. in the load?
>>>
>>>Returning .F. from Load doesn't do anything... Returning .F. from Init will cause the object not be created, but Load doesn't check for result values (unless this has changed recently).