move window by class name

[rolfk]

---

wiebe@CARYA wrote:
The user32.dll should be included when you build an application. It's a platform dll, so the user32.dll provided by MS should always used. The dll can differ from system to system.

---

I tink you wanted to say that the user32.dll should NOT be included in the application build. Every Windows installation comes with its own user32.dll or it wouldn't be able to startup any windows.
Including your own copy with an application has a number of possible problems such as that your version does not be compatible with the rest of the Windows installation as well as that calling your own copy of user32.dll does cause synchronization problems since user32.dll is a system DLL that gets not usually loaded into every process independantly but instead is loaded only once and mapped into each process that uses it. Having your own copy will cause all kinds of problems where internal pointers, lists and references get disconnected from the main ones that Windows needs to manage the entire desktop.
This is probably also the original problem since using a private copy of user32.dll will search its internal window list for windows with the specified class name but since that DLL was not used to create them it will find 0.
But to think you could get your own disconnected window management by this is also a misconception. Sooner or later your application will simply die with a protection fault error when doing this.

Rolf Kalbermatter

[Guig]

Ok, the property to use is "frontPanel.WindowsLimits".
Sorry...

[Wiebe@CARYA]

"rolfk" <x@no.email> wrote in message news:1147767015110-365603@exchange.ni.com...
Wiebe@CARYA wrote:The user32.dll should be
included when you build an application. It's a platform dll, so the
user32.dll provided by MS should always used. The dll can differ from
system to system.
I tink you wanted to say that the user32.dll
should NOT be included in the application build. Every Windows
installation comes with its own user32.dll or it wouldn't be able to
startup any windows.




Yes, I ment to say user32.dll should NOT be included... Sorry about that.


Regards,


Wiebe.



Including your own copy with an application has a number of possible
problems such as that your version does not be compatible with the rest
of the Windows installation as well as that calling your own copy of
user32.dll does cause synchronization problems since user32.dll is a
system DLL that gets not usually loaded into every process
independantly but instead is loaded only once and mapped into each
process that uses it. Having your own copy will cause all kinds of
problems where internal pointers, lists and references get disconnected
from the main ones that Windows needs to manage the entire desktop.
This is probably also the original problem since using a private copy
of user32.dll will search its internal window list for windows with the
specified class name but since that DLL was not used to create them it
will find 0.
But to think you could get your own disconnected window management by
this is also a misconception. Sooner or later your application will
simply die with a protection fault error when doing this.


Rolf Kalbermatter