Darin

Thread safe code has no possibility for race conditions. If a piece of memory can be accessed from multiple threads, then some form of synchronization and locking must be employed to allow one operation to complete before the next one starts. It is ok if the order of multiple operations is not deterministic, as long as each operation is atomic. Let's say LV is trying to load the same VI in two threads. They could both look and see that the VI is not in memory, and then they both load it, and you have two copies floating around. If they are forced to be sequential, it does not matter if thread 1 or thread 2 wins and does the loading, what matters is the second thread will see that the VI is in memory and not reload it. The hard way to achieve thread safety is with mutexs, concurrency checks, and other locks, and means you had better catch all possibilities. The easy way to achieve thread safety is to be single-threaded. For this reason, all code which requires thread safety gets pushed into a single thread, which happens to be the UI thread. Why the UI thread?, well LV was multithreading when multithreading wasn't cool. This involved rolling their own cooperative multitasking which means a task grabs the thread for a while, and then gives it up to another task in the pool (often putting itself back in the pool to work again later). A 'rude' thread won't give it up so easily, but most times it appears that parallel tasks are being done. This framework is still present in the UI thread, it can be single threaded when needed, and cooperative to emulate multitasking. Thread safe code grabs the UI thread and does not let go until it is done. Someday, there may be additional special threads to separate some tasks from the UI. It is true that it both has come a long way, and that it has a long way to go.

Almost anytime that LV wants thread safety it uses the UI thread. This includes operations like opening VI references. Some operation in the auto-population is grabbing the UI thread, probably the first time you pause for a few msec.

I assume you are eschewing the built-in methods because opening the class involves the subsequent loading of a large number of VIs. What I have also done instead is get the class icon data from the lvclass XML file and replace the icon data in the XML file of a blank class or library. Now use the built-in functions to load the blank class file and get the icon image. The loading is pretty fast on a blank class or library.

Use the built-in parser to get the XML element and you do not have to worry the escaping. If I were you I would grab the icon element from the monster class, insert it into an empty class file and use the built-in functions.

Histogram it and you will immediately see that it is a form of Base-64 encoding. Shift back to zero (I forget the offset), extract the six real bits from each value, and repack into bytes and it is all right there. There is a deflate step which was added in LV8.6 I believe. I create Windows thumbnails of vi,ctl,lvclass,lvlib, and xctl files by reaching in and getting the icon.

Personally I see no issue posting the code here, I have posted plenty of "This will crash LV" examples with sufficient warnings. How about a screenshot at least of the offending code. I have seen a few of these bugs in the scripting world, especially with the private methods, don't know if that is what you were doing or not. I have taken to dumpster diving into the lvlib, xctl, and lvclass files directly since I find the scripting methods are slow (insist on loading everything when all I want is an icon or something), buggy, or do not exist.

I should add one of my other "rules" here which I call the "What the F*&*( Rule". You are often faced with a situation where the easy to read code is *slightly* slower than a crazy, ultra-complex, unreadable alternative. Inevitably you are going to open it up a few months later and say WTF?! If all of the complexity saved you a microsecond, that code will have to run millions of times to make up the time it took you to say it. Not to mention the extra time spend coding it up. And let's say it passes the WTF rule and is worth the complexity, in order to save it from your future self, or your replacement, you may want to mention why you chose the complex solution. Otherwise, someone will be very proud that they replaced a bunch of crazy code with a couple of functions, or think it looks better when that constant is moved outside the loop. Only later will they ask why it is so much slower.

Bit twiddling falls into the grey area since I consider that a simple formula that G has a hard time representing. I am talking more about the play by play comments you see (Add two values together and multiply the result by x). Close the reference. You should need relatively few comments if you: Provide useful names, descriptions and icons for subVIs which should be doing one thing most of the time. Provide visible labels for constants, and display the most useful radix (b1000 is often better than 16 for bit operations) Maintain low to medium density of nodes with a neat BD I'll rephrase by saying, you should be commenting on the algorithm, not on the implementation. Comments should ADD information, not simply rehash the BD. Naming a song Waltz helps you when it comes to reading the sheet music. For example, I am ok with saying "check if bit 4 has changed". I can look at the implementation and decide on its correctness. I think saying "take XOR of old and new values, then AND with 1<<4" is superfluous.

