drjdpowell

Didn't think to include G#, GOOP and similar, as I've never used them.

Apologies to JKI for not explicitly including State-Machine-Objects in the poll. Though I think what you compared was two common community frameworks, plus the framework you use, and largely developed, regardless of how common it is. Difficult to make such comparisons, as the stuff-you-know-well usually trumps stuff-you've-read-about. Even getting unbiased comparison categories is hard; I'd probably have "messaging pattern support" and "network communication", two things Messenger Library does well, yet not "Teststand Integration", which I've never tried.

I was interested in the relative numbers of LAVA developers using different "frameworks" or types of architecture. Apologies, my list of poll options shows my biases towards a message-passing, actor-ish, style of architecture. Sorry, I seem to have forgotten to allow more than one option, so you'll have to pick the the best answer and explain more in a post. I pick "Messenger Library", though as I developed that, my honest answer is that I use my own internal framework.

Oops, two things called "name". The "Names" output is an array of item names. Your item name is, confusingly, "name". "Cartographie" is one of your date values. It is a string, and I in my example provided a string as the data type. But you provided as data type an empty/void Variant, which will fail. Use a string like in my example.

Your names are strings, not variants.

You certainly can do this with LAVA JSON, but I would suggest you use the JSONtext library instead, if possible:

Your right, there is a reference leak here. That Queue is a reference created in the actor's calling code, and is used to trigger the "Autoshutdown" message when the caller stops, thus invalidating the Queue. There is an async component called the "ReferenceMonitor" which watches that Queue and sends the Autoshutdown message then closes. ReferenceMonitor also polls the actor's address, so it can shut itself down if the actor dies. However, I forgot to destroy the Queue in that case. Here is an image where I have added the needed Close operation: Thank for spotting this, -- James

Yes, these references are intended to only be closed when the actor that created them stops running. The term "reference leak" is used by the trace toolkit to indicate any reference cleaned up by LabVIEW when a vi goes idle, regardless of whether it is an actual leak.

A JSONtext example, ssumming all dictonary items are the same type: Alternately, keep items in JSON format so they can be treated differently at a later step:

Don't quite understand that. JSON is a standard data format, widely reusable. Your weird Variant/Cluster/Dictionary thingies are very non-standard.

This idea, though it is a request for the reverse operation, illustrates how one can convert a cluster (in a variant) into an array-of-variants that contain the individual cluster elements. This did not exist when the OpenG Variant Tools were made, and OpenG is based on the (much slower) operation of manipulating flattened data.

If you can access the original JSON string, then you have more options to convert it, such as with the in-built JSON primatives or JSONtext, both of which should be quicker and use less memory. The code would be simpler too.

One suggestion is to use Variant-to-Data to convert your Cluster-in-a-Variant to an Array of Variants containing the Cluster elements. Then use the Data type palette to get element names. This will be much faster and less memory intensive than using OpenG Vis.

The problem is, if there are two dialogue actors, which should be on top. Only one dialog can be interacted with, but that one isn't necessarily on top.

I do that. But the problems I have are reported by Users of the EXEs

Does anyone have a solution to the problem of ordering of floating windows, where for example a modal dialog box is behind another floating window, and thus can never be dismissed? Or a floating window opens a file-selection dialog, and it opens behind the first window. Is there a way to determine which modal window has control (and must be dismissed first) and then force that to the front?

The programming term you should look into is Futures and Promises. It is about handling results not yet received (such as defining their order, as you wish to do). Single-element Queues, as TomOrr0W suggests, is what I usually use.

You can easily customise a standard boolean by swapping out the on/off elements for whatever decoration you want. Then you can colour on and off states differently. Alternately you can use PNG images (already coloured) for the on/off states.

I'm afraid I don't even have easy access to a Real-Time unit to try 2019 on. My clients are all 2017 or 2018.

You would need to compile a loadable extension to add that functionality. As an example, I compiled extension-functions.c in order to allow advanced math functions like standard deviation, so you could have a look at that. I note that there is a regexp.c extension on the SQLite website, so you could try and compile that using the loadable extension instructions.

I never use the wizard. I used the online documentation and wrote VIs by hand.

The "pretty print" includes a length check, and keeps small objects compact. You can see it in the code; it's 40 characters or less, I think. This was added to improve the readability of arrays of small objects. Unfortunately, "pretty" is subjective, and it is hard to come up with simple rules that work for all possible input JSON.

I haven't (yet) implemented an "any depth" wildcard character, but if you know how many levels down the item is, you can use wildcards for each level: $.*.*.*.*.NID_PACKET

Did you try a non-Messenger Library TCP example to see if it has the same issue? Another test would be to launch a basic actor (not the TCP communication ones) and see if that causes the same disconnect (if so it could by the ACBR stuff). Unfortunately I'm not on 2019 yet, so can't look into it.

That node starts the TCP Listener; can you try some simple example code that creates a TCP listener and see if it has the same issue? Note: if you change the "TCP Listener" Actor to non-reentrant and to open front panel, I think you can debug it on RT.