candidus

Maybe Jenkins reads StdErr instead of StdOut. Try to change the argument of DuplicateHandle() to StdErr (-12). Just a guess, I didn't try that myself.

Great article, thanks! And a pretty cool way to explain things in LV terms OK, here the detailed explanation as promised: You can find a very simple example in the ZIP file attached to my first post, GZipStream.Example.vi . There's a file Hello.txt, if you run GZipStream.Example.vi you'll get the compressed file Hello.txt.gz . To decompress it, activate the other frame of the diagram disable structure and run it. The output will be Hello2.txt . There's not much to say about this example VI, the code consists of just .NET invoke nodes and properties. The code of CreateGZIPStream.vi is that what matters here. We use .NET reflection to call a constructor that would be otherwise inaccessable for LV. Reflection is the ability to query a .NET assembly (DLL or EXE) for the classes (and other types) contained within and ask these classes for their properties, methods, events and constructors. It is built into the .NET framework and thus always at your service if the .NET support of LV isn't enough. The most important .NET data type when using reflection is System.Type . OK, let's now dissect the code. Sorry about using C# here but I know no better way to explain .NET code. This is what we want to do: GZipStream CreateGZipStream(Stream stream, CompressionMode compressionMode) { // Call the constructor. return new GZipStream(stream, compressionMode); } Since LV doesn't allow us to select this constructor we need another way to get and invoke it. Reflection makes that possible, although the code becomes much more complex. CreateGZipStream.vi is roughly equivalent to the following C# code: GZipStream CreateGZipStream(Stream stream, CompressionMode compressionMode) { // Get the types. Type streamType = typeof(Stream); Type compressionModeType = typeof(CompressionMode); Type gzipStreamType = typeof(GZipStream); // To get the desired constructor we need its argument types and bundle them into an array. Type[] constructorArgTypes = new Type[] { streamType, compressionModeType }; // Get the constructor. ConstructorInfo gzipStreamConstructor = gzipStreamType.GetConstructor(constructorArgTypes); // Bundle the constructor arguments into an array. object[] constructorArgs =new object[] { stream, compressionMode }; // Call the constructor and cast the result. return gzipStreamConstructor.Invoke(constructorArgs) as GZipStream; } Unfortunately LV complicates things a little further: We have no direct equivalent of typeof(). We can work around that by either using GetType() or loading the type from the assembly by name. Using GetType() is easier but it requires a valid .NET reference. Thus we need both: GZipStream CreateGZipStream(Stream stream, CompressionMode compressionMode) { // Get the types. Type streamType = stream.GetType(); Type compressionModeType = compressionMode.GetType(); Type gzipStreamType = compressionModeType.Assembly.GetType("System.IO.Compression.GZIPStream"); // To get the desired constructor we need its argument types and bundle them into an array. Type[] constructorArgTypes =new Type[] { streamType, compressionModeType }; // Get the constructor. ConstructorInfo gzipStreamConstructor = gzipStreamType.GetConstructor(constructorArgTypes); // Bundle the constructor arguments into an array. object[] constructorArgs =new object[] { stream, compressionMode }; // Call the constructor and cast the result. return gzipStreamConstructor.Invoke(constructorArgs) as GZipStream; } But that's still not enough. For LV CompressionMode is an enum, in .NET an enum is a full featured object. So we have also to construct a CompressionMode .NET object in LV and set its enum value. There's no direct equivalent to the 'value__' property in C#, I guess LV does something special here. Now we're ready to invoke the constructor in LV. The snippet again: We construct the CompressionMode object and use its Assembly property to get the GZIPStream Type object. Then we ask for the constructor using the parameter types bundled into an array. Finally we call that constructor with the arguments bundled into an array and cast the result to GZipStream. A note about the style of the code: When it comes to external reference-based code I use a single error wire through all nodes to enforce some kind of control flow. Furthermore it's important to close all open .NET references after using them. I'm using .NET reflection to do things that are not supported by LV for a couple of years now, in my case .NET Remoting with events, see here (no reflective constructor invocation, though).

Benoit, sorry about the missing documentation. The snippet above is just the constructor call new GZipStream(Stream stream, CompressionLevel compressionLevel) expressed via .NET reflection. Yes, it is that complicated but at least it's possible. For a more complete example see the ZIP file appended to my first post. I will write a more detailed explanation tomorrow.

