hooovahh

If you do reach out to NI they will likely ask for a crash dump. Here is a page on how to enable it and get it: https://nilrt-docs.ni.com/troubleshooting/lvrt-crash-dumps.html I've tried sending NI projects with weird behavior, in the hopes they could find and fix LabVIEW bugs. Some times it works out, but because of the nature of some configurations, and weird compile cache and deployment errors, it can be hard for NI to pinpoint a cause, and create a fix.

No you luckily quoted it, which left the context when the spam post was deleted. I did think about what that would look like so if you didn't quote them, I may have just decided to delete your post too. I also think the spam levels here are relatively low. But then again engagement with humans is relatively low too, so the signal to noise ratio is more noticeable.

The LabVIEW Fundementals thread is one for sure that gets confusing. Realistically it is probably 8 bots all talking to each other. But what they say makes sense, and some are points I could see a human making on these forums. One account got the most likes in 24 hours (at one), and I assume that was from an actual human. I apologize to any humans caught in the cross fire.

Well keep the reports coming when you see them. It just takes time to go through them all.

As is the case with most of these things, it is easy to tear down, but hard to build up. AI slop can cause problems to a forum, that take much more effort to clean up. Ever reported post pings me. I then need to review the thread, then evaluate how likely the member is spam, and decide what to do. Then repeat that many times.

I like it and I want to play around with it, but I feel like most of those examples you gave could be accomplished with subpanels, or 2D picture controls set to the top of the Z layering.

Okay that is kinda cool. Other than an on screen keyboard, what uses are there for this?

Individuals still are interested in maintaining the OpenG packages. They have been copied a few times, and several repos are on github. I think the most up to date ones will be from here. They look like they were last updated around 2 years ago. VIPM.IO hosts the packages, and you can make comments, and feature suggestions there.

I still leverage the VIT method in the New... VI >> From Template. It allows for selecting from a variety of New VI templates. Instead of overriding the installed functionality. Admittedly it is a couple more clicks.

2022 Q3 is still the large majority of our projects. Windows 11 support 64 bit RT, and things work fairly well. Yes like others have said some compile cache issues but very happy. We are migrating to 2025 Q1 as needed. I haven't used it as much as I have 2022 Q3, but it seems fairly good so far. I have seen a compile cache issue in 2025 Q1, and I have seen an RT related crash with XNet in development where the build was stable. So not all the confidence in the world but fine.

The code needs lots of work, but yes that is the start of something. I'm glad to see you leveraged Norm's image translation code, rather than trying to make something yourself and likely have worse performance. If you intend on having this be more dynamic you'll have to keep track of the relationships between nodes better. Right now you have a very static linking between two objects. If you add a third right now it isn't handled within the class. There's also a good amount of formula nodes. Once it is well understood I'd suggest trying to do it in pure G LabVIEW nodes since it will likely have better performance. They can obviously be wrapped into a nice subVI with a comment of what the code accomplishes. What is your eventual goal for this? How do you intend on using it in a larger application?

I know this post is ancient by internet standards, but I've been using LVMark off and on for years now. I recently posted a Hooovahh String package here on VIPM.IO. I plan on making a video demonstrating features of that package including LVMark some day. The LVMark code is mostly unchanged from the version posted here, just some comments and VIA_Ignore tags mostly. I do think there are places where performance could be better, but I've only ever used it on relatively small strings. There seems to be other LabVIEW Markdown libraries, like the one Ton linked to (but links seem to be dead), and a QControl here that has similar functionality. I do like the simplicity of LVMark.

Yes you make a good point. Maybe I just see it as friction when going to a built application. Like ideally you just tell LabVIEW this is my top level VI and if it runs in the IDE it should run in an EXE. Anything that gets in the way of that simplicity feels like an annoyance to me. But you are right once it is done once that's it. I think the explicit find for each class is more obvious. Like you said a developer may drop down a Find VI and it will either be broken (with the required terminal un wired) or they will need to find what they need. I think I do find the Class Constant method easier in times when you don't know what hardware you want, and you want to just use any. But admittedly that is quite rare and most applications are for a tester with a known set of hardware. I can do both of course, but maybe have the Find for that class be the VI that is on the palette. I don't understand what you are saying here. Are you saying that if the hardware uses a DLL for example, you won't know until you try to deploy to a target where that isn't supported? I mean the VI will be broken in the context of a Linux target, so that will at least clue in the developer before having to deploy it and see it doesn't work.

I've used a variation of this design in the past and as you said if you load it dynamically from disk, LabVIEW needs to be told to always include it in builds. If I provide VIPM package to someone, I don't think it is an obvious step that they should need to find my class and add it to an always include for builds. I don't need to do that for other APIs, like DAQmx for example. If you can rely on the documentation to have the always include, and you control on disk where things are, your dynamic load solution with naming of the class will work. If I want to avoid always include, and if I want the code to have to be brought as a dependency, I think there are only one of two options for forcing the library to be in memory, so the dependencies are brought along. Either have a class constant somewhere, or a class specific VI. It must be one of those two options right? That was my original question of which design do people prefer and use to force some code to be dependent on that class?

Looks like Jim went with the design where class constants are passed in as an array of classes to operate on like my first example.