LabVIEW 64-bit support for modules and toolkits

[Matt_W1]

As it said on the download link for the windows API functionality.

[quote]

The abilities of the VI Server supersede the functionality of the VIs. National Instruments recommends that you use the VI Server functionality for new applications. Implement calls that the VI Server does not support through the Windows API directly by using a Call Library Function node in a more recent version of LabVIEW.

[/quote]

I think all of those could be implemented with VI references.

Minimize and Restore can be done with the Front Panel Window.State property

Move Window can be done with Front Panel Window.Window Bounds property

The window stacking should be controllable by setting the Front Panel Window.Is Frontmost property for all the windows in the stack in order from bottom to top. Not a super great solution but I think it would be workable.

I haven't used LabVIEW 64bit yet but assuming it can call 64bit dlls, you should be able to change the windows api call nodes to use the 64 bit dlls. Note that you may need to adjust the call parameters.

[DonRoth]

For the latter solution, I am assuming I would have to recompile the DLLs for 64-bit using something like Visual Studio.  I will get with one of our computer scientists in the organization who has the right tools to do this, or if someone can recommend a simple, alternate 64-bit DLL compiler, I would be happy to know about it.   These VIs work great and I would like to stay with them if possible.  I have a number of other things that I have to address in this application that are not working properly in the 64-bit version - so the easier the solution right now, the better.

Thanks,

Don

[Jim_S]

Hello Don,

I agree on all counts. I believe the VI server is going to be the fastest way to get this up and running in your VI. If you are going to have a computer programmer create a dll for you, I would suggest to have them build a .NET assembly because industry is moving away from C++ dlls for Windows interface. From here you can access the .NET dlls with LabVIEW very easily. I wish you luck with this and feel free to post if you need anymore help with it.

[DonRoth]

Do you have any thoughts on using the property node (fp.state and fp.IsFrontmost) vs. invoke node (fp.open)?  It seems like using the invoke node gives you more flexibility because you can specify thru the 'activate' property which window to make active (which I may need to do).  Or it could be a combination of both are needed.

Don

[DonRoth]

Well I have run into my first problem.  I have a compiled .chm help file that is spawned from a user run-time menu in the application.  Using the WinUtil function "Make Window Always on Top" (and using the name specified for the title bar of the .chm file as input to this function), I can always make the help file show up on top of all of the other windows.  I cannot see how I can use the VI server property and invoke nodes to address a non-VI file.  I have tried a few things like using VI server to make sure all of the other open windows in the application are not "frontmost", but the Help file always shows up behind the application with the VI server function use strategy.

Let me know if you might have some suggestions using LabVIEW-only technology.

Thanks,

Don

[DonRoth]

Additionally, I use another related LabVIEW utility that I don't remember exactly where I found called the 'Child Window Handler.vi'.  This allows one to make one window stay inside of another window in your application, and again is critical for my application.  This one also uses call library function nodes that require a redo for 64-bit.

I do now believe that there are some essential utilities, such as these windows utilities, that although not supported by NI, would be great to be made available in 64-bit versions.

Sincerely,

Don

[Matt_W1]

I don't think the LabVIEW server vi can control non LabVIEW windows. I attached something that can set a window to top most in LV64 (it uses a mix of .net and a CLN). It looks for the process by name, you may need to find it another method. I barely tested it so it may have problems. For instance I'm not sure which parameters for the 64bit version of user32.dll should be quads, I know I have to set the window handles to quads.

I'm not sure what the "Child Window Handler.vi" does exactly. But would a sub panel work instead?

Fun Fact: In windows the 64bit dlls are in system32 and the 32bit ones are in SysWOW64.

[DonRoth]

Hi Matt -

Yes, that is what I am saying.  VI Server falls short in a number of areas.  Subpanels actually will not work in my application since the child window handler allows one to move the child window around within the parent window.  Subpanels will be static.

I'll take a look at your VI when I get LabVIEW 2010 installed.

Thanks,

Don

[Jim_S]

Hello Don,

The VI server is made for controlling VIs and objects in LabVIEW environment which can be seen in the capabilities of VI Server. This won't be able to control the chm file help so you will have to use .NET assemblies or dlls in the 64bit environment like Matt W described. I hope this example that Matt W created works and if you have any more problems with this, please feel free to post.