Leaderboard

I had this issue in the Quick Drop window. And for reasons I can't remember now, I wasn't able to use a system combo box. So my solution was to have a frame decoration, with the same color as the panel, that I position exactly where that ugly black box would be. And the decoration is higher up in the panel order than the combo box. So when I assign key focus to the combo box, you don't see the ugly black border because the panel-colored decoration is above it. I also have to resize this decoration on a panel size, to ensure it's always surrounding the combo box at exactly the right size. Programming UIs in LabVIEW is fun!

Have you turned UAC off through the User Accounts control panel applet?

Noooo!!!! Please not!!! LabVIEW manager functions are ALWAYS C calling convention! That it seems to work is simply very bad luck (and it most likely doesn't really work but just not crash anymore). What the real problem is, is the fact that these VIs were written long before anyone knew what 64 Bit pointers will be and therefore LabVIEW also had no means to configure parameters as pointer sized integer since in all LabVIEW versions sizeof(*void) == sizeof(int32) was true. The second paramter to MoveBlock() is configured therefore as int32. To make this work all Shared Library Nodes in that library need to be revisited to check for parameters being configured as (u)int32 but really being pointers and they need to be changed to be pointer sized integers. After that the library should work independent of the bitness of LabVIEW. This means that besides the second parameter to MoveBlock() at least the function where this wire comes from needs to be reconfigured too. Edit: I see it uses the WinAPI RtlMoveMemory instead of LabVIEW MoveBlock(). From the VI Name I assumed it would be using the LabVIEW manager call. The problem about the pointer sized integer parameter however remains the same. It just so happens that Windows hasn't mapped the heap of your application above the 2GB range, otherwise it would badly crash. And that library needs to have a lot pointer sized integer adaptions to make it 64 bit safe.

Hi, Right now I am working on a project to create an open Vision-like library for LabVIEW based on Intel OpenCV. At the moment, we don't have enough time and people to wrap all the OpenCV functions, so we could really use some statistics on which functions are essential and which of them could be left for the future. Please, express your opinion here. Thanks in advance

or, if you want to use dynamic VIs for memory loading reasons (or some other reason where static links are not so desirable), you can always create a "launcher.vi" in the same folder as the dynamically called VI, that way the path to "dynamic.VI" will always be <launcher.vi's path><stripped 1><appended with dynamic.vi>