hooovahh

Oh yeah I'm not trying to convince anyone, I just was putting it out there in case others aren't aware of this style of messaging. I prefer the design I described it because it makes life easier on the developer using the API, at the expense of extra work on the architect making it.

For me each message is it's own user event that is a variant, that gets created at the start. Then you can use it as a publisher/subscriber paradigm because you can create an array of these user events and register for them all at once. This is great for debug since a probe can just subscribe for all user events and see all traffic between actors. The Variant has an attribute that is Event Name, that is pulled out so the one event case handles them all, but the name is unique. VI Scripting creates a case to handle each unique user event, with a type def on how to get the requested data out, and if it is synchronous, another type def to put the data back as a reply. New cases are created with VI scripting to generate the VIs for request, convert, response, and the case structure.

Typed Clusters takes care of most use cases with this. I have had times when two separate applications are talking to each other, and in those cases if the type def cluster changes, then both applications need to be built so the data matches.

The word I heard, was that this was the result of a code optimization gone wrong. NI attempted to add some code that would take shortcuts in loading things, and skipping things it didn't think it needed. Some of these code optimizations were fixed in 2022 Q3, but others remained. So I believe you will see the icons get wiped away in less scenarios in later versions, but even the newest public release today may see this bug. Hope you have SCC and can easily recover them.

How about halfway happy. Which is more happy then I'd be with nothing. I enjoy a community that shares code. Sharing is caring. I'm agree that stuff on VIPM.IO should have a bit more polish. But a random forum post doesn't require the test and rigor of a commercial product.

I disagree. Large amounts of my code online have never required my support. It's happened with me several times. I don't like speaking in these absolutes. These half finished projects have been extremely valuable to me over the years, way more valuable then having nothing. Often times I will take the code, polish it, add features, then post it online. Not as perfect but so someone else could add to it if they ever wanted. A community that only shares perfect code shares nothing.

I know you have an aversion to unnecessary support. But still I'd suggest you just post them in the code in progress section of LAVA. I've posted many random projects and VIs on LAVA and the dark side over the years and only my array VIMs, and CAN stuff ever get any questions or comments. Most of the time the community comments make these code projects better. And if I'm unwilling to improve them someone else can make the changes. As for the specifics of these XControls. I have had a need for a dynamic or ribbon looking interface which is why I made one using the 2D picture control. I should have made it an XControl, but those gave me so much edge case problems I just have it as a class. I did see a tab like XControl posted online, but it was very limited in how it worked and the community could probably use another example at how this can be done. I can't seem to find it now but I think it was on NI.com

Every year I have to ping Michael about adding the new version of LabVIEW to the selectable drop down. It is something on the admin side, not moderator side. I'm guessing he just wanted to save getting bothered, and added 2024 when he added 2023, believing that there would be a LabVIEW 2024 eventually.

NXG's file types were all mostly human readable. The front panel and the block diagram were broken up into separate XML sections. At one point someone asked about having multiple front panels, and it was shown that the XML structure supported from 0 to N front panels for any GVI. NI never said they intended on supporting any number of front panels other than 1, but I thought that would have been an interesting thing to explore.

You can also add additional controls for things like a dedicated set of booleans for expand or collapse, and move the selection up or down. Not elegant for sure. You can increase tree control fonts, and that helps with selection, but glyphs and other elements won't change in size. I did make an idea exchange for it.

Okay new version release 3.1.1.22. I had to flatten a few VIMs in the Filter 1D Array VIM until builds started working again. To be clear this is a bug on NI's side, and they sound like they will fix it, but I understand how frustrating it is to have builds fail for seemingly no good reason. I also made a few minor fixes for clusters, and a couple other data types.

The easiest way I've done this in the past is to have a transparent path control that takes up the whole front panel which is hidden. Then you look for the value change event on that path control which will indicate a drop took place. Here is a post with an example of this working. If you are looking to open a file type when double clicked in explorer, then you will need a second EXE to get called, and it can decide what to do. Like maybe open another instance, or detect if it is already running, and open it in that. I know this post is old but it is what I used to understand what was needed. Since then I've started using InnoSetup installers, and you can setup file association there as part of the install process.

Yeah it sure would be great if NI fixed that bug wouldn't it? Back in May I did open a service request with NI for a build issue related to VIMs. After some back and forth they did assign a bug number to it 2401803. The cause was a VIM with a VIM inside it, but no classes involved. Attached is the project which demonstrates the issue. For some reason the project takes a while to open, then once opened the VI runs fine, but the build to an EXE fails saying it isn't in memory. NI's advice was to use Disconnect Type Defs in the build. But in larger applications that causes different issues. NI has said this will be likely be fixed in 2024 Q1. When I filed that bug I told NI that I had users of my VIMs that would complain and that they should fix this. Because if I'm complaining, they are going to get others having the same issue. Also NI just posted LabVIEW 2023 Q3 Patch 1, which fixes a bug 2296528 related to VIMs. I haven't tested it yet but it is possible this fixes this build issue. Filter VIM Issue VI Not In Memory (1).zip

