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

[Dragokas]

Hi !

I want to add convenience to the window of another program for my own purpose.

Program is closed source (Delphi). It consist of 2 Windows:
- Basic window, that always takes focus and get input queue
- Foreground window (non-modal)

When Foreground window takes a focus I'm pressing Alt + Tab 2 times.
After that, Basic window takes a focus.
I need foreground window took focus instead. It's usual window with its handle.

How can I do that?
Somehow change Foreground to modal? Or EnableWindow API + Basic window to disable it temporarily?
Thanks.

[Eduardo-]

Hi !

I want to add convenience to the window of another program for my own purpose.

Program is closed source (Delphi). It consist of 2 Windows:
- Basic window, that always takes focus and get input queue
- Foreground window (non-modal)

When Foreground window takes a focus I'm pressing Alt + Tab 2 times.
After that, Basic window takes a focus.
I need foreground window took focus instead. It's usual window with its handle.

How can I do that?
Somehow change Foreground to modal? Or EnableWindow API + Basic window to disable it temporarily?
Thanks.

When a window is modal all other top windows are disabled.
You can use the EnableWindow API to disable the other windows, and you'll have to enable them again when the modal window is closed or hidden.

[Dragokas]

Hi, thanks. I already done that. But, it is not very convenient.
See: I need disable it, make my work, then enable it.
If only I could somehow make foreground window to be modal, I don't need any action to do after finishing my work, because main window will be activated automatically as soon as I close foreground (modal) window.

I don't very familiar with API related to windows, so I don't know is it possible at all.

[Eduardo-]

Hi, thanks. I already done that. But, it is not very convenient.
See: I need disable it, make my work, then enable it.
If only I could somehow make foreground window to be modal, I don't need any action to do after finishing my work, because main window will be activated automatically as soon as I close foreground (modal) window.

I don't very familiar with API related to windows, so I don't know is it possible at all.

AFAIK there is no Windows function to make a window modal, other than creating a Dialog Box, but that must be done before the window is displayed.

To re-enable the others windows when the "modal" window is closed, you'll have to:

1) Subclass that window
or
2) Test with a timer from your program for that window existence and visibility. The API's are: IsWindow and IsWindowVisible.

[Dragokas]

Maybe it can be done with SetWindowLong ?
https://www.codeproject.com/Articles...-position-at-r

[westconn1]

did you try setting the foreground window to topmost?

[Dragokas]

Yes, tried. Basic window still gets the focus on Alt + TAB regardless of TopMost state of daughter window.

I think I'll stay on non-very beautiful solution with EnableWindow + timer to track new daughter Window / basic window closing to do all the job. It is working for me fine.

Thanks for all.

[Eduardo-]

To better understand this issue I'll contribute with what I understand, and if someone knows better is welcomed to add the information that she/he knows:

The "modal" state of a window is not a property of the window itself but a way of how a window is displayed in relation to the others windows of the program.

To display a window modally it is needed to disable all the other top windows (in VB they are usually Forms), in order to have enabled only the modal window.
This is done when the window is shown, not after that.

VB has the option to show a Form modally, for that sake it has an optional parameter in the Show method.
It also shows modally the dialogs MsgBox and InputBox.

Windows has also a way to show windows modally, that is accomplished by making a Dialog Box.

I'm quite confident that VB must use the Dialog Box for InputBoxes and I can say I'm sure that it uses the MessageBox function for Msgboxes, and that must be an specialized Dialog Box.

But I don't know how VB shows a modal form, whether it uses the Dialog Box function of if it handles the enabled state of all the other forms by itself.

I don't know of any API, like ShowWindow, SetWindowPos or any other one that could show a window modally.

In conclussion: if you are going to show a Window modally, use the VB intrinsic .Show method (in the case the window is of your own program), or use the Dialog Box API (I never used it myself so far), or... disable all the other windows "by hand".
More, if the window is already shown, you don't have many choices, you need to disable all the other windows by yourself, that's anyway what Windows and VB do automatically when showing a dialog or a modal form.

And of course, the windows that were disabled mut be enabled again when the modal window is closed. Windows and VB do that automatically, but you need to do it by yourself.

