Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Catch 22
Message
 
 
To
20/05/1999 15:19:06
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Title:
Miscellaneous
Thread ID:
00221090
Message ID:
00221130
Views:
18
Erik:

You might try sub-classing the RegistrySetting form into a modal In-Top Level and one a Top-Level. Then in your main program:

IF NeedToChangeReqistry
CREATEOBJECT(RegistrySettingTopLevel)
READ EVENTS
ENDIF

* Call the In-Top Level form within the Top-Level form
CREATEOBJECT(MyMainTopLevelForm)
READ EVENTS

Also, I don't believe you can set the ShowWindow property at runtime. The VFP docs claim that it is read only at runtime.

HTH,

--Paul


>I have a new situation that I am trying to put together a smooth strategy for.
>
>The application is a Top-level-form app. The app stores user settings in the registry. On app startup, these settings are retrieved from the registry. If any setting is missing or obsolete, the user is given a form that allows her to update the settings. The form is also callable from the top-level-form menu from the tools pad.
>
>The user settings form is currently called from a form method called from form init. If the user cancels out of the settings form, I return .F. from the main form's init.
>
>
>Problem: A form called from a TL form's init cannot be seen unless it is itself a top-level form. A top-level form cannot be modal, and therefore cannot return a result. I could set the form's showwindow property to 'In-Screen', and temporarily show the screen, but this seems kludgy.
>
>I am looking for a logical program flow that will get deal with my being forced to choose between "in-screen" and "In top-level form".
>
>Another issue I am dealing with is where to place the READ EVENTS in a situation like this.
>
>Anybody got any suggestions?
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform