LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to run an exe as a window inside a VI

Thanks for getting back to me! Yeah the reason I need x64 is because we need be able to address around 64GB memory. To be honest since Lv2018 pretty much all tools from 32bit also work on x64, I don't really come across the issue at all. 

 

Would you have the source code for the dll so I could re-compile for 64bit? The problem is Lavbiew gives broken arrows even just trying to load the dll

 

0 Kudos
Message 31 of 39
(3,774 Views)

@jackwhelan wrote:

Hi Hooovahh,

 

Great demo project, its exactly what I need! The only problem is my LV application is x64 and the LVWUtil32.dll is 32 bit. Do you think you could provide an x64 version of the dll, or if it's too much trouble any advice how I could use this in an x64 application? 

 

Thanks in advance


The DLL is not the only problem. All handles have to be changed too. In LabVIEW they need to be made a U64 value, and the Call Library Nodes have to be configured as Pointer sized unsigned Integers. While I have a modified winutil.llb that entirely avoids the use of lvwutil32.dll by directly calling the according Windows APIs, the entire MultiPanel Example would need to be reworked too, including its own Windows API VIs that are specific to handling the child window handling. 

Rolf Kalbermatter
My Blog
0 Kudos
Message 32 of 39
(3,764 Views)

@jackwhelan wrote:

Thanks for getting back to me! Yeah the reason I need x64 is because we need be able to address around 64GB memory. To be honest since Lv2018 pretty much all tools from 32bit also work on x64, I don't really come across the issue at all. 

 

Would you have the source code for the dll so I could re-compile for 64bit? The problem is Lavbiew gives broken arrows even just trying to load the dll


It's totally not clear to me why your Get DLL Path.vi would call the lvwutil32.dll in any way as shown in your error dialog IMAGE.  My version of the WinUtil library has no such VI and the DLL has no function that would make sense to be called by such a VI.

 

I have never seen the source code for the lvwutil32.dll and doubt it still is anywhere available. It was developed by someone from NI I think back in around 1993/1994 for Windows 3.1 (right!!!) and later recompiled by someone for Windows 95 and some stuff was removed as it was now possible to do them with the VI Server much more easily. Nothing else has been done to it since then except various cosmetic edits to the VIs themselves.

Rolf Kalbermatter
My Blog
0 Kudos
Message 33 of 39
(3,760 Views)

I was able to avoid using that special DLL and just use user32.dll directly which still exists on a 64 platform like Windows 10. I think using an outside DLL which you don't have the source code is a bad idea. If I can get some time, I can show you the modifications I made. For my application, I embedded the MATLAB command prompt within my LabVIEW program.

0 Kudos
Message 34 of 39
(3,756 Views)

I will note though, I only implemented enough to place the window within LabVIEW. I did not convert all the functions over, just want I needed.

0 Kudos
Message 35 of 39
(3,754 Views)

Windows 3.1... I had no idea it was that old 😄 I must have a different version to you, the Get DLL Path.iv is used everywhere in mine. 

 

@Josh I would really appreciate that if you have the time. In my case I want to display the contents of an ffplay.exe window, which I'm using to display a video stream, in a Labview subpabel instead of having a floating window. Its more of a nice to have really

 

0 Kudos