Using a timer (checking perhaps every half a second or less) doesn't seem to me a bad idea, since you avoid messing with the window's messages of the foreign window.
When the window is no longer shown, then you enable again the windows that you previously disabled.
It is more or less what VB and Windows does automatically for you when something is shown modally anyway (of course they don't do it with a timer).

If someone comes with a better idea, I'll glad to read about it.

PS: showing a window as Top Most has nothing to do with modality but with the Z-Order.

[techgnome]

The "modal" state of a window is not a property of the window itself but a way of how a window is displayed in relation to the others windows of the program.

That's the way I undertstand it too...

To display a window modally it is needed to disable all the other top windows (in VB they are usually Forms), in order to have enabled only the modal window.
This is done when the window is shown, not after that.

Not "all the other top windows" ... but the ones in the ownership chain of the one being shown modally. Just because my VB app is showing a form modally doesn't affect anything Word is doing... or any other app. It's all about the ownership chain.

That said, I think the rest of your assesments are sound... the sound right to me. You can't make something modal that wasn't created modal in the first place.

In conclussion: if you are going to show a Window modally, use the VB intrinsic

I think this is the part that's confusing... if I'm reading it right, it's not the form in his app that he wants modal, but the form of another application... so that when he closes his form, it returns BACK to that form, which he then closes and returns focus once again to the original main app's form.

So... he's go App 1 (not his) showing Form 1 which then displays Form 2 ... he then activates App 2 (his app) does something, closes the form, Alt+Tab Alt+Tab to get back to App1.Form2 to continue work and closes App1.Form2 and returns to App1.Form1 .... what he wants is App1.Form1 opens App1.Form2, opens App2.Form1, closes App2.Form1 focus automatically goes back to App1.Form2 w/o any user intervention... closes App1.Form2 and returns to App1.Form1.... repeat ad nauseum.

-tg

[Dragokas]

techgnome, it's easier.
We have App2.Form1, and daugther: App2.Form2 (has focus). You are pressing Alt + Tab 2 times, and App2.Form1 gets a focus instead of App2.Form2. That's bad for me.
App2 - is delphi-based app.

[Eduardo-]

Not "all the other top windows" ... but the ones in the ownership chain of the one being shown modally. Just because my VB app is showing a form modally doesn't affect anything Word is doing... or any other app. It's all about the ownership chain.

Of course.
I thought it was implied that I was talking about the top windows of that program only.

I think this is the part that's confusing... if I'm reading it right, it's not the form in his app that he wants modal, but the form of another application...

In that paragraph I was traying to explain modality in general, not the particular case.
Yes, may be it was a bit confusing.

which he then closes and returns focus once again to the original main app's form

That part was missing from the suggested API's: she may also want to set the focus to the previously disabled window. SetActiveWindow could be useful.

[Victor Bravo VI]

Maybe it can be done with SetWindowLong ?

You might want to see this thread.

AFAIK there is no Windows function to make a window modal, other than creating a Dialog Box, but that must be done before the window is displayed.

Typically, a modal (a.k.a. owned) window is created by, not surprisingly, the CreateWindowEx function.

Owned Windows

An overlapped or pop-up window can be owned by another overlapped or pop-up window. Being owned places several constraints on a window.

• An owned window is always above its owner in the z-order.
• The system automatically destroys an owned window when its owner is destroyed.
• An owned window is hidden when its owner is minimized.

Only an overlapped or pop-up window can be an owner window; a child window cannot be an owner window. An application creates an owned window by specifying the owner's window handle as the hwndParent parameter of CreateWindowEx when it creates a window with the WS_OVERLAPPED or WS_POPUP style. The hwndParent parameter must identify an overlapped or pop-up window. If hwndParent identifies a child window, the system assigns ownership to the top-level parent window of the child window. After creating an owned window, an application cannot transfer ownership of the window to another window.

Dialog boxes and message boxes are owned windows by default. An application specifies the owner window when calling a function that creates a dialog box or message box.

An application can use the GetWindow function with the GW_OWNER flag to retrieve a handle to a window's owner.

Another possible way of making a window modal is by hooking its creation.

[Eduardo-]

Hello Victor,

Typically, a modal (a.k.a. owned)

Modal and Owned are different things.

In VB, to show a Form modally you do it in this way:

Form.Show vbModal ' vbModal = 1

But to show a form owned by another:

Form.Show, OwnerForm

An owned form has an special relationship with another single form, with the owner.
The owned form will stay always over the owner (in the Z order), but the owner remains enabled (as do all the other forms that are open at that time in the program).

A modal form has a relationship with all the forms that are open, because all the other forms will be disabled while the modal form is open.

[Victor Bravo VI]

Actually, a modal window is just one of two kinds of owned window. The other kind of owned window is, as you probably already know, a modeless window. You can verify that a window is owned by attempting to retrieve its owner via the GetWindow(hWnd, GW_OWNER) API. Raymond Chen's Modality articles - in particular, part 1 & part 2 - does a great job of explaining what the differences between modal and modeless windows are. When you have time, you might want to play with the attached test project below, which is based on his articles.

[Eduardo-]

What are you trying to show, specifically?

If you want to make any correction or addition, please be specific and clear to the point. Thanks.

[Victor Bravo VI]

What are you trying to show, specifically?

I thought I was very clear. I was trying to correct this misconception:

Modal and Owned are different things.

As I've stated, modal windows are owned windows, as are modeless windows.

[Eduardo-]

I thought I was very clear. I was trying to correct this misconception:



As I've stated, modal windows are owned windows, as are modeless windows.

What I said stays: modal means something, and owned means something else, they are not the same thing.

If what you are trying to say is that modal windows can be also owned, yes of course.
If what you are trying to say is that modal windows are always owned, may be, I don't know. But it isn't important for the question of this thread anyway.

[Victor Bravo VI]

What I said stays: modal means something, and owned means something else, they are not the same thing.

I think you need to specify what you mean exactly by "modal". Is it UI-modal, code-modal, both or something else? In VB6, modal Forms are both UI- and code-modal.

If what you are trying to say is that modal windows can be also owned, yes of course.
If what you are trying to say is that modal windows are always owned, may be, I don't know.

By convention, modal windows are always owned. Sure, you could mimic a modal window's behavior using an unowned top-level window, but why would you go to such lengths when there's a much easier way?

But it isn't important for the question of this thread anyway.

One possible solution to Dragokas' problem was given in the thread I've linked to in post #12 - SetWindowLong(hWnd, GWL_HWNDPARENT, hWndNewOwner). In addition to that, he will also need to take care of a few things.

BTW, in the course of writing the test project above, I've discovered that VB6 apparently uses the GWL_HWNDPARENT hack itself when setting the owner Form via the Show method.

[Eduardo-]

I think you need to specify what you mean exactly by "modal". Is it UI-modal, code-modal, both or something else?

You know we are talking about windows, not code.

In VB6, modal Forms are both UI- and code-modal.

Wrong again. Even when a modal form is shown, code in somewhere else can be executed, because of timers or other events.

By convention, modal windows are always owned

OK, let's read where is that convention (I'm not saying it's not that way).

Sure, you could mimic a modal window's behavior using an unowned top-level window, but why would you go to such lengths when there's a much easier way?

One possible solution to Dragokas' problem was given in the thread I've linked to in post #12 - SetWindowLong(hWnd, GWL_HWNDPARENT, hWndNewOwner). In addition to that, he will also need to take care of a few things.

BTW, in the course of writing the test project above, I've discovered that VB6 apparently uses the GWL_HWNDPARENT hack itself when setting the owner Form via the Show method.

Making a window owned is not enough to be modal. It isn't even a requirement from the behavior point of view. But of course it's better to assure that in no case the only enabled window could hide under disabled windows.

It makes sense, and that's exactly what I do in a custom ShowModal procedure that I have in a component: If there is an active window (usually a form), I make the modal form owned by that form.
The purpose of my ShowModal procedure is to allow non modal forms to be displayed (like a toolbar or something like that) after a modal form is shown, and then bypass the intrinsic limitation that VB/Windows have.

But what "easier way" are you talking about?
Making a window owned doesn't disable the owner window.
But I guess you already know that (or you should).

Are you trolling?

[Dragokas]

Victor Bravo VI

Private Declare Function GetWindow Lib "user32.dll" (ByVal hWnd As Long, ByVal uCmd As Long) As Long
Private Declare Function GetParent Lib "user32.dll" (ByVal hWnd As Long) As Long
Private Declare Function SetParent Lib "user32.dll" (ByVal hWndChild As Long, ByVal hWndNewParent As Long) As Long
Private Declare Function SetWindowLongW Lib "user32.dll" (ByVal hWnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long

Private Const ICC_STANDARD_CLASSES As Long = &H4000&
Private Const GW_OWNER As Long = 4
...

    Dim hWndEdit As Long
    Dim hWndMain As Long
    
    hWndMain = FindWindowByName(sMainWnd)
    hWndEdit = FindWindowByName(sEditWnd)
    
    Debug.Print "Main hwnd = " & "0x" & Hex(hWndMain)
    Debug.Print "Edit hwnd = " & "0x" & Hex(hWndEdit)
    
    Debug.Print "Edit parent = " & "0x" & Hex(GetParent(hWndEdit))
    Debug.Print "Edit owner = " & "0x" & Hex(GetWindow(hWndEdit, GW_OWNER))
    
    If 0 = SetParent(hWndEdit, hWndMain) Then
        Debug.Print "SetParent failed with error " & Err.LastDllError
        If 0 = SetWindowLongW(hWndEdit, GW_OWNER, hWndMain) Then Debug.Print "SetWindowLongW failed with error " & Err.LastDllError
    End If
    
    Debug.Print "After set parent"
    Debug.Print "Edit parent = " & "0x" & Hex(GetParent(hWndEdit))

Main hwnd = 0x1112E6
Edit hwnd = 0x8111C
Edit parent = 0x0
Edit owner = 0x1112E6
After set parent
Edit parent = 0x0

(confirmed with Spy++)

After SetParent API:
the child window has changed its position: now it can not be dragged beyond the boundaries of the client area of the base window,
BUT, it doesn't done the job. Pressing 2 times ALT + TAB sets the focus on basic window control, not on Edit window controls.

Also, I don't know why "Edit parent = 0x0" after SetParent succeeded.
But, I agree with Eduardo-, you can't make it as modal by manipulating these properties.

[Dragokas]

Here is a "problematic" program, if someone would like to train (xTranslator): https://www.nexusmods.com/skyrim/mods/29148/
and meat: download any mod, like this one: https://www.nexusmods.com/skyrim/mods/88449?tab=files

How to use:
File -> Load ESM; Double-Click on any line in listbox. You have 2 windows. Now, you must do something that prevent changing focus from edit window after pressing Alt+Tab 2 times.
Currently I done this by Disabling/Enabling basic window by special timer. Project with today's experiments is in attachment.

[Niya]

I get the impression that a few of you don't really get what a modal window is. Whether a window is modal or not has absolutely nothing to do with the window itself. It's done by the implementation surrounding that window's creation. There is no property you can just set to make a window modal. A window is made modal by spinning up another message loop and disabling the window's owner after it's creation. That's all there is to it. This also means there is no way to just make a window in another process modal. For that to even be possible, you would have to be able to inject executable code into the foreign process, specifically a message loop and you must get it to execute just after the window is created. Even if you could do this, a billion things would probably go wrong. It's better to write it off as something that can't be done.

However, it could be possible to get the foreign process' window to emulate modal behavior using some trick or hack. But I wouldn't know how to begin something like that.

[Eduardo-]

A window is made modal by spinning up another message loop and disabling the window's owner after it's creation. That's all there is to it.

It's not just disabling the owner.
It is quite obvious, if you want to see, that when showing a modal form (or an MsgBox) all the other forms get disabled, not just one.

[Niya]

It's not just disabling the owner.
It is quite obvious, if you want to see, that when showing a modal form (or an MsgBox) all the other forms get disabled, not just one.

No doubt.

techgnome even suggests that the entire owership chain gets disabled. While this might very well be true throughout all of Windows, it's really only a convention. You or I could implement a different convention if we wanted in our own applications. We could choose to disable all top level windows in the process or just the ones in the chain to which our modal window belongs. Hell, we don't even have to disable any window at all. The message loop alone would create modal behavior. The point is, modality is not a property inherent to the window. It is defined by convention.

[Eduardo-]

No doubt.

techgnome even suggests that the entire owership chain gets disabled. While this might very well be true throughout all of Windows, it's really only a convention. You or I could implement a different convention if we wanted in our own applications. We could choose to disable all top level windows in the process or just the ones in the chain to which our modal window belongs.

Yes, I've done one, as commented here:

that's exactly what I do in a custom ShowModal procedure that I have in a component: If there is an active window (usually a form), I make the modal form owned by that form.

The purpose of my ShowModal procedure is to allow non modal forms to be displayed (like a toolbar or something like that) after a modal form is shown, and then bypass the intrinsic limitation that VB/Windows have.

I'll post it in the Codebank as soon as I finish other things.

Hell, we don't even have to disable any window at all. The message loop alone would create modal behavior.

I have doubts about that: the other windows could be frozen if you don't allow them to be painted (and to process other messages).

The point is, modality is not a property inherent to the window.

Yes, that's what I've been saying all the time in this thread.

[Niya]

I have doubts about that: the other windows could be frozen if you don't allow them to be painted (and to process other messages).

lol....I probably should have emphasized in my post that the results wouldn't be pretty but it's still modal behavior.

Yes, that's what I've been saying all the time in this thread.

Yea I got that. I also got the impression your point wasn't being understood clearly and needed to be emphasized in a more straightforward manner.

[Eduardo-]

Yea I got that. I also got the impression your point wasn't being understood clearly and needed to be emphasized in a more straightforward manner.

Thank you!

[Schmidt]

Just skipped over this thread - and...

Niya: "The point is, modality is not a property inherent to the window."
---- Eduardo: "Yes, that's what I've been saying all the time in this thread."
---- ---- Niya: "I got that. I also got the impression your point wasn't being understood clearly..."
---- ---- ---- Eduardo: "Thank you!"

LOL.

Ok, now that everybody (especially Eduardo) seems happy and satisfied
(with the apparently agreed on result, that "modality can mean anything or nothing") -
how would one have to proceed from here onwards - in such a "Babel-like" setting?

Wouldn't it be advisable, to try to find "common, existing terms" first, which finally have (for all participants)
the same meaning (after some studying on the end of those who are not familiar with them).

For that it is usually helpful, to find references (links) of "prior usage" in the context of the problem
(here: hWnd-based Container-Handling on the MS-Windows-platform).
After everybody has studied those links, the ensuing discussion is far more likely,
to not to be as pointless as this one was so far.

Oh, wait - there was somebody who was already trying to do that (making efforts to define terms first,
to provide common ground for all participants) - but sadly that person was called "a Troll" and driven from this thread.

Sigh...

Dragokas' problem (as fas as I see it) is not really caused by the way, how the Parent-Child-hierarchy was set up
(and not solved by changing or manipulating these relation- or ownerships - also not by introducing ones own MessagePump in-between) ...

In my opinion, the (Delphi) Parent-Window "breaks" convention, by setting the focus to
its (apparently still enabled) self (from inside its WM_Activate-Message or something, whilst being "re-activated") -
then entirely missing, to delegate the activation (the focus) "up the chain" (to its current "TopLevel-Child" along the Owner-queue).

I don't know if that's a general problem with the Delphi-Form-Engine, or a handmade one by the App-Developers.
In either case, one will have to circumvent that faulty focusing-behaviour (and it seems that Dragokas has found
a solution, by manually disabling the Parent, so that its internal focusing-attempt had no effect on said Parent)


Olaf

[Eduardo-]

Just skipped over this thread - and...

Niya: "The point is, modality is not a property inherent to the window."
---- Eduardo: "Yes, that's what I've been saying all the time in this thread."
---- ---- Niya: "I got that. I also got the impression your point wasn't being understood clearly..."
---- ---- ---- Eduardo: "Thank you!"

LOL.

What makes you laugh Olaf, that we are agree?

Ok, now that everybody (especially Eduardo) seems happy and satisfied
(with the apparently agreed on result, that "modality can mean anything or nothing")

From were do you take that idea?
(and more considering that you said "Just skipped over this thread")

how would one have to proceed from here onwards - in such a "Babel-like" setting?

Wouldn't it be advisable, to try to find "common, existing terms" first, which finally have (for all participants)
the same meaning (after some studying on the end of those who are not familiar with them).

For that it is usually helpful, to find references (links) of "prior usage" in the context of the problem
(here: hWnd-based Container-Handling on the MS-Windows-platform).
After everybody has studied those links, the ensuing discussion is far more likely,
to not to be as pointless as this one was so far.

Oh, wait - there was somebody who was already trying to do that (making efforts to define terms first,
to provide common ground for all participants) - but sadly that person was called "a Troll" and driven from this thread.

He was qualified as troll because he was insisting in that "modal and owned" were synonymous (meaning the same thing). After evidence and explanation was showed (unnecessary, because anyone with a little knoledge would know that they are different things) he kept insisting with the same idea.

Isn't that trolling?

About providing links, I asked about a link (from MS or some autority) were I could read the convention of how a modal windows should work, but he didn't provide one. Do you have one? (official)

Sigh...

Dragokas' problem (as fas as I see it) is not really caused by the way, how the Parent-Child-hierarchy was set up
(and not solved by changing or manipulating these relation- or ownerships - also not by introducing ones own MessagePump in-between) ...

In my opinion, the (Delphi) Parent-Window "breaks" convention, by setting the focus to
its (apparently still enabled) self (from inside its WM_Activate-Message or something, whilst being "re-activated") -
then entirely missing, to delegate the activation (the focus) "up the chain" (to its current "TopLevel-Child" along the Owner-queue).

I don't know if that's a general problem with the Delphi-Form-Engine, or a handmade one by the App-Developers.
In either case, one will have to circumvent that faulty focusing-behaviour (and it seems that Dragokas has found
a solution, by manually disabling the Parent, so that its internal focusing-attempt had no effect on said Parent)


Olaf

Dragokas' problem was solved with my first two messages.
If you have another suggestion you are more than welcomed to show it, it is always good to have options.

Do you have anything good to add or are you also trolling Olaf?

[Schmidt]

He was qualified as troll because he was insisting in that "modal and owned" were synonymous (meaning the same thing).

I've just read it more slowly - but still cannot find, where he was suggesting that they were synonyms.
What he was trying to say (and which is to this point still not understood by you) is:

- a modeless Window (e.g. a ToolWindow) can have the Owner-Attribute set (to the Parent-hwnd it is attached to interactively and non-modally).
- a modal Window always (implicitely in most current Form-Engines) has the Owner-Attribute set to the Window that was active before

After evidence and explanation was showed (unnecessary, because anyone with a little knoledge would know that they are different things) he kept insisting with the same idea.
Isn't that trolling?

Sorry, couldn't find any "evidence" or "explanation" from you...

And I would be generally more careful, with throwing that "troll" attribute around Eduardo.
A troll (in my book) is someone who "understands only half of it" - and then stirs up the heat with off-topic remarks -
which is what you're currently doing.

About providing links, I asked about a link (from MS or some autority) were I could read the convention of how a modal windows should work, but he didn't provide one.

He did provide several - the best one is perhaps the one to the modality-series of Raymond Chen:
Here a repost: https://blogs.msdn.microsoft.com/old...g/tag/modality

Do you have anything good to add or are you also trolling Olaf?

And there you go again - your "spanish temper" in full bloom...

I guess I'm just sad, that the Hobbyists in this forum always seem to manage,
to drive the few Pros away, who still post valuable stuff here.

Olaf

[Niya]

Victor said this:-

As I've stated, modal windows are owned windows, as are modeless windows.

While true, it's inherently misleading. An innocent bystander reading that might form the opinion that a window being owned and modality have some kind of technical relationship when in fact they don't. Modal windows being owned windows is entirely defined by convention and common practice, not by any technical design which is what Eduardo was trying to clear up.

Maybe he did go a little overboard by calling him a troll but his point was still relevant.

[Schmidt]

While true, it's inherently misleading. An innocent bystander reading that might form the opinion that a window being owned and modality have some kind of technical relationship when in fact they don't.

In a certain sense, modal windows (in current implemenations on the Win-Platform) use the "Owned-Attribute",
because when this Attribute is set, the *system* (not you as a developer) is responsible, to always render the Windows with the Owner-Reference *on top* of the Owner (never behind it).
That's one of the necessities for modal-windows, which is already "fulfilled easily" by using that Attribute.

Olaf

[Eduardo-]

I've just read it more slowly - but still cannot find, where he was suggesting that they were synonyms.

Typically, a modal (a.k.a. owned)

a.k.a means "Also known as".
It is a pseudonym or an alias for the same thing.

Do you agree with it: "modal windows" is an alias to refer to "owned windows"?

What he was trying to say (and which is to this point still not understood by you) is:

- a modeless Window (e.g. a ToolWindow) can have the Owner-Attribute set (to the Parent-hwnd it is attached to interactively and non-modally).
- a modal Window always (implicitely in most current Form-Engines) has the Owner-Attribute set to the Window that was active before

I didn't criticized that.

Sorry, couldn't find any "evidence" or "explanation" from you...

Take some minutes and read again. I won't explain everything that I already said another time.

And I would be generally more careful, with throwing that "troll" attribute around Eduardo.
A troll (in my book) is someone who "understands only half of it" - and then stirs up the heat with off-topic remarks -

I don't know what book you have and who wrote it but there are dictionaries so the people has a commmon place to agree on the meaning of the words.
There are many types of troll, once I've read about them on Wikipedia.

In the acception I used it, means: someone that is not trying to help but trying to make other people to lose time.

You can read in that page and say what kind of troll is the one that keep insisting in something that he was already showed to be incorrect.

which is what you're currently doing.

No. We were already paceful here. You are the one that came with the intention to mock.

He did provide several - the best one is perhaps the one to the modality-series of Raymond Chen:
Here a repost: https://blogs.msdn.microsoft.com/old...g/tag/modality

He had posted that link before I asked for "the convention".
Do you have a link (official) to the convention?
Please, if you don't have it, just answer "no".

And there you go again - your "spanish temper" in full bloom...

You have no idea about me. Do you know where am I from? The only thing you know is that I speak Spanish. Do you know anything?
LOL.

I guess I'm just sad, that the Hobbyists in this forum always seem to manage, to drive the few Pros away, who still post valuable stuff here.

Olaf

???????????????????

[Niya]

In a certain sense, modal windows (in current implemenations on the Win-Platform) use the "Owned-Attribute",
because when this Attribute is set, the *system* (not you as a developer) is responsible, to always render the Windows with the Owner-Reference *on top* of the Owner (never behind it).
That's one of the necessities for modal-windows, which is already "fulfilled easily" by using that Attribute.

Olaf

True, but we still need to make people understand that window ownership is only a small part of how modality is implemented in Windows. People are very prone to believing that a modal dialog is a simple matter of just setting a property or combination of properties. I've seen people make this mistake a few times over the years.

[Schmidt]

... a modal (a.k.a. owned) window ...

a.k.a means "Also known as".
It is a pseudonym or an alias for the same thing.

Do you agree with it: "modal windows" is an alias to refer to "owned windows"?

Hmm, I can't see anything logically wrong with the sentence he wrote...

It's all about "knowing your hierarchies and Sub-Sets" I guess (which you apparently don't).

Because when you read the following sequence in a sentence:
"... an F1- (a.k.a. Race-) car ..."

You will certainly not flame the author for trolling.
The Set- SubSet-sequence in this case being:
[ [ [F1-cars] Race-cars ] cars ]

And back to the topic at hand, the set - sequence below is also a given (on the win-platform):
[ [ [modal-windows] owned-windows] windows ]

Now you come along and state explicitely:
"Modal (windows) and Owned (windows) are different things".

Which (switching back to the cars) is the same as saying:
"An F1-car and a Race-car are different things".

Whilst in a certain way both statements sound "somehow true" -
seen logic- and set-wise they are not really, because:
- An F1-car *is* a Race-car ... period.
- A modal-window *is* an owned-window ... (on the Win-platform).

Both points of view have their merit though because whilst an F1-car is certainly a race-car:
- not *all* Race-cars are F1-cars
- and not *all* owned Windows are modal ones
...but calling someone a troll for his "more formal understanding of logic or set-hierarchies" is just rude (and wrong).

And there you have already the difference between Pros and Hobbyists (since you asked about it).
<shrug>

I'll leave your other remarks without comments (they speak for themselves already).

Olaf

[Schmidt]

True, but we still need to make people understand that window ownership is only a small part of how modality is implemented in Windows. People are very prone to believing that a modal dialog is a simple matter of just setting a property or combination of properties. I've seen people make this mistake a few times over the years.

I don't disagree with that - but as we say here in germany:
"The tone makes the music" (or something along that line).

Olaf

[Eduardo-]

Hmm, I can't see anything logically wrong with the sentence he wrote...

It's all about "knowing your hierarchies and Sub-Sets" I guess (which you apparently don't).

