That's because they are different windows. Every VB top-level form (i.e. not MDIChildren) is actually owned1 by a toplevel, 0 x 0 pixel window to which all messages and events are initially sent, whose caption is the application title3.
>This has nothing to do with link name od the form?
Well possibly. FindWindow will work quite happily in locating VB forms. But it isn't very flexible. Given the search criteria of class name and window caption, it just finds the first matching window in the window list2. If your form's caption is the same as your app title, and you are only searching on window caption then there's no guarantee that you'll get the right handle back.
So you need to either
a) be more specific in the search. If you want a VB form (or MDI parent) set the class name to ThunderRT6FormDC (or ThunderRT6MDIForm) for compiled apps and ThunderFormDC (or ThunderMDIForm) for the IDE. Of course, if you have two VB apps running with forms with the same name, then you'll still have problems
b) ensure your form has a unique name
1. Having an owner is subtly different from having a parent, in that the owned windows can still be a top-level window (and thus be found by FindWindow). If it has a parent, then it can only be a child window.
2. A combination of EnumWindows and the function BobRodes mentioned, EnumChildWindows, will allow you to walk this window list (which is also visible in the Spy++ application from the Visual Studio Tools menu)
3. This window has a class of ThunderRT6Main at runtime, and ThunderMain in the IDE