A Modal form called from another Modal form sometimes vanishes and not seen! 1

[Rajesh Karunakaran]

Dear Friends,

I have a Modal form. In this, I have a button which calls another Modal form (it's a client lookup feature). Once it's opened and the client record is located, user has to click Select button which closes (rather Releases) the 2nd form. Sometimes, the client reports that they cannot invoke the 2nd form by clicking the button in 1st form. When I inspect I see that it's gone somewhere and not seen. If I see the 'Windows' menu item (Vfp menu), I can see an entry for this form as active.

In fact, I am not expecting a Modal form to allow clicking anywhere outside of it. Or, to allow it to be dragged completely outside of the form which called it.

As I could not reproduce this scenario, I have not yet solved it.

Without going to any more details, any one has a preliminary clue/idea on this?

Thanks in advance,
Rajesh

 

[Mike Lewis]

I am not expecting a Modal form to allow clicking anywhere outside of it.

That's almost true. In fact, It does allow clicking on a toolbar or a menu bar, since technically these never receive focus. Is that likely to be relevant here?

Or, to allow it to be dragged completely outside of the form which called it.

No, that's not true. Are you perhaps thinking of ShowWindow = 1?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Dear Mike,

Is that likely to be relevant here?

Yes, I did reproduce the scenario. The menu is active and when 'Cascade' option is clicked, I got the same scenario. I would turn off the main Vfp menu option also because the main form is in a run and quit (vfp) manner.

Rajesh

 

[Mike Lewis]

For what it's worth, I have code in my base modal form class to disable most of the controls on my toolbars while a modal form is active. This is to prevent users closing the modal form or opening other forms outside the modal form's control. The only controls I don't disable are for things like cut, copy and paste, and calling the Help system.

I used to do something similar with menus, but I no no longer have menus in my applications, given the trend towards ribbon-style interfaces.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Dear Mike,

Our application dynamically decides whether a full menu systems with various forms or a single form (just like a kiosk maybe) to be run as per the user login details.

In this particular case, its a single form run immediately after login and when this form is closed the application also quits. So, just before launching the form, I disable the menu and enabled it back after the launching command. This enabling, is in fact not required as the application also will quit, but just wanted to keep the enviro un-disturbed to support future modifications, if any.

Anyway, the problem appears solved. Thanks.

Rajesh

 

[Chris Miller]

Anyway, the problem appears solved.

I see, but did you find out what it was?

the first thing i would say is thaat top level forms are not modal, even if you set them modal. So that's a reason just a DO FORM of them still immediately retrns to the caller and then the form vanishes, as the calling code continues. You can "stack" modal form on modal forms and make the latest modal form the currently focused form that has the core modal behavior, but you can't make any top level form modal.

Forms need to be child forms, but it's also not true that they must be enclosed within the parent form, they can also be desktop=.t. forms and are freely movable. It's not impossible they are out of sight, also when inside and thus clipped by the parent form. They can have a position outside that form and outside of the desktop.

But you can easily see, whether you get a direct return after starting the modal form and then know it didn't succeed to become modal, if you set a breakpoint right after starting the modal form and see, whether that really only suspends program execution after you close the modal form or comes up right after the modal form starts. Because that's the major difference between modal and non-modal from the programming perspective.

Non--modal forms should be preferred as they allow users to change freely. If you absolutely want to enforce the user into only using that form until what you need from him is done, then modal forms are absolutely fine, but the usual ase is not just a single path of workflow that you force users to go through, just like Windows itself does not have just one active application and you can switch between what you need without first ending what you currently work on. And that was the major motivation for Windows vs DOS systems, to not just have one active screen and the ability to fast switch between applications. Your application windwos should ideally mimmic that and each be services to the user he can and want to switch between. Anything that's more complex and needs single steps to go thorough can also be solved by putting it into a pagerame and controlling the tabs programmatically instead of allowing manual change between tabs.

Chriss

 

[Rajesh Karunakaran]

Dear Chriss,

I understand what you're explaining.

I see, but did you find out what it was?

Yes, I was able to reproduce the exact scenario.

Also, in this particular user activity, the user is not supposed to run any other screen/modules (which the application otherwise has). The 1st form runs on a touch screen. After desired work, when the user exits from the form and then the application also is closed.

However, the default Vfp menu was left activated. Clicking on the menu (by mistake) was creating the above problem. In fact, the menu is not required. So, we disabled it.

Rajesh

 

[Chris Miller]

You mean if two modal forms are started - the second started by the first - which works as it should in itself, but the VFP system menu also is active, the current modal form breaks away? How?
I mean, sure, if a user picks Window->Hide, he hides a form, but the menu in itself does nothing to the forms started. The menu can be used, while the current form is modal, that's also true, but well known.

Anyway, you solved whatever detail issue by not having the menu and simply close instead, if I understand it. i would have liked to know a corner case, perhaps a new case, of how modal forms fail to work modally, but then I think this wasn't actually an interesting new case, just whatever was done with the menu that should not have existed at that moment anyway.

Chriss