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.

Well, there is a lot that could go wrong and not a lot of info to go on. If not working = crash, then I would check the calling convention. Windows API calls not-surprisingly use the WINAPI setting which is very easy to overlook. If not working = non-zero return value then you have to follow the links for system errors, mostly make sure that you are using a valid path from a mapped network drive. Other than that this function should work for you. It is similar to many other Windows API functions. The buffer upon return will have 1 or 3 pointers (these will be U32 or U64 depending on the dll bitness) after the pointers will come the 1 or 3 C strings. If you try to simply return a C string (with some min length of say 1024), you will either get a buffer with some random bytes (the addresses) followed by the string you want, or about 1% of the time, the buffer address you pass in will have a zero in it and you will get just a couple of bytes and no string. In this case you could simply retry and you'll get a different address that probably works. To be totally safe you can use the vi.lib functions to create a buffer with sufficient length (DSNewPtr), and then use GetValueByXNode to dereference a cluster with a single U32 or U64 (depends on dll bitness) and a string (for infoLevel=1) or 3 U32s/U64s and a string (for infoLevel=2). In this case the buffer parameter is simply passed as a pointer sized integer. About all the help I can offer at the moment with no idea what the real failure mode is, and no LV around to show you an example.

Start with a control in your template. Get a reference to that control and cast it to VIRefNum. Then call the 'Make Strict Reference' method using a VI reference to the desired VI. Finally, get the Terminal reference of the VIRefNum and invoke the method 'Change to Constant'. The constant winds up in a different location, if you are OCD like I am then read the position of the control terminal before and write that position to the constant after. It is pretty common to have more scripting versatility with a control or indicator than the corresponding constant.

Holy blast from the past, but back in the day I did create a pure G implementation of a limited subset of ZMTP. Basically I implemented what I needed for REQ/REP and PUB/SUB peers over TCP and some other low-hanging fruit. A few MUSTs and several SHALLs in the RFC were ignored along the way to suit my needs (mostly self-educational). It was strictly version 2.0, no dealing with v1.0 peers (plus it is now at least v4.0). Looking back I will just say that I was not lazy, I was guarding against downgrade attacks.... These days I use 0MQ a lot, but mostly over inter-process connections which requires platform-specific bits so pure-G is out, and at that point I strongly suggest just wrapping libzmq (actually if pressed I would suggest wrapping it in all cases). I do not say this about very many libraries, but this one has been a pleasure to work with across several platforms with many different language bindings. In my use cases I have not run into any problems with my wrappers

If all you are doing is querying a DB you may not notice that you are implicitly inside a transaction. To make changes that are available outside the current session you need to explicitly commit.

As the parent of an autistic child I would be delighted if you could find a different pejorative to use in these situations. Thanks.

My idea is dead in the water because it requires real effort on the part of NI. The good news for your idea is that it probably would make a nice addition to the right-click menu in LV15+

LV15 seems to behave itself. At any rate I would think it is a feature to be able to probe there.

I have managed to do a few cool things with these, and I have also managed to crash LV twice. YMMV

The start case needs the same check to add 1 when the for loop ends without finding whitespace.

Here is an interaction I have had on more than a few occasions: A: I have a random TCP problem Me: Sounds like a Nagle's Algorithm issue. A: I'll try that....Nope disabling Nagle did not help. Me: Sounds like a Nagle's Algorithm issue. A: I tried again, does not look like a problem with Nagle Me: That's odd. Let me know what you find out.... <Time passes> A: Turns out I screwed up, it was actually a Nagle's Algorithm issue. What I am saying is that this sounds like a textbook case of Nagle's algorithm. Until I was really, really sure, I would not look for something besides Nagle to explain the issue, I would look for the reason why it is not being disabled everywhere like you think it should be. One time I even started appending random garbage to the end of every message that was not of a given length.