Okay new release 3.1.0.16 should fix the issues I mentioned.

Also great feedback thanks. Sorry about the type def input breaking. That was sort of needed. Previously you could wire any numeric to it and it would accept it as a VIM input, but I really did want to only allow that enum. So I made it a type def, then forced it inside to only allow that. I knew that would break things, but it is a simple fix and if I were someone like NI I could make the mutation automatic in previous versions. The filter not accepting references is not intentional. I added some performance improvement stuff, and I see how that this relies on the Search Sorted 1D Array, but some data types aren't supported in the sort function. In these cases the right answer is to not use that function, and fall back into the less performant method. Thanks for catching this it will be in the next update. Control references do work for filtering Scalar data types, just not filtering a 1D with a 1D. The filter only accepting an I32 is intentional, but yes I could see that any numeric should be accepted. I thought it would just coerce to the right type, just like the primitive index does. I'll remove the strict I32 input requirement.

Pretty weird right? I just noticed that recently. I've moved on to using the newer version with the Sort option, since it is better than the original. But I opened some legacy stuff and saw it was rotated like that. I had to relink some VIMs, and the whole purpose of leaving the old method was to preserve existing functionality, but now that is lost. Not sure how that happened. Thanks for letting me know. That being said I'm not sure I want to push out an update for such a small change. I'll see if I have any other Array stuff in my candidates folder and push out some other changes along with that in the future.

You're right that there are a few ways to do this. Having a separate library of Common Controls is one way to go about it. In this you only need to have Type Defs that are shared between two or more libraries. For me the overwhelming majority of the time a Type Def is only needed in one library. If I have a set of VIs that does some kind of thing and needs a cluster or enum I'll save it as a type def to go along with the library. Any library that needs to use that type def, is going to probably need it because it will be a constant, or a control, that calls a VI from the first library. And so in that case it doesn't really matter that the second library depends on the first because of the control, because it is going to call the subVI so that dependency requirement is going to be there anyway. So I'll just have one type def control in the first library. Sometimes I'll make separate Type Defs, that contain the same data in different libraries, but in the future they might not. So one library may have an enum with "Yes, No, Cancel" and named "User Response.ctl". Even though another library has the need for the same set of enum values, I might make one separate control for each library because while they contain the same data, they aren't directly related. This could also work for you. Even though the two libraries have the same data Waveform data, they could be decoupled. Wiring will then do an automatic coercion dot which is nice, but could lead to issues in some small cases.

Change is scary. Especially when it is forced on you. I guess that summarizes how I feel about this whole situation.

That would be the right attitude to have as a manager. But that also reduces my value to the company. Now instead of doing work, I have a guy, that has to hire a guy to get the work done. My value in the company stays very high assuming NI and LabVIEW are the accepted tools used.

My problem with this, is that for some tasks if I do it in LabVIEW it might take a week. And if I were asked to do that task it in any other language I'd ask for a year. Sure I can do anything my boss asks, but if I tell him I need a year to do something, all the sudden my value at the company is much less then it was earlier when LabVIEW was an option. There's reuse, work flows, templates, example projects, and tools already done if I work in LabVIEW and NI that I'd have to relearn, or recreate.

Can't I just retire 10 years earlier than expected? Or maybe I can become a manager that just tells people what to do, instead of doing the work.

When I saw your post I figured it would be an RT error I see all the time. Nope, never seen anything like that. I'd also suggest a reinstall of the RT module, and possibly of LabVIEW itself.

I get where Shaun is coming from here. There are some behaviors in LabVIEW that either weren't well defined, or up for interpretation on how it should work. Then a new fix would come to LabVIEW where all of the sudden those corner cases weren't the same. Events are one of those things I've also thought might change, but I'm glad to hear that likely isn't the case. I remember a presentation by Jack Dunaway years ago at NI Week I think that talked about some of the event behaviors, and how it has changed in some releases. This was in the 2012 era.

This video appears to be missing. But otherwise lots of good resources.

I think the oldest I have is 7.0 or 7.1 in physical form. These boxes of old stuff just look cool to me so I have them displayed in my office along with a few LabVIEW books, and boxes of older software like Windows 3.1. I do wish I had more just to display and show off.