Renaming the buttons of MessageBoxW with SetDigItemTextW (user32.dll)

[J-M]

I have some problems with SetDigItemTextW.  When I just load the VI "MAIN-TEST Unicode MessageBoxW.vi" It takes a delay of 300 to 400 msec (not always but often) before being able to rename the buttons with SetDigItemTextW.  When I run this VI for a second time, I don't have this delay. If I close the Vi et re-open it, I still have this delay.


What I do is:
1) Start dynamically MessageBoxW
2) Obtain Window handle of  MessageBoxW
3) Rename the buttons of MessageBoxW with SetDigItemW


I just try to understand what is causing this delay.  Any idea?

[Jorr-El]

Hi Jean-Marc,

I think what is happening is that LabVIEW is dynamically loading your DLLs and sub-VIs when you first open and run your VI. Because LabVIEW is loading the DLL into memory, and has to load several copies of your DLL into memory because of the for loop, there is a delay the first time.

When you run it a second time, LabVIEW still has the DLLs loaded into memory, so you don't see the delay. When you close the VI, the DLLs are unloaded from memory, which then causes you to have the delay again when you re-open and rerun the VI.

[J-M]

Thanks for the informations.   Fortunately, It seems that this behavior don't appears with an executable.

[rolfk]

Change the "library name or path" for your GetForegroundWindow(), FindWindowW(), and SetDlgItemTextW() functions from "Windows\System\user32.dll" to just "user32.dll" only!

That should help and also avoid the application builder to include user32.dll into your build directory. Distributing that DLL with your application is both a technical and legal nogo!

Without a full path, LabVIEW simply calls the Windows API LoadLibrary() which will immediately recognize that it is an already loaded system library and return with a reference to the open library. With a full path LabVIEW will first attempt to load the library explicitedly from that location, getting likely errors and having to retry in the end with just the name alone anyhow.

[J-M]

When I made an executable (with the full path of user32.dll) and run it, I received this error.

This was solved by using only user32.dll instead of C:\Windows\System32\user32.dll

[rolfk]

Of course, that was the other part that I mentioned. With a full path the Application Builder assumes that the DLL is a private copy for the application and copies it into the "data" directory, or whatever is the name that you set the support directory to. Your application then tries to load that private copy instead of the system version and all hell breaks loose, since the system DLL are responsible for managing just about anything in Windows including the opened windows, files, etc. The two copies of the system DLL now loaded into your process (the correct user32.dll already got loaded way in the beginning of process instantiation long before your LabVIEW has a chance to try to attempt to load the private copy) clash because one receives handles that refer to objects managed by the other one and BUMMMMMMM!

That is one of the technical reason why you can't redistribute a system DLL, not even to your own PC. Another is that even slightest version differences could mean that the interfaces to the lower level kernel services which are almost all private and undocumented won't match. Legally Microsoft also doesn't give you any rights to distribute these DLLs in any way.