hooovahh

16 minutes ago, HYH said:

This is an old flaw. It was first mentioned in LabVIEW 2021 SP1, and reported fixed in LabVIEW 2022 Q3 :

But apparently not.

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.

1 hour ago, ShaunR said:

Support is always necessary.

I disagree. Large amounts of my code online have never required my support.

1 hour ago, ShaunR said:

That never happens.

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.

On 10/23/2023 at 2:20 AM, MikaelH said:

BTW, can you also update this library to make LV2023Q3 to build applications with these VIMs to work ;-).
We use these VIMs a lot, and in LV2023Q3 several VIs stops the builds complaining that "VI is not in memory".
And to get the App building to accept these VIs I have to replace your VIMs with the old style OpenG version :-(.

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.

On 9/26/2023 at 3:47 AM, ShaunR said:

Or, in other words, "A Manager". That's all managers are! Your value isn't diminished, you've just been given the opportunity to increase your skill-set.

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

On 9/21/2023 at 7:09 AM, ShaunR said:

Well. If I were your manager then I'd ask you to find a contractor that can do it in a week and task you with managing them. 

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.

22 hours ago, ShaunR said:

If an employer said we are switching to something else, I'd just shrug my shoulders,  load up the new IDE and ask for the project budget number to book to.

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.

1 minute ago, crossrulz said:

For 7-10 years, you will probably be fine sticking with LabVIEW and TestStand.  For those of us who are more like 20 years out, looking at alternatives is advisable. 

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.

8 minutes ago, HYH said:

"Future of LabVIEW" presented by Jeff Kodosky, the "Father of LabVIEW," talks about the beginnings and future of LabVIEW. (NIWeek 2016)

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.

14 hours ago, jlw186 said:

Is there a labview project example of this running on a crio/sbrio with embedded UI? I seem to get error 1055 with reading property nodes from front panel references and the HTML page is not being created when I run the publish VI on the controller.

There are complications with this.  On Windows the first thing it does it figure out where the controls are, and creates the template HTML pages and web code.  Then when it runs it can send the values of controls to the HTML pages, or send images of what the controls look like.

If I'm remembering right, on embedded devices, some of the needed functions won't work.  I think the get an image of a control doesn't work, even if the embedded UI is enabled.  And Writing to PNG using compression doesn't work.  But the good news is the values of controls can still be sent and received.  At some point I did have this working on devices with an embedded UI as a test and showed it here  It looks like some controls are in image mode, so maybe I'm wrong about it not working.  The code as it is today is already a bit of a mess, when it comes to examples and demoing the features it has.  So that code was an even bigger hack.  I do wish I had time to work on this because it is one of the cooler projects I've worked on, and the easiest 80% of the project is done.  But the last 20% would take a bunch of work.  So it sorta sits here in this sorta works, but needs some attention, stage.

First I'll mention that snippets aren't working recently on LAVA.  I messaged the admin but haven't heard anything.  Second I'm wondering why this can't be a native LabVIEW feature.  Has anyone made an idea on the Idea Exchange for probes to work on parallel For loops, where the P terminals can constant fold to a 1?  I'm also not sure why this works only in the enabled structure.  I wouldn't expect the structure to be a non-reentrant type function.  And it doesn't, when I put a wait in there as a test.

Okay it looks like you'll get an Out of Memory error on building. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019No1SAE&l=en-US