Rolf Kalbermatter

Icons are the resource sink of many development teams. 😀 Everybody has their own ideas what a good icon should be, their preferred style, color, flavor, emotional ring and what else. And LabVIEW actually has a fairly extensive icon library in the icon editor since many moons. You can't find your preferred icon in there? Of course not, even if it had a few 10000 you would be bound to not find it, because: 1) Nothing in there suits your current mood 2) You can't find it among the whole forest of trees

Well, I have done a few minor updates to the library to fix a few minor problems with newer Windows systems. It's still active and used by some customers. What do you want to know about it?

Oops, sorry! 😀 But you found it already. 👍

Where you refering to this? https://lavag.org/profile/19157-jordan-kuehn/

I would consider that a bug in VIPM. It should not rename the DLL and linkage name in the VI in this case or at least offer an option to disable-that. But your solution with the Post Install works and is what I always do. VIPM always lacked a few features to properly handle 32-bit and 64-bit binaries. I haven’t checked in the latest version but there was no way to distinguish files to be only installed for 32-bit or 64-bit only and even if the latest version would support that I’m hesitant to use it as VIPM tends to create packages that won’t be installable by older versions of it.

A star before the file ending is translated to 32 resp 64, a star for the file ending is translated to the respective platform specific shared library file ending. Is your shared library name different between bitnesses? Otherwise you do not need a star at all before the file ending.

If you make that libmuparser-lv.* you can leave the default file ending for the shared libraries. .dll for Windows, .so for Linux and .framework or .dylib for Mac OS. And you don’t rename the default name of libraries under Linux but typically create a symlink with whatever non-versioned name you need.

It’s actually how Microsoft wants DLLs distributed with an application unless it is installed directly into the system (or GAC for .Net assemblies). For DLLs that get directly referenced by LabVIEW VIs it is not important as the application builder adjusts the path to whatever relative directory you told it to move the DLL but for other DLLs that LabVIEW and/or the application builder doesn’t know about it is important to place the DLL in a standard Windows searched location.

NI System Link, NI TestStand, NI Measurement Link, NI MultiSim/Ultiboard (barely) , NI LabWindows/CVI (pretty much not anymore), MATRIXx (not sure they still sell that other than to legacy customers), Diadem (not actively sold anymore), and a few others that they have stopped working on. Other than LabVIEW, TestStand and System Link, NI has pretty much stopped any other software development, so part of the down turn is likely that sales from those other software is dwindling as existing customers jump the boat and no new customers are boarding for them.

Well, the whole NI=>Emerson transaction seems to go as follows: 1) Shareholders from Emerson have approved the deal 2) Emerson created a wholly owned subsidiary in Deleware called Emersub CXIV, Inc for the whole purpose of merging with NI 3) Shareholders from NI approved the merger on June 29, 2023 4) After all the legalities have been dealt with National Instruments and Emersub CXIV, Inc will merge into a new company under the name of National Instruments, and Emersub CXIV, Inc will cease to exist. The end result is that National Instruments for a large part will most likely simply operate as is and be a fully owned subsidiary of Emerson Electric but for a lot of things simply keep operating as it did so far. If and what technical cross contamination will eventually happen will have to be seen. You could probably compare it to how National Instruments dealt with Digilent and MCC when they took them over. They both still operate under their own name and serve their specific target audience and for a large part were unaffected by the actual change in ownership. There were of course optimizations such as that most of the MCC boards where eventually actually manufactured and shipped from the same factory that also produces NI hardware. Digilent also has eventually taken over some of the products from NI that were mainly meant for the educational market such as myDAQ but also the Virtual Bench device which they sell under a different name but it is 100% the NI Virtual Bench device and also works with the same drivers.

There is no simple fix to that. In order to draw anything on a Windows GUI you do need GDI objects. Every Window is one, every subwindow, every icon or bimap is one, every line or arc could be one, every text can be even two or three. You can open them, draw them to the device context and close them afterwards but opening/creating them costs time so if you foresee to use them again it’s a pretty smart idea to keep them around instead of spending most of your program execution time in creating and destroying them continuously. The only thing LabVIEW programmers can do is to try to combine more operations into a single object and/or finding the objects that are rarely needed and pay the runtime performance penalty to recreate them each time instead of keeping them around. Also I’m pretty sure that 3D controls with alpha shading may look cool to some people but tend to increase the GDI object count substantially. Classic and Dialog controls are a lot easier to draw!

And the Scan From String does a greedy pattern match, this means the first %s will eat the entire string as any character matches %s and then there is nothing left for the other 7 %s to process => error 85 as the Scan from String can't satisfy the second %s. If you have a space as separation character as it seems you have from the format you show you should rather use following Scan From String format string %[^\s]\s%[^\s]\s%[^\s]\s%[^\s]\s%[^\s]\s%[^\s]\s%[^\s]\s%[^\s] For this you should also right click on the string constant and enable '\' Codes Display The format string basically says, take every character until you see a space and put this in the first output parameter, then take the space and repeat this for the remaining 7 output strings. Possibly 23 character could also mean that each substring consists of exactly 2 characters plus the 7 separation characters. If so you could also use: %2s\s%2s\s%2s\s%2s\s%2s\s%2s\s%2s\s%2s

You’re saying that an event registration terminal should behave like a tunnel? They are not the same thing as the name already says (and the symbol shows)! It’s also more like a shift register although the right side of a shift register can’t be unwired. And the behavior makes sense. For tunnels it can be a pitta to have to wire each output but it’s also desirable that it can be easily “reset”. And that behaviour was defined ca. 1986! For event registrations it is almost never needed to connect the right side terminal (I did that maybe once or twice in my entire LabVIEW programming). Alternative would have been to make only a terminal on the left side but then you couldn’t dynamically register an event. Inconsistent? Maybe if you take a puritan look, ,useful? Definitely! And I can assure you the LabVIEW team debated over this probably several weeks if not months before deciding on the current solution. The only improvement I could think of nowadays is to allow to hide the right side terminals!

That would be a management nightmare. There would be no possibility to handle more than one event registration to subscribe to the same even generator without very involved buffer management. By placing the event queue into the event registration object it is fairly simple. 1) Hey here is my event queue, post any event you get to it. 2) I only have to check that queue to see if there is any event to handle. Not some other queue that might or not might have events present that I already processed but need to remain in it because not all event registrations have yet gotten to read that event. There is a relatively cheap check needed in the event generator to see if the event registration queue is still valid before trying to post a new event to it but that’s much easier than turning the single.queue into a pseudo random access buffer for use with multiple registrations. Similarly the event registration needs to check that the event generator is still valid when trying to deregister itself from it on its own destruction but that’s again a fairly simple Is Not an Object/Refnum check.

That would make little sense. That event queue is owned by the registration refnum, and the registration refnum registers simply a callback in the event object. The event is able to have multiple callbacks registered as it "queues" them up internally. That's what makes it possible to have multiple registration refnums connected to the same event object. That makes resource management fairly easy, avoids polling and objects owning other objects. Once the event goes away it simply will stop posting any events to the registered callback (it forgets about the callback since it is non-existent). The event queue in the event registration object still exists until that event registration object itself is destroyed. And if you close the event registration refnum earlier it simply deregisters itself from the event.