[RESOLVED] Why form still visible when 'unload'

[Urgentbody]

Hi every one there,

Private Sub Command1_Click()
If Text2.Text = IDS(0) Then

    Main.Show vbModal
    Unload Form1
End If

End Sub

The form is unloaded but still visible behind Main Form Why?
Where as in some cases i found when unloaded a form its closed.

[LaVolpe]

The Unload statement is not executed until the modal form is closed or hidden. Remove the vbModal part and Form1 should unload after Main is shown.

[Urgentbody]

Thank you Lav....
Your reply solved the problem....
Can i get some extra knowledge .. Why that one not happening earlier... what is the role of vbModal / vbModeless.

Thank you again..

[SamOscarBrown]

F1 or, look for vbModal in Help

[LaVolpe]

In my signature is a link to VB help files online. You may want to bookmark that link.

Using that link, if you navigated to: Methods > S > Show > Show Method, you would find this on that page

When Show displays a modeless form, subsequent code is executed as it's encountered. When Show displays a modal form, no subsequent code is executed until the form is hidden or unloaded.

[Elroy]

Modal forms actually can be a bit of a mystery at times. However, I suspect many of those mysteries are beyond what Urgentbody is asking.

To fully appreciate them, we must recognize that showing a form as modal involves both Code consideration as well as UI consideration. As we know, when we show a form modally, whatever code did that is suspended at that line of code until that modal form is made non-modal in some way (unloaded, shown non-modally, hidden), at which point the original code will continue to execute once the thread is handed back to Windows.

Why do I talk about the thread? Well, because, we might hide our modal form, do some operations, and then re-show it as modal while not releasing the thread. This would keep the original code (that showed the modal form) suspended. And, as a further note, this is one place where DoEvents can cause havoc. For instance, if you have a form loaded modally, it temporarily hides itself, executes some DoEvents, and then re-loads itself modally, you will get bizarre results (with the code loading the modal form continuing to execute in some cases).

Another thing to appreciate about modal forms is that, you can unload (but not hide) their parents (forms lower in the ZOrder) and you will also (somewhat automatically) unload these modal forms. Personally, I would consider this coding practice highly inadvisable. In fact, that seems to be precisely what Urgentbody is doing. I can set up test cases where bizarre things happen when you do this, especially if the "Parent" option is used when loading the modal form. In some cases, you can actually crash the IDE.

Now, if we try to hide (not unload) a form that's lower in the ZOrder when a modal form is showing, we get an error:


This is expected (at least by me). And it's probably the way unloading a form lower in the ZOrder should work, but doesn't.

Also, there's the issue of what events are still allowed to fire within the COM/Code object of forms lower in the ZOrder when a modal form is showing. And there seem to be inconsistencies here between the IDE and compiled. For the most part, all keyboard and mouse related events are prohibited. However, other non-mouse/non-keyboard events are often still allowed to fire.

And, if you directly call it (because it's declared as Friend or Public), you still have full access to the procedures in the COM/Code objects of forms lower in the ZOrder. You also have access to all these "lower" forms' controls if you directly access them. In other words, a modal form can easily change captions, lists, or whatever on some parent's form.

Also, it's a form's UI, and not its COM/Code piece, that defines it as modal (or not). However, again, this affects (suspends) upstream code execution.

Personally, because of these ... ummm ... confusions, I stay away from modal forms execept for MsgBox messages and my own MsgBox-type messages. However, this does mean that I must do an excellent job of managing my user-interface if/when multiple forms are showing. In most cases, I just hide parent forms such that only one form is showing at a time (but this isn't always practical). Also, this means that I must manage my code better because there won't be any code suspended anywhere.

Just some personal thoughts about this.

Best Regards,
Elroy

EDIT1: Just one last comment. I find it rather bizarre that some particular form's state (modal or not) can affect whether or not code can execute (i.e., because it's suspended because it loaded a modal form). It's almost like calling a function (where the caller is suspended until the function returns), but it's not. A modal form returns the thread to Windows the way any other form does, whereas a called function doesn't return the thread until it's completed its task.

[Urgentbody]

Thank you Elroy and LaVolpe for the information.

[tubus]

When Show displays a modeless form, subsequent code is executed as it's encountered. When Show displays a modal form, no subsequent code is executed until the form is hidden or unloaded.

... well, I think I understand that, but *why* a modal form is not automatically the topmost??

Now all too often I happen to open a modal form and it is hidden below an other one.
And all to often the Ctrl-Alt-Del is the only escape

[Elroy]

Say Tubus,

If possible, it'd be nice if you could pull together a small example of what you're talking about. I've seen what you describe happen when a form is manipulated with some API calls, but I'm not sure I've seen it happen under normal circumstances. Within a particular program/project, the last form to be loaded modally will/should be highest (most in front) in the ZOrder.

Now, let's not forget that there can be a hierarchy to modally loaded form. In other words, some code may load a modal form. And then, that form may load subsequent modal forms. Etcetera. That's why, above, I say the "last form" to be loaded modally.

Best Regards,
Elroy

EDIT1: Also, let's remember that each "instance" (i.e., program) is going to have its own ZOrder list. In other words, another application can still place windows over your program's modal windows (unless you make an API call to make them always-on-top, and even then, the always-on-top list still has its own ZOrder list to keep track of all the always-on-top forms).

[tubus]

I've seen what you describe happen when a form is manipulated with some API calls, but I'm not sure I've seen it happen under normal circumstances.

Thanks Elroy for your answer

...well yes, I do manipulate the Z-order with the respective API calls, I need that to display sort of monitoring or toolbox windows above the main windows.

To be fair, it's not a problem in the compiled exe, I've learned to handle this, but often frustrating in the IDE. An unexspected error message popping up, but hidden behind a topmost-by-API window, then you are locked. No way to bring it back to the front or move focus back to it.

I would think, if Windows restricts User-input to a certain window, it should bring it to the top. Period.

[passel]

If you're in the IDE, I would think you could hit Ctrl-Break to pause the executing program and in the immediate window use the move method of the form in question (or use it's left and top properties) to move it to where you can see it.