Because when you read the following sequence in a sentence:
"... an F1- (a.k.a. Race-) car ..."

You will certainly not flame the author for trolling.
The Set- SubSet-sequence in this case being:
[ [ [F1-cars] Race-cars ] cars ]

And back to the topic at hand, the set - sequence below is also a given (on the win-platform):
[ [ [modal-windows] owned-windows] windows ]

Now you come along and state explicitely:
"Modal (windows) and Owned (windows) are different things".

Which (switching back to the cars) is the same as saying:
"An F1-car and a Race-car are different things".

Whilst in a certain way both statements sound "somehow true" -
seen logic- and set-wise they are not really, because:
- An F1-car *is* a Race-car ... period.
- A modal-window *is* an owned-window ... (on the Win-platform).

Both points of view have their merit though because whilst an F1-car is certainly a race-car:
- not *all* Race-cars are F1-cars
- and not *all* owned Windows are modal ones
...but calling someone a troll for his "more formal understanding of logic or set-hierarchies" is just rude (and wrong).

And there you have already the difference between Pros and Hobbyists (since you asked about it).
<shrug>

I'll leave your other remarks without comments (they speak for themselves already).

Olaf

If you read the message(s), we were talking about modal windows, he said "modal a.k.a. owned", and just started to make the whole conversation about owned windows, as if that were the requirement to solved the OP problem of modality.