All required libraries should be able to coexist peacefully. What happens if you add Controls.lvlibp to Limits (TSC_XML).lvproj? Does it help or does it make things worse?

Don't always believe what others say :-) When the .NET support of LV doesn't suit your needs use .NET reflection. This way you can get exactly the constructor you want. Here is some code to show the idea: GZipStream.zip

I put the game in a GitHub repository: https://github.com/mus-candidus/Labricks

I did it: Here is the URL to the GitHub repository: https://github.com/mus-candidus/StyledText Please move this thread to "Code in Development".

Get Current LV Bitness.vi will return the bitness of the currently running LV instance so this should work. Why do you need it? Do you have to call external code depending on bitness?

Great suggestion! Here you are. StyledText-20181006-LV2010.zip

There's a VI in vi.lib: vi.lib/Utility/Get Current LV Bitness.vi Note that this VI is not on the palette.

Cool, if I knew that before I probably didn't create my own library. Probably I used the wrong keywords for my search on LAVA. But now that my library exists, what to do with it? Submit it to the CR? Create a GitHub repository? Do both? I'm unsure...

I was looking for a way to specify text styles programmatically. After some unsuccessful attempts I found an approach that works surprisingly well, using selection and font properties. I wanted to use some HTML-like tags so I wrote a small library to do the work. Also included: A general-purpose 'about' dialog. Enjoy :-) StyledText-LV2010.zip StyledText-LV2010.zip

There is a reason to refactor: I have to add more features and I don't want my toplelvel VI to become any bigger - currently it has a huge block diagram... That's it! I began to experiment with an event containing a variant-based lookup table, then I looked at Messenger Library and saw that all I need is already there. Thanks!

Yes, the builder runs in a different application context. But you can open your project from the Pre-BuildAction.vi, invoke GetAllDescendants until you find your VI and then get its callers. That should work.

I have to decouple the UI part of a medium size application (approx. 2000 VIs) from its core. When we created the application it was a simple state machine. Later we realized that some operations must be asynchronous so we added an event-based control loop that controls the state machine via user events. But it was still a single VI and over the years it grew bigger... Now I decided to move the state machine (approx. 70 states) into a subVI but since there never was a separation between the UI part and the non-UI part I now need a way to access the UI controls (approx. 40 controls) from the state machine. Currently I see the following options: 1) User events from/to the state machine. This seems to be a quite clean approach but means a lot of work. 2) Use something like Actor Framework. Probably the most clean approach but even more work. 3) Get/Set Control Values by Index. I prefer that over Get/Set Control Value because I often have to read/write several controls at once. I can easily encapsulate this in a nice class that maps my control names to indices. 4) Put the control refnums into a cluster and pass that to the state machine subVI. This is the approach I dislike the most. I already decided not to do it that way. Currently I like 3) best but I have mixed feelings about it: - It seems odd to use control access to separate application parts. Maybe that's just me but it feels wrong... - I have controls of which I have to access other properties than the value so I definitely need events here. - Searching here on LAVA brought nothing about Get/Set Control Values by Index which disturbs me a little bit. Do you have any any advice for me? Do I miss something important? Thanks in advance, candidus

I had no problems with libraries. Maybe this helps: If you open the VI by name instead of path you need the fully qualified VI name and the VI must be in memory. The VI you want to call remotely has to be in the public scope. Here is the modified example project. RemoteLib.zip

Here is an example how to call a VI in a remote Executable. Note that I couldn't get it work without a custom INI file so this might be the most interesting part for you. Remote.zip

A slight modification of the variant approach: Pass the common camera parameters as a cluster and pass only the device specific parameters by variant. This variant could either be a separate parameter or a member of the initialization cluster.

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

AQ gave the right instructions but we have to use a private method to set the VI Path. I stumbled upon that when I tried to script XControls.

Not always. If your active window is the block diagram it returns its HWND Just out of curiosity: Are there use cases for a modal dialog that doesn't belong to the active window?

GetActiveWindow() might do the trick:

I have to admit, a blurred texture doesn't help that much. Here is a windows-only solution using .NET . The possible values of Graphics.TextRenderingHint are explained in the MSDN: https://msdn.microsoft.com/en-us/library/ssazt6bs%28v=vs.110%29.aspx.

You're right, the aliasing happens in the 'Picture to Pixmap.vi' but since texturing involves scaling and filtering the result looks slightly better than just using 2D with a big font size. You can then call "Render To Image" and save the result as JPEG.