Jump to content

dadreamer

Members
  • Content Count

    66
  • Joined

  • Last visited

  • Days Won

    5

dadreamer last won the day on January 5

dadreamer had the most liked content!

Community Reputation

25

3 Followers

About dadreamer

  • Rank
    Very Active

Profile Information

  • Gender
    Male
  • Location
    RF

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    2010

Recent Profile Visitors

562 profile views
  1. Finally here it is. Refnum_to_Pointer-Linux.zip Refnum_to_Pointer-MacOS.zip Tested in LV 2020 on Ubuntu 20.10 and macOS Big Sur. It's assumed to work in 64-bit editions of LabVIEW only.
  2. Maybe it's not what you are looking into, but did you consider using VI Tags to store, read and write the data? It's contained inside a VI in a dedicated resource section, so it will be inside an EXE after the building as well. It has one disadvantage though - you can't use OS tools to view and edit the data directly, but have to use LabVIEW/RTE to do that. If you're fine with it, then try to give it a go. https://zone.ni.com/reference/en-XX/help/371361R-01/lvprop/generic_m/ https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-04-13-2009/m-p/888538?profile.language=en
  3. I just hardly understand, how new features of NXG could be integrated into classic LabVIEW editions, given that a classic is written on C/C++, whereas NXG is made on C# mostly. It's also worth mentioning, that some code pieces of classic LabVIEW were not updated for decades, so it would take years literally to rework them and reimplement some NXG possibilities (as zooming, Unicode support etc).
  4. Might it be that LabWindows/CVI RTE should also be installed on a clean machine? DLL dependencies utility shows, that QCMM2000.DLL depends on cvirte.dll. I'm not sure, where you could download 4.0.1 RTE for LabWindows, it's not available on NI.com. Maybe try to request it from the vendor?..
  5. Definitely yes. I have done this many times for simple applications a la "Calculator" and it does work. Although for modern LV versions (starting from LV 2018 as I can remember) it has become more complicated, because universal CRT is used, that requires Microsoft Visual C++ 2015 Redistributable to be installed or a whole bunch of DLLs should be placed near the exe instead.
  6. When I found a way to obtain the object's pointer given its refnum, I remembered my old and currently declined idea on NI Forums - Ability To Get .NET/ActiveX Window Handle By Its Automation Refnum. The solution proposed there is not good for many reasons, so I decided to see, whether I could pull out a HWND of NI Container Clipping Window from LabVIEW's internals using the object's pointer only. After some experiments I have succeded! So, now it's clear that LabVIEW retains that HWND in the memory to be able to do some manipulations with the window (like resizing / moving etc.). Okay, he
  7. Did you know that this option shows "Autopreallocate arrays and strings" checkbox on VI Properties -> Execution tab? Here's the excerpt from the LabVIEW Help about this setting.
  8. Nice catch, Rolf! It works and I am able to pass the input/output parameters now. RunVI.vi SubVI.vi But it appears that CallInstrument wants to be ran in UI Thread only, else LabVIEW goes big crash. It calls the VI synchronously, waiting until it finishes. That makes me think that this function is not the best idea to use as a callback, because when the user will be interacting with some GUI elements or the program will be running some property/invoke nodes, the callback VI will be waiting UI Thread to become idle, thus we could experience the delay between the events from
  9. I have not, but I just tried and saw no difference in passing strings into CLFN (no matter, if variable, bounded or fixed length). I think, it could be some archaic setting for early LVs before 2009. It even doesn't cause a VI to be recompiled unlike "Type Only Argument" option. It just adds 0x40000 to the flags field in the terminal's DCO properties. Having played with that flags field a little, I can conclude, that it affects IDE behaviour and the terminal look only (to accept some wire(s) or not), but has nothing to do with the compiled code execution. For example, with value of
  10. I'm afraid, we can't use them, because they don't actually run a VI, but "prepare" its state for a run. I guess it's used only for LabVIEW Adapters to be called later from TestStand. VIRefPrepNativeCall requires a VI to be in reserved state, otherwise it returns 1027 error. If we mark the VI as reserved with StatVIRefReserve, then it all goes OK, but the target VI is not executed. Something like this: int32_t StatVIRefReserve(uintptr_t viDS, uint32_t *pVIRef, int32_t unknown, int32_t setUnset); int32_t VIRefPrepNativeCall(uint32_t viRef, uintptr_t *pVIDS); int32_t VIRefFinishNati
  11. All I could find about this is just these two internal functions: CallVIFromDll NCGRunVirtualInstrument For the first one I was able to find .NET prototype only: CallVIFromDll.Invoke(Int32 epIndex, IntPtr lvClient, IntPtr entryPointDataSpace) I'm kind of unsure, how it could be used for the mentioned task. It looks like it doesn't accept the VI parameters. And what do these arguments mean exactly?.. As to the second one, it doesn't accept the VI parameters as well and must be called in UI Thread only. The prototype is as follows: int32_t NCGRunVirtualInstrum
  12. A few WinAPI calls are used there. Besides of that I suppose that assembly blocks should be altered and the hard-coded offsets should be checked as well. It all needs a time to debug on those platforms. I have VMs for Linux/macOS on one machine only, so... Do you really need this on Linux or macOS?
  13. It took a while to code it, but here it is finally. 😉 I have found a way to retrieve the object's pointer soon after the last post in this thread, but had to debug and test everything. Refnum_to_Pointer.rar How it works: As we don't have any public or private API to obtain Base Cookie Jar (BCJ) pointer (that is a LabVIEW global variable), the only way is to examine some function, which uses it, find the place with this global and save the pointer. Actually, this is how we're getting our BCJ. To clarify, it's for Object References only, not for any other references out there.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.