Leaderboard

FYI something similar happens for Windows registry. If you read Local Machine\Software\National Instruments from LabVIEW 32 bit, in a Windows 64 bit, you will actually be reading from Local Machine\Software\Wow6432Node\National Instruments. A handy feature at time, but usually causes more issues than it solves. I did not know a similar function was made for the file system in regards to System32.

@Benoit; We are still in the process of defining the final set of primitives that will make to version 1.0. We are looking at releasing the Beta package by this coming weekend (hopefully).

Darn. I actually had a DEV template modification that demonstrates some of this, but I removed it from the published package because I thought it was too niche. See a screenshot below. I also need to use a subVI to name the event registration. You can also see a “Private Messenger†in the JKI Actor Template. Note, BTW, that I don’t use EventMessengers in the way you are: a different Messenger for each message. Instead I have multiple messages coming in through one event case, with a case structure on the message label. The only reason I sometimes have a second EventMessenger is to separate “Public†(or “Externalâ€) messages from calling code, from “Private†(or “Internalâ€) messages coming from my subActors. So I can prevent calling code from being able to send me private messages, and I can limit what subActors can do (like not tell me to shutdown, for example).

I'm experimenting with this framework, and my early impressions are that it's very powerful and flexible. In my experimentation I created a Messenger Event for registering with a sub-actor Observer registry. In the code I can give the User Event a custom label to make the Event Structure case more understandable (green highlighting in image), but I'm struggling to set a custom label for the Messenger Event, which I store in the actor internal data shift register (Blue highlighting in image). Is there a recommended approach that I'm missing? Applying a typecast always fails.

The VI "UNIXPathStringToPath" is an unused placeholder on windows. It is replaced with a platform specific implementation when loaded on Mac.

Because I'm an idiot and didn't test my code after back saving, which didn't include the subfolder that LabVIEW didn't know was a dependency. Attached is an updated version including the images in the demo. Ribbon Interface Test With Images.zip

Absolutely right, however you can disable that behavior for a calling thread. To do so just call Wow64DisableWow64FSRedirection and Wow64RevertWow64FsRedirection when you are done. Make sure to call both methods in the same thread (I have used the UI thread in the past)! In between those calls you can access the System32 directory normally. Very important: All calls to the System32 directory must be executed in the same thread as the DLL calls! EDIT: You might be interested in reading this explanation to the File System Redirector: File System Redirector

There was such a thing in the old times of LV6 . Here is what I remember (This was nearly 15 years ago, my memory about this stuff is dim): LV player was able to run signed VIs, you were even able to see (but not edit) their block diagrams. To sign a VI you needed a special tool that required a LV6 Professional Development System. Without LV6 and this signing tool you won't be able to do anything useful with the player. I don't see a reason to resurrect this old piece of software, except for nostalgia :-)

Not exactly a constant but a VI that returns the path separator: vi.lib/Utility/sysinfo.llb/Get File System Separator.vi