ShaunR

It cannot function identically since YOU CAN NOT HAVE SHORTCUTS ON POPUP MENU'S. You can argue that maybe it should morph to hide the connector but then you're just as likely to have people scratching their head when using menu's. With this behaviour you get an explicit error telling you " Run-time menu shortcuts are not supported for this type of menu.". Remember. This is a run-time check, not a design time check. You get the same behaviour if you try to operate a function on an invalid type after coercion to a more specific type.

If you wire a keyboard shortcut cluster to a popup menu it gives you an error stating that it is the incorrect type. That's correct. You can only have keyboard shortcuts on main menu refnums. The alternative is to have separate primitives for main menu's and pop-up menu's-one with a shortcut terminal and one without. We can recreate the same behaviour with xnodes where we can detect if anything is connected and it's type with abilities.

Only main menu's can have keyboard shortcuts and yes. LabVIEW can tell if something is wired to a connector. It's how polymorphism works and why you get a broken run arrow for required terminals if you don't connect them.

Yes. I think it was the Studio Bods one I was thinking of. Looking at it now it seems to be geared towards executables and not sure if it will suffice for source code.

As long as it's only the app that has stopped responding you could also use the NI Webserver RPC feature to call a separate vi that reboots the machine (if that is still a thing after NXG). I'm not sure it's possible to install on a PharLap target but with SSH you can easily reboot a remote machine.

Interesting. This is could be due to their new subscription method. It might be worth finding out whether that is the case as there will be other caveats like you need to maintain a subscription Indeed. I vaguely remember a third party that was offering an alternative solution that was implicitly geared towards LabVIEW and used the TPLAT. But I can't remember who it was or how it worked.

The toolkit will lock the libraries and produce a licence file which you can browse to and select in VIPM. NI have a SoftwareKey Server that they use for Tools Network offerings but you can buy and install your own from SoftwareKey.

Is it reentrant?

I've only seen those sort of frequencies of corruption if the files are on a network drive.

Ditto what Rolf said. If you want a class that handles arrays of objects then take a look at List.

I don't really use classes for the intended purposes. I mainly use them as a variable cluster local to the instance when I need to keep track of state (sessions, stateful protocols et. al.). On the rare occasions I have used them for the intended purposes it has never gone beyond 2-3 and it's always been more hassle than it's worth, less elegant and incomprehensible build times.

That's because you have only dumped LV error messages into the DB. LabVIEW error messages are for LabVIEW programmers. Pull the error number out to a field so you can look up your own, different messages. I think what you are struggling with is the difference between application error messages and system error messages. So I would expect an application message something like "Server XXXX is not responding. Unable to connect to server". That is fairly easy as you just override the default LabVIEW message for 63 with a more verbose one. However. They may have left the IP address blank, in which case the application error would be something like "You must enter an IP address". If you let that through to LabVIEW then it will report error 54 "The network address is ill-formed." That may be ok since a blank IP address is, indeed, ill-formed but the former is more explicit. Note that just overriding error 54 with "You must enter an IP address" will have them yelling at you "I did enter it" as It is a context sensitive error. So adding a custom error code for blank fields that should be filled in is advisable and check the field before actioning. That way you can be sure error 54 was an illegal address. That's a rather contrived example but the sort of error guessing and reporting that I try to do (caveat: non programmers) In summary, there are application specific errors. A production line operator should only be expected to resolve two types of errors - they didn't enter something they should have or they entered an illegal value. Outside of that it depends on training and remit. If there is training then you should also add the training manual page and section to which the error refers. This will cut down a lot of the "didn't read it" responses as they are expected to refer to the manual to resolve the issue and the manual will contain far more information than an error dialogue and what to do about it. If they can't give you the page number and section then they have not followed procedure and you can chew them out. If they have referred to the manual then you know the common resolutions have already been tried.

You are not using SQLite for this? Not only can you have multiple messages based on required verbosity but you can have fine grained segregation based on type (information, debug, Critical, Warning etc) and user (Operator, Technician, Maintenance etc). Additionally you can have language translations.

Considering COBOL is over 60 years old, I think most experts have long since retired and most of the US government runs on COBOL. Just a quick and dirty example from one site...

Too obtuse for my smooth brain. You link to a COBOL forum and imply something but I have no idea what you are implying or it's relevance. Is it a spam post?

The intensity graph is usually an order of magnitude faster for this sort of thing as it has in-built interpolation. Not sure it would particularly easy with the mouse-over circle, though, since you wouldn't be able to draw on it and it would be very difficult to implement non-rectangle colour maps.

I disagree. There are other native solutions that won't crash LabVIEW, are cross platform and you could probably make it look much better than the LabVIEW native control.

I haven't finished yet Agreed. Bug. I too couldn't preproduce it in 32 bit. However. You need both strides for the 2D array (offset= x*Stride_1 + y*stride_2). Granted LabVIEW uses a contiguous allocation but that also assumes packed and aligned. Not sure we can guarantee that on all platforms (Rolf will know). You can obviate the array allocation for this particular example by auto-initialising it on the first run (or when the length changes). You can remove the calculation of the length too since that is returned as one of the size parms. You can calculate the length as in the other examples but not calculating it improves jitter immensely. I also did your little trick with the wrapper which makes a nice difference here. too. The following was on LV 2021 x32. Compared to... Raster 2021_SR_1.zip

A warning about the ArrayMemInfo function. Be aware of whether it is returning a sub array or not. It can change even by changing VI properties and a plethora of other reasons.

I like that.

You used to be able to modify the GSW but in later versions they put it in a packed lib. The probe window is still my #1 focus of hate. The fact you can't resize string controls in it makes it dead to me

I'm nothing if not consistent. I have a first in, first out memory with limited buffer. I guess the buffer has reduced to less than 2 years in my old age. Not long now before I'm yelling at clouds, I guess.

Ok. Sweet. I get the same now. I tried it on some other functions that I thought might benefit but it turned out that the majority of the overheads were elsewhere. Is that feature sticky in that if it is set during design time it stays with the VI when loaded on a LabVIEW install without the ini settings?

Interesting. I only see a difference when Error checking is Max. Default and None produce no changes. I assume that's what you mean by "without the wrapper function"?

Well. just to be argumentative.... It is <almost> entirely equivalent. A type cast is used in AQ's original to convert between formats initially and assumes a particular memory format such that when the reverse is operated, it produces the expected result (consistent memory topology). Memcopy, of course, won't work with the LabVIEW type cast since the expected memory formats are different (and would be different on different endian machines and not portable). There are also a lot more checks and an allocation with the type cast, naturally. I suspect the performance boost that AQ sees by converting to a string first is to do with bypassing byte swapping-perhaps he can tell us in intricate detail why it is faster converting to a string first. The memcopy is doing a lot less work because the array initialisation is outside of the timing and a fixed size. You can move the array initialisation into the timing area to create the buffer on-the-fly at the cost of performance in order to generalise but it is still slightly faster. If then you check the length and allocate that amount on-the-fly, then you end up with a similar performance to the tostring trick, sans protection. Most of the differences will be to do with compiler optimisations. The take-away is that the type cast (rather than memcopy) won't crash labVIEW if you get it wrong, is portable and poke-yoke. Use it.