I will once again state the analogy that many of you have heard me make elsewhere: Text comments in LV are like writing the letters next to the notes on a sheet of music. You should be able to "hear" the tune just by reading the music. Comments are for: References. Copyright Notes to self (doing this because of LV bug xx, finish this) Why the code is there (covers requirement xxx) Comments are not for: This is what the code is doing. Grey area: Equations, G has a tough time representing equations.

Assuming the accelerator exists, I usually simulate the Alt+? followed by the accelerator keypresses.

Makes it even easier to implement my idea: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Almost-Equal-quot-functions-for-Float-comparisons/idi-p/1446480

The fundamental issue here is that Type definitions define type, not value. Of course NI has been beating people over the head for more than a decade now to type def enums and clusters so it would be poor form if they turned around and gave you that answer when you complain about this behavior. Now NI, as is their wont, stretch the definition of 'Type' definition a bit and try to accommodate this expected use case. This is as effective as the developers are in determining all of the corner cases. LV users delve into some very dark corners, so this is usually hard. Holes like this are likely bugs and probably get fixed in the usual (insert adjective here) timeframe. We are used to the fact that it is safer to explicitly bundle type def constants instead of relying on the values of BD constants. Maybe we should be doing the same thing here: Which brings up another thing that bites you every so often when updating td enums connected to Case structures. Sometimes a list 'a','c' gets silently changed to a range 'a'..'c'

The colorbox is not really intended to display a colored box (I hope that makes sense). It provides an alternate and often convenient representation for the U32 representation of an RGB color. Its long name would be color selection box instead of color display box. I like using the intensity graph when I can, it handles changing the z-scale nicely and other things. It is also easy to perform the color interpolation manually and use a picture for the entire operation. The bonus is that you are not limited to the 8-bit depth that the IG has, but you lose the events and such. There are many tricks, if there is a common denominator for the sizes, it is easy to use multiple points for each sensor and vary sizes that way as well. And, beware the overlay of the transparent picture. In older versions it would sometimes confuse LV into thinking it had to redraw parts of the FP when there was no need, causing considerable sluggishness.

I have also used the PlotImage property to put a grid onto a Intensity Graph, you could also add colored masks to various cells. Grid.zip

Thinking outside the color box for a moment, for a simple solution I would use the high and low color values of the ramp to indicate not in use or bad and set the values accordingly (easy using +/- Inf). Adjust the scale of the ramp to handle all valid values.

Compared to the markup on resistors, cables and other items, that's a steal!

As a matter of fact there is an API to access the Lithium data, but you would have to be some kind of geek to be using that to analyze trends on the idea exchange. If such a geek did exist, I am pretty sure he would tell you that projections have my idea ahead of yours 180.12 to 151.66 after two years time. Of course that geek's predictions tend to be better when the tail is not disturbed too much. That geek would probably also be very happy if the property node idea were implemented. In fact, I am pretty sure he would think it is a great idea.

You should really say "No like the president"

Why does S&R not fulfill your desire? The regex engine deals in offsets and lengths in its internal state machine. Implementing dropped characters would really require a fundamental change to this representation. I am not sure what it would do to its speed (lack thereof) but my guess is that it will not speed up. There seems to be a reason why regular expressions are low-level tools used in higher-level languages. In Perl you can sprinkle some other code inside, but it really makes things hard to read. Most people do not realize that you can comment inside regexes, and even fewer ever want to deal with a regex which requires commenting.

In Perl you can get funky, here I would S&R or use capture groups on both sides and concatenate. Actually I would probably do that in Perl as well.

You can just go to the source: ..LabVIEW xxxxvi.libAdvancedStringCommand Line String To Path.vi

When it comes to unicode support in LV, the philosophy borrows from Kipling "East is East, West is West and never the twain shall meet."

Is this the TPS format with or without the new coversheet? See here: https://github.com/ctrl-alt-dev/tps-parse and here: http://blog.42.nl/articles/liberating-data-from-clarion-tps-files-2/

A similar approach is to intercept the Mouse Down? event and populate the combobox strings based on the clicked element:

From my vague recollection, I think you can use the Config.Get Target App's Settings (or Set) to do what you want. However, I think it requires the line exist in the ini file before it can change it. I do not think it will add it.