11-03-2020 01:53 AM
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
11-03-2020 08:40 AM
@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.
11-03-2020 08:46 AM - edited 11-03-2020 09:01 AM
@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.
11-03-2020 08:52 AM
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.
11-03-2020 08:55 AM
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.
11-03-2020 09:10 AM
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