To be owned is not a requirement, really, for the modality. It may be a good practice, even a convenion (I still would like to read were that convenion is).
The proof is that the OP solved the problem without making the window owned.

If you don't disable the other windows, you can make a window all the owned that you want, and it will never be modal.

PS: I see that you learned now what "a.k.a." means.
And no, modal windows are not "also known as owned windows".

[Niya]

Hmm, I can't see anything logically wrong with the sentence he wrote...

Actually, Eduardo is right on this one. Firstly just to make something clear, Victor knows what he is talking about. It's clear to me that he knows how modality works. Now if we were to assume everyone who reads this thread already knows all this, we wouldn't have all these problems. But the fact is that many will come to this thread without any knowledge of the inner workings of modality so I think we have to be more responsible when it comes to how we define things for all the world to read.

Now with regards to the expression "also known as", any English speaking person that reads this as one thing being synonymous with another. What you really want to express is a set based relationship and not one of absolute equality. Modal windows, by convention, are a subset of owned windows. The term "aka" would not carry that meaning. It would only tell the person reading that owned windows and modal windows are exactly the same thing which they are not.

The problem here is that Victor played it a bit fast and loose with the definition of a modal window which is why Eduardo felt compelled to correct him. Yes, he could have been a bit more diplomatic about it but I understand why he reacted at all.

