Armin,

I just looked briefly at the possibilities of the _SCREEN poperties (in general being the same as those of a normal form), and I must say, there are some possibilities ...

Please note that I didn't take the time to workout the anomalies found immediately.
Here are some properties / suggestions involved :

Enabled.
When set .F., the form (_SCREEN) can't be made smaller by means of clicking the two squares in the upper right corner. However, once the form is in the status of being smaller, it can be maximized.

LockScreen.
When Set .T., and you activate your other task (with the modal form) after that, it can't be brought up again. This "solution" is not similar to .Visible=.F. because it would disappear from the taskbar at all (not tested).

Obviously you can disable the boxes in the upper right corner, and I think you can tell _SCREEN that it isn't allowed to resize it my means of the mouse.

For sure you must be able to SETALL the child-objects from _SCREEN to Enabled = .F. Thus, any control at it, won't work anymore. But beware, I have the feeling that you won't succeed in disabling the top bar menu system by this means, but ... that can be shut off (keeping it visible) by means of SET SYSMENU OFF. Also note that from off W2K the popping up of the choices will remain (under W2K they don'ty pop at all), like the IE example.

Most stupid suggestion (being a little over-creative) :
Have your modal forms at the size of the current _SCREEN, overlaying that completely (hmm, can the latter be done ?), having a background picture being an image of a nice looking _SCREEN. One thing : don't forget to grey the TitleBar (well ... have it equal to the chosen color of it at the higher level ...). Have the modal form within a container so you can position the "active area" as you like.

A stupid suggestion which probably won't work at all, and which shouldn't be done in a Citrix environment (too much CPU useage) :
Try to have MouseOver methods at _SCREEN "all over the place", and let them result in something that won't allow the due manipulation from the user.

Last stupid suggestion :
When you create a copy of the _SCREEN instance in the (appropriate) manner that it doesn't create a new Win-task, you could have this form as a Top Level Form, your modal form running in it. Possibly the user won't see the difference. This is just (my) theory. It needs a special class for all of your modal forms, just implying the copy and all, at instantiating the modal form.

In the end I think I would succeed on this by means of combining the parts above accordingly. But it really is not the way to go IMO.

Regards,
Peter

>Hi Peter,
>
>you're right. Displaying modal forms as children of a Top Level form (I think this is what you mean), the TL form is totally blocked. I didn't test that, since this isn't an option for the current app. I've already played around with TL forms a lot. They have advantages and disadvantages and I'm still not sure, what's the better way.
>
>Thanks very much,
>Armin
>
>
>>Hi Armin,
>>
>>The _SCREEN instance, for me, is just the other Win-task, and so you CAN make it active while your modal form is running in the other task. I am not 100 % sure of this, because I can only look at our own app(s) running, surely not showing _SCREEN at all. In fact, I had to explicitly get rid of it, which brought some anomalies. Difficult to test in the production environment as well, because the behaviour is slightly different there.
>>
>>But do you really need it ? Why build your app on (the virtual) top of _SCREEN ? So instead of _SCREEN as the basis, just have another form and have _SCREEN.Visible = .F. Now have all other forms "in" your new top-form. I wouldn't use a FormSet; too much weird stuff in there.
>>
>>You'd be missing the dropdowns (and further menu-possibilities) in the top-bar; just make your own class for that.
>>
>>But obviously it may be a hard thing to do with an up and running app.
>>
>>Regards,
>>Peter