[RESOLVED] How to change state of window to modal ? (in another program)

Schmidt, thanks. It's working of course, but it's still a timer. Your version is theoretically more safely, because I can potentially get exception after disabling whole form if code will try to access controls on that form.
Guys, don't quarrel.
I regret that I touched on the topic, where you have terminological misunderstandings by each other, not in general.
I any case, I'll beter go read book.
Thanks to anyone who came to my thread.

OK, I see a lot has happened since my last post, so I'll try to respond to most of the points made as concisely as I can.



Let's start with the basics. Owned windows comes in two flavors: modeless and modal. A modeless window does not disable its owner. A modal window, OTOH, does.

Now, let's talk about modality. As stated by Raymond Chen, it also comes in two kinds: UI-modality and code-modality. According to him, UI-modality happens when an owned window disables its owner. The user isn't able to interact with the owner window until the owned window is dismissed. The owned window here is considered modal in the UI sense.

Code-modality, OTOH, is encountered whenever a nested message loop is entered (in VB6, the most commonly seen example of this is a busy loop with DoEvents). The modal code defers execution of subsequent code until the loop is exited but, depending on how the loop was written, it typically does not prevent code in other event handlers from running. Any kind of window, even child windows, can have modal code in them.

When people talk about modal windows, they usually mean an owned window that disabled its owner and has its own nested message loop. In other words, an owned window that is both UI-modal and code-modal. This definition is very similar to Niya's except for one detail: the owned window doesn't disable all of the windows up its chain of owner windows, only the immediate one.

I believe that this is actually the standard behavior in Windows. In VB6, modal Forms disables not only their owner and chain of owners but also all other top-level Forms as well. AFAIK, this intuitive behavior is unique to VB6; most other programs written in other languages only disables the immediate owner of the owned window. They don't bother disabling other modeless or even other modal windows. Notepad.exe is one such unsophisticated program when it comes to modal windows. Try this: open Notepad, type something, press Ctrl+F to bring up the modeless Find dialog. Now click the Help|About Notepad menu. This displays a modal window. However, try clicking the Find dialog. Surprisingly, for VB6ers at least, it can be activated. What's more, when trying to click Notepad itself, the modeless Find dialog now acts as though it is modal. Notepad++ and IrfanView are two more examples of this kind of standard behavior.

Alright, it is true that there is technically nothing that keeps an unowned window from becoming UI-modal to another. However, in order to replicate an owned window's behavior, a nontrivial amount of work must be done to flawlessly duplicate the real thing. See MSDN's description in Owned Windows to get an idea of the tasks required. Virtually nobody is foolish enough to go through this route though because the natural thing to do when a modal window is needed is to simply create an owned window and let the system do the heavy lifting.

Eduardo, you kept asking about the convention regarding modal windows. Well, if you have only read the link in my last post, you would have found this:

Quote:

---

Originally Posted by Raymond Chen

A modal window is an owned window whose owner window cannot be interacted with.

---

I probably don't need to remind you who Mr. Chen is, do I?


Hopefully, this now clears up any confusion regarding the difference, or should I say, similarity between modal and owned windows. If one is still unconvinced, I can only recommend reading a good reference material on this topic.



Dragokas, it took some effort to download the xTranslator program from that site (I was required to sign-in so I registered using a disposable email address) but at least it made it easier for me to devise a customized solution. FWIW, the attachment below contains a Standard DLL project that injects itself via hooking and then subclasses the xTranslator program in order to disable the main window when the modeless "Search and Edit" window is shown and re-enable it when hidden. The main appeal of this approach is that the code runs in-process instead of having 2 processes.

As demonstrated by Olaf, this is in fact the expected behavior when Alt+Tabbing back and forth between programs that have a modeless window. It can be quite frustrating indeed and I can understand why you'd want to "fix" it.

Quote:

---

Originally Posted by Victor Bravo VI

As demonstrated by Olaf, this is in fact the expected behavior when Alt+Tabbing back and forth between programs that have a modeless window.

---

Note that not each and every (owned) modeless Window-scenario behaves in that way (switching the focus back to the Parent of the ToolWindow).

Because, if the owned modeless Window has the "ShowInTaskBar-Attribute", the behaviour would be as desired here;
(the ToolWindow "on top" getting the Focus in a back-switch, without any intervention from the outside).

That could be a hint, to solve the problem in "yet another way" (one, so far not attempted yet).

Olaf

Good catch, Olaf! :thumb:

Thanks, Victor Bravo VI for the explanation.
And, interesting project.