I'll end this with what I think should be a technical definition of a modal window:-
A modal window is an owned window that's been given it's own message loop while also having it's owner and all owners in that chain of owners disabled.

That is as succinct a definition as I could muster that captures all the important technical elements of what a modal window is supposed to be in Windows and what they generally are in practice.

[Schmidt]

If you read the message(s), we were talking about modal windows, he said "modal a.k.a. owned",
and just started to make the whole conversation about owned windows, as if that were the requirement to solved the OP problem of modality.

What Dragokas was describing was already an "owned-window-scenario" (not a "modal one").
Concretely a Main-Window, which had an Edit-Window running (as a Tool-Window, the ToolWindow not showing in the TaskBar).

You can easily enough replicate that Delphi-setting by opening a VB6-Project with two Forms in it (Standard-Names Form1 and Form2 are sufficient).
After adding Form2 to the Project, make sure you make it a ToolWindow (Borderstyle = 4 or 5).

Now put the following code into Form1 (the Main-Window):

Option Explicit
 
Private Sub Form_Load()
  Caption = "Main-Window"
  Controls.Add("VB.TextBox", "TB").Visible = True
  Form2.Show , Me '<- show the Edit-Window as an "owned" ToolWindow
End Sub

And then the following into Form2 (our Edit-Window, which acts as the "owned ToolWindow"):

Option Explicit
 
Private Sub Form_Load()
  Caption = "Edit-Window"
  Controls.Add("VB.TextBox", "TB").Visible = True
  If Me.BorderStyle < 4 Then MsgBox "You didn't ensure Borderstyle 4 or 5 for the Edit-Window"
End Sub

Well, that was it already - now compile the Project to your Desktop for example - and start it from there.
You can try to switch per <Alt>-<Tab> back and forward - and what you will see, is exactly the effect Dragokas was describing
(the Edit-Window not brought into the ForeGround by back-switching to the little Application).

Ok - now let's solve the problem...

Open another (new and empty) VB6-Project and put the following into Form1:

Option Explicit
 
Private Declare Function GetWindow Lib "user32" (ByVal hwnd As Long, ByVal wCmd As Long) As Long

Private Declare Function GetForegroundWindow Lib "user32" () As Long
Private Declare Function SetForegroundWindow Lib "user32" (ByVal hwnd As Long) As Long
Private Declare Function GetWindowTextW Lib "user32" (ByVal hwnd As Long, ByVal lpString As Long, ByVal cch As Long) As Long

Private WithEvents Timer1 As VB.Timer

Private Sub Form_Load()
  Set Timer1 = Controls.Add("VB.Timer", "Timer1")
      Timer1.Interval = 100
