drjdpowell

Here is something that I often have problems with and have no good solution: Often I have floating or modal windows, and another modal window opens (either from the VI that is the first window or another async-running component) and the active modal window ends up behind the first window. Often this second window is the file dialog. The User ends up unable to click on the active modal window, and unable to move any other LabVIEW window. They think the application has hung, which effectively it has. Really, of course, I want the active modal window (that is blocking the User from all other windows) to always be on top. How do other people get around this problem?

Those are VIM, VI macros, I think, not your clones. To get clones you need to use Open VI ref with the form <VI name>:nn, with nn as a possible clone number. See the development of the Task Manager.

Thanks Rolf, your definition of "pretty easy" is slightly wider ranging than mine.

i'm afraid I only ever had the documentation from the netCDF website, sorry.

I've done a 3D-points-cloud type application in the past. I used SQLite to store and analyse the data, using the RTree feature to store points (the RTree is designed for fast lookup of multi dimensional mapping data). One can do max/min, mean, std dev, etc user various filter conditions in SQLite much easier than in LabVIEW arrays. For display I used the 3D Picture Control. Both these techs involve a steep learning curve but are very useful for your type of application.

The special math functions like "Create Special Matrix" can do it; they return an error code -20001 ("Analysis: (Hex 0xFFFFB1DF) There is not enough memory to perform the specified routine.") if you try and create a too-large matrix. They do their work in a dll, and this might be the way I would have to go.

I have application where the User provides files from another program, which are typically 10 Mb, but with no real limit on their size. One User managed to generate a 900+ Mb file and caused an out-of-memory condition which caused my app to fail. Rather than the annoying "Out of memory" dialog that pops up, I would much rather get a standard error that I can handle (by telling the User that file is too big to load and then returning to normal operation). So I have been trying to think of a way to attempt to allocate a very large string with a graceful way to fail if there is not enough memory. Has anyone else found a way to do this?

I've had a google and you're right, there are uses of "priority queue" for structures that are not analogous to common meaning of "queue". Wikipedia even labels a stack with priority as being a "priority queue". Personally I think this counterproductive when used with frameworks as only a subset of users will know the secret language. Surely we can use English words with their standard meanings.

That's my point. You explaining that a theorectical elderly person might get priority means this is a priority queue and thus there was no other expectation of ordering, and that's why you cutting in front is ok...that ain't gonna go down well.

That is a weird, though undeniably literal, interpretation of the words priority queue. You must get into a lot of arguements at the supermarket checkout.

I'd expect there to be a very strong expectation that anything called a queue enforces ordering, as that is what the word queue means.

Thought I'd show an example of "complexity" of a framework, according to my way of thinking, by comparing the priority messages of the NI Actor Framework and the DQMH: Looks the same from an API level (they even use similar icons). Let's look inside; here is the relevant code section for priority messages for the AF: Yikes! And here is the same for DQMH: Ah, much simpler. Now we can see which framework involves more complexity: the DQMH. Wait, what, you say? Isn't the obvious complexity of the AF implementation mean the AF involves more complexity? Well, no, because I, as User of a framework, care nothing about the implementation, I care about application I am building with these APIs. So let's consider the task of sending three high-priority messages, A then B then C. In what order will the three messages be received and acted on? With the Actor Framework the order will be A, then B, then C, ABC, always. With the DQMH we have: 1) if the receiver can execute them faster than they are sent, the order will be ABC 2) if the receiver is handling another message the order will be CBA (as we place on the front of the queue) 3) if the receiver is idle, but executing A takes time (allowing C to get before B), the order will be ACB 4) if busy but finishes after B is sent but before C is sent, the order is BCA 5) as (4) but B is finished executing before C sent, ther order is BAC Thus with the DQMH there are 5 possible orderings of execution, with the probability of the various orderings highly dependant on timing of not-directly-related bits of code (other messages being sent). At best, this is counter-intuitive and potentially confusing during debugging. At worst, one combination is a rare race condition that doesn't show up during testing and causes near-impossible-to-debug errors in deployed code. So that is an example of complexity, and it is certainly accidental, as the DQMH designers did not intend unpredictability of message-handling order when they used enque-in-front as message "priority".

Exactly, but according to your definition it would be "accidental complexity". No, my original claim (that Daklu reacted against) was that a good framework reduces complexity. Working without a tried and tested...something (could just be a standard way of working that you are very expert in, but a "Framework" adds a library that supports that standard) leads to code that has extra complexity in it. Often that extra complexity is not obvious, but that's the worst kind of complexity. A particular bugbear of mine is NI templates like "QMH" and "Continuous Measurement and Logging" template/example that come with LabVIEW, which you might think are simple. I consider them very over-complicated. I've given more than one talk pointing out weaknesses in CM&L.

What is a "framework" but a tried and tested template for design combined with a support library and hopefully some productivity tools and documentation?

I don't think Functional and OO are contradictory, per se. Rather, it's by-reference objects contained in other objects that is very non Functional. By-value objects and LabVIEW dataflow seems quite Functional to me.

I think Daklu meant when your program is more complex than the problem it is solving. My problem with calling this "accidental" is that it sounds easy to avoid if you're careful, when really it is very hard to avoid lots of extra complexity. An example that comes to mind is shutdown/cleanup code. A good framework will handle cleanup simply and easily (this is an area I think Messenger Library is strong).

Yes, I try to do that with "Messenger Library". Unfortunately, I find that if I stress that it is a library of messaging (with optional "actor" templates) that it gets dismissed as not to be considered when comparing "frameworks", but if I present the whole thing as a "framework", then people assume it is very restrictive.

That "accidental complexity" is a killer. It's a big part of that exponential increase in complexity you showed on your graph a couple of posts ago. Helping to get that out of the way so you can address the true complexity of the actual problem is no small thing.

How does MVA relate to your STREAM framework that you've blogged about?

Here is a beta version, 1.11.0, with changes to TCP Messengers to support the various TCP options about ports and the like. Also adds a Keep-alive to detect half-open connections. Bitbucket Issues 26, 27, 33. I have not had time to do more than a basic test; it would be a help if someone could give it a try. Note that I've replaced some of the creation VIs for TCP Messengers in the pallette (originals should still work, but I wanted to change VI names). drjdpowell_lib_messenging-1_11.0_116.vip

That is Issue 34, which will be fixed in the next version. In the meantime, the fix is quite easy and described in Issue 34.

Does your variant have a name? If it doesn't that's why it's name is "". Re attributes, you have to provide a variant containing default values of those attributes. This is because the JSON doesn't contain the LabVIEW type information (can't tell a string from a timestamp from an enum). I realize this is not the answer someone who uses variant attributes wants to here. Personally, though, I use sub-JSON instead of variant attributes, with cluster elements that are strings with the <JSON> tag in its name.

Issue 33

What number do I feed to "net address" to make it local host only? I wasn't aware of such a feature.

Worse, writing the image ref only triggers the need for a refresh of the control; the actual read of the data is asynchronous (like all LabVIEW indicators) and happens a short while later, possibly after the image has been changed.