Darin

In general you can use the Class Browser (Ctrl+Shift-B) and search for 'Style ID', or whatever property you are interested in. Also, make sure you have scripting enabled to see the Blue properties (Tools->Options-> VI Server)

The Style ID property of the Control class should get you a little bit farther. Not all of the way, some controls are simply cosmetic alterations of others.

I have been trying for years to get the following bug(s) fixed to no avail. Beware if you use or plan to use the 'Names' format for the CLFN after you adjust the ParamInfo property. https://forums.ni.com/t5/LabVIEW-2021-Public-Beta/BUG-s-Call-Library-Function-Node-Scripting-Problems/m-p/4147512#M93

Get the desired PropertyItem from the Properties[] property of the Property Node reference. Then you can set the isWrite property as desired.

Log files are why Linux has the 'tail' function and Powershell has the -Tail option for the Get-Content command. For a straight log file it would never occur to me to put new entries in the beginning, just use tail. The other alternative is to log to a database instead of a simple file, but in my view that often adds a lot of moving parts for no real benefit.

In the world of C it is up to us to declare variables such as those Refnums as 'volatile' so the compiler knows they may change despite the appearance of being loop invariants. I would say it is a bug that the LV compiler does not treat Refnums as volatile. I'd say most of your workarounds would work, but are in (slight) danger of being optimized away as the compiler improves. Personally, I'd drop an 'Always Copy' node instead of the IPES.

I tried this on purpose a while back and was starting to get excited when I made it farther than I did with DVRs or Queues, but in the end it screws with your private class data and you can not bundle or unbundle it (try creating an accessor in your Class1). Sadly it is a bug that it doesn't complain sooner when you do this. Still stuck with pointless Type Cast dances to achieve recursive data types. And, yes, this is most likely the root cause of your build issue.

Reason number Avagadro's Number + 1 why units annoy me..... Too many corner cases here to worry about pretty printing. I'd simplify things and simply pass the original value (not the output of the Assert Floating-Point Numeric.vim) to a Format to String function (not Fract/Exp String to Number) and use the default formatting. You'll get base units everywhere, but for debugging and something that has to be robust enough to ship, probably as good as you'll get.

In fact I would strip the units only to check the type, but pass the original value into the string format. Taking it one step further, for a real floating point value with units I would cleanup the string by using SI units and then a little regex action. Complex values with units are just too far out there to worry much about so I just use the default format. Scalar To String.vim

VIMs are not the actual culprit here, rather the Type Assertions (or lack thereof). A double with units will fail the Assert Floating-Point Assertion test. This may or may not be a bug. In the absence of a separate assertion for floats with units, it probably is. The second assertion failure occurs in the Scalar to String.vim itself. A double, with or without units is a perfectly acceptable input for a timestamp format string. Unless you add an assertion in the timestamp case, there will be no broken wires, and voila, your DBL with units is interpreted as a timestamp. I see no reason not to Assert that value is a Timestamp in the Timestamp case, since you already preferentially decide that DBLs should be handled with Number to Fractional String. A little Edwin Starr: Units, huh, good God What is it good for Absolutely nothing, listen to me…

I do not think that XControls draw their pane, that would become quite the pain when placing them on different front panels with different colors. What I would do is place a single page tab control on the facade (hide the tabs) and put your other controls on it. Control the background color using the FGColor property of the Tab control.

The instructions in KERNEL_SOURCE.txt are pretty good and work well for me. I use a Ubuntu 18.04 VM for cross-compiling, I would suggest at least 70 GB hard drive space. More help can be found here: https://forums.ni.com/t5/NI-Linux-Real-Time/ct-p/7013 And you can watch this if you'd like:

Good catch using Spy++ in the first place. Not sure I would check every control, but I have always found gauges and meters to be particularly troublesome, so I would check those. If you ever color a part transparent I would think about checking, but LV has gotten much better in the past decade. Once upon a time I actually used the fact that an overlapped, transparent picture control triggered excessive redraws to "fix" problems with controls which were glitchy from a lack of refreshing. Was this control born in LV14 or was it upgraded from an earlier version?

Transparency + overlapping objects can lead to a situation with constant redrawing. In this case (LV14 SP1) I was able to tame it by coloring the housing a solid color and then recoloring it transparent.

I should have seen from the original post that you are using the wrong function. The function you described takes an existing share (mapped network drive for example) and resolves the mapping (server name from mapped drive letter, for example). You are looking for the URI for a local file, there is a simple .NET function to do that.