End Sub
 
Private Sub Timer1_Timer()
  Dim hWndForeGround As Long, hWndTool As Long
      hWndForeGround = GetForegroundWindow
  If GetCaption(hWndForeGround) = "Main-Window" Then
      hWndTool = GetWindow(hWndForeGround, 6) '<- GW_ENABLEDPOPUP
      If hWndTool Then SetForegroundWindow hWndTool
  End If
End Sub

Function GetCaption(hWndAct As Long) As String
  Dim S As String: S = Space$(1024)
  GetCaption = Left$(S, GetWindowTextW(hWndAct, StrPtr(S), Len(S)))
End Function

After that, start this Project (directly from the IDE is sufficient, no need to compile) -
now try the Alt-Tab based back and forward-switching with the little "Delphi-Mockup"-application again.

So the solution above will work without any need to disable the Main-Window -
it's simple "Foreground-checking + Foreground-switchery to the ToolWindow which was needed,
to solve the problem (which is - as said - based not on a modal, but an "owned" scenario).

If you don't disable the other windows, you can make a window all the owned that you want, and it will never be modal.

The Window *was* already owned - and no - the problem was *not* solved by "making the ToolWindow a modal one" (no separate MessageLoop was entering the game).

And no, modal windows are not "also known as owned windows".

You are wrong of course, because:
"F1-cars are also known as Race-cars" (but I'm repeating myself - I've explained the whole thing already for you).


@Nyia

I'll end this with what I think should be a technical definition of a modal window:-
A modal window is an owned window that's been given it's own message loop while also having it's owner and all owners in that chain of owners disabled.

I'll sign that, but that was neither the scenario Dragokas was describing (which was a plain "owned one") -
nor was the solution accomplished my making the Edit-Window a modal one (by your own definition above).

Olaf

[Eduardo-]

No, F1 and race cars are not aliases of the same thing.

But think what you want Olaf.

If you are going to set the window as foreground, it doesn't need to be owned anyway.

And it wasn't about Dragokas's specific problem that was already solved by that time, it was about not misinformating people that can come reading this topic.
I think that the matter is already clear to anyone, so we can end this discussion.