Prevent Form2 show when i click on Form1...

It's hard to say in few line so this example is the best way to describe:

Step to reproduce the behavior :

Create a new vb6 project, create two form named form1 and form2. Double click on form1 and paste this code :

Code:

---

Const HWND_TOP = 0
Const HWND_TOPMOST = -1
Const HWND_NOTOPMOST = -2
Const SWP_NOMOVE = &H2
Const SWP_NOSIZE = &H1
Private Declare Function SetWindowPos Lib "user32" (ByVal hwnd As Long, ByVal hWndInsertAfter As Long, ByVal x As Long, ByVal Y As Long, ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long

Private Sub Form_Load()
Call SetWindowPos(Me.hwnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE Or SWP_NOSIZE)
Form2.Show
End Sub

---

Now press F5 to run the application, you will see both form show up.
Click on Form2 to make it have focus, then click on the vb6 ide to make the IDE have focus and form2 will disappear. Form1 still appear because it's have HWND_TOPMOST, now click on Form1 to make Form1 have focus. But when you click on Form1, Form2 suddenly show up, that is very annoy. This behavior not occur if you're using vb.net with the same code. So how to prevent form2 show up when i click back to form1 in this case?

Just a side note. I would not worry about the ZOrder in IDE. Does it produce the desired results when you compile the exe? That's what matters.

It's normal behavior

When you start project both Forms show because you have Form2.Show. When you click on any other app, like the IDE, Form2 goes behind the other app as expected because only Form1 has TOP_MOST. When you again click on Form1, Form2 will again appear because it is the child of Form1. Everything is normal

Quote:

---

Originally Posted by LaVolpe

Just a side note. I would not worry about the ZOrder in IDE. Does it produce the desired results when you compile the exe? That's what matters.

---

i've tried to compile exe but got the same result.

What do you mean you tried to compile exe?

It doesn't matter, exe or run in IDE you will get same results as far as the Forms showing.

Quote:

---

Originally Posted by jmsrickland

What do you mean you tried to compile exe?

---

I suggested that as I wasn't sure exactly what the OP was questioning about. We all know that what happens in IDE is not necessarily the same thing that happens when compiled. In this case, appears so

Quote:

---

Originally Posted by jmsrickland

When you again click on Form1, Form2 will again appear because it is the child of Form1.

---

Not exactly. Form2 is not a child of Form1. It is owned by a hidden VB window, same as Form1 is owned by that hidden window. When one clicks on an owned form, it will bring it's owner up in the Zorder too. Since owned windows cannot be lower in the Zorder than the owner, all the owned windows come up too. This is what appears to be happening.

If vietnamvodich wants these windows to be independent of each other, then they should be part of different applications. That may also be accomplished by making Form2 an owned window of the desktop via APIs. Maybe this example?

Quote:

---

Originally Posted by vietnamvodich

So how to prevent form2 show up when i click back to form1 in this case?

---

The reason for that behavior is because all top-level Forms in a VB6 process are owned by the unseen ThunderMain window. When one of your Forms becomes the foreground window, the rest are also brought near to the top of the z-order as a consequence of their owner window being activated.

To "disconnect" one or more of your Forms from each other, you need to turn them into "unowned" windows. This can be accomplished via the undocumented trick of changing the target window's GWL_HWNDPARENT to none:

Code:

---

Private Const GWL_HWNDPARENT As Long = (-8&)

Private Declare Function SetWindowLongW Lib "user32.dll" (ByVal hWnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long

Private Sub Form_Load()
    SetWindowLongW hWnd, GWL_HWNDPARENT, 0&
    SetWindowLongW Form2.hWnd, GWL_HWNDPARENT, 0&
    . . .

---

As an example, this could be done

Code:

---

Private Declare Function SetWindowLong Lib "user32.dll" Alias "SetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long
Private Const GWL_HWNDPARENT As Long = -8
Private Declare Function GetDesktopWindow Lib "user32.dll" () As Long

...
SetWindowLong Form2.hwnd, GWL_HWNDPARENT, GetDesktopWindow
Form2.Show
....

---

However, you are breaking VB in a way. When you close your app, Form2 will not be unloaded. You will have to unload it manually via Unload Form2

Edited: Bonnie beat me to it, but pay attention to the my final sentence above

I see where Bonnie has two SetWindowLong statements where LaVolpe only has one. Would this make a difference in the behavior of the two Forms

Quote:

---

Originally Posted by LaVolpe

... but pay attention to the my final sentence above

---

Quote:

---

Originally Posted by LaVolpe

However, you are breaking VB in a way. When you close your app, Form2 will not be unloaded. You will have to unload it manually via Unload Form2

---

I think there won't be any change in unloading behavior since Form2 wasn't owned by Form1 (or any other Form) anyway.

Quote:

---

Originally Posted by LaVolpe

Code:

---

SetWindowLong Form2.hwnd, GWL_HWNDPARENT, GetDesktopWindow

---

---

Most top-level windows aren't owned by any other window, but they are all children of the desktop window. A top-level window that is both a child and is owned by the desktop window is possible, although it is quite weird.

Quote:

---

Originally Posted by jmsrickland

I see where Bonnie has two SetWindowLong statements where LaVolpe only has one. Would this make a difference in the behavior of the two Forms

---

I was "disconnecting" Form1 and Form2 from ThunderMain, hence the 2 lines.

Bonnie, yep I was way off base with that unload statement -- senior moment likely

Wow, the code from Bonnie work perfectly. Now form1 and form2 are not "linked" anymore. Thank you Bonnie so much and thank Lavolpe and jmsrickland for having great effort to help me.