Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Defensive programming...
Message
From
07/06/2002 08:29:42
 
 
To
06/06/2002 15:45:08
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00665394
Message ID:
00665883
Views:
25
That's fine and he can put that code where he likes as long as it works properly. As I mentioned, it was my understanding that the Init was the "proper" place to stop instantiation. The main issue for me here is to help him get his problem solved. :-)

Bill

>AFAIK they both work. I use one or the other depending on need. Sometimes I'll want the form not to be initialised depending on the status of some control or other on the form, and I need it to be initialised first. If so, I use the form's init to return .F., otherwise, I normally use the Load.
>
>Alan
>
>>>>Hi Chris,
>>>>
>>>>Since you want to check this stuff first thing ( i.e. in Load or BeforeOpenTables ), looks like you might want to do something like add a property to your base form class, something like "CancelFormLoad". Then in your procedures instead of returning a .T./.F. if your requirement fails, you can set the CancelFormLoad property to .T.. Then in the form Init, check this property like
>>>>IF THISFORM.CancelFormLoad
>>>>    RETURN .F.
>>>>ENDIF
>>>>Returning .F. from the Init will stop the form from instantiating. You might want to work with this but you get the idea here.
>>>>
>>>>Bill
>>>>
>>>
>>>You can return .F. from the Load event to prevent a form from being created.
>>
>>My understanding was that a return of .F. from the form Init was the proper way to accomplish this.
William A. Caton III
Software Engineer
MAXIMUS
Atlanta, Ga.
Previous
Reply
Map
View

Click here to load this message in the networking platform