How to run an exe as a window inside a VI

[jackwhelan]

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

[rolfk]

---

@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. 

[rolfk]

---

@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.

[Josh]

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.

[Josh]

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.

[jackwhelan]

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

[Josh]

I was unable to get it to embed into a subpanel. My application is almost like an APP viewer, where I can select different subpanels (one only shows as a time).

I wanted to do the same with the MATLAB command window, but I could never get it to work. So I have to embed in in the main labview panel. To hide it, I added a tab interface (one tab for all my applications and another tab for MATLAB). When you select the tab, I use a show function to hide and unhide MATLAB.

[rolfk]

---

@jackwhelan wrote:

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. 

---

The (semi-)official version with cleanup and updates for Win32 is here: https://forums.ni.com/t5/Example-Code/Windows-API-Function-Utilities-32-bit-for-LabVIEW/ta-p/3996462

Anything else is probably older and contains still Windows 3.1 isms.

[rolfk]

This is a first attempt at creating WINUTIL.LLB without any reference to the lvwutil32.dll. It calls directly the Windows API and should be fully compatible to both 32-bit and 64-bit LabVIEW. It should also behave the same as the version with the DLL calls.

I had to change the data type of the window handle control, so if code did use this typedef it should still work but of it was using their own copy of the control things will go bad. Of course if you have custom functionality with VIs calling into Windows APIs that are outside of this library, then you absolutely have to update them too, otherwise things will start to fall apart.

Format is LabVIEW 2016.