ShaunR

We've had these arguments before. I always argue that It's not for me to define the implementation details, that's NI's problem. We already have blocking events (the Panel Close? greys out the "Lock Front Panel" checkbox because it's synchronous). The precedent is already there. What I think we can agree on is that the inability to interface to callback functions in DLL's is a weakness of the language. I am simply vocalising the syntactic sugar I would like to see to address it. Feel free to proffer other solutions if events is not to your liking but I don't really like the .NET callbacks solution (which doesn't work outside of .NET anyway).

Not really, although I suppose it is in the same category as what I would propose. I mean more like the "Panel Close?" event. The callback would be called (and an event generated). You would then do your processing in the event frame and pass the result to the right hand side to pass back to the function (like the "Discard?" in the "Panel Close?" event). Of course. Currently we cannot define an equivalent to the "Discard?" output terminal. They'd have to come up with a nice way to enable us to describe the callback return structure.

Indeed. However, NI *should* have been aggressive in correcting that. I agree. Lazarus is the Open Source equivalent and I use a variation called CodeTyphon. But it highlights that even if LabVIEW is considered "vendor software" it should be on those lists as it is more of a programming language than HTML/CSS (as you point out). There could be no argument against inclusion, IMO.

LabVIEW never seems to even be listed on programming statistic websites. I refuse to believe (also) that LabVIEW has less programmers than, say Raku. Hopefully Emerson will aggressively promote LabVIEW on these kind of sites to raise visibility. NI failed to do so consistently.

I've always been suspicious of Google Trends because it doesn't give context. The following is C++ but I refuse to believe it's marching to oblivion. But it's fun to play with

Happy? Or do you mean grateful for small mercies? You wouldn't have been happier with a documented and example laden product that you can ask questions about and actually works? No. There is too much of this thinking around nowadays and it annoys the hell out of me. We (programmers generally) used to be better than this. The rigor and community that made OpenG tools is definitely gone now. I'm not quite sure who is to blame for this mindset creeping in but it's just not good enough BTW. I also get just as annoyed with "Beta" releases or, as I call it, "Still Not Working". Oh well. Back in the private toolkit it goes. Maybe one day I'll get around to it but it's clear that even if I did release it to the community as-is, it'd just be the spawning point for variants which, quality wise, would be just as bad, if not worse.

Different philosophies that we probably will never agree on. But in this particular case; I have working code with no known bugs and the price for using it is for someone to take responsibility and ownership of it.

Support is always necessary. That never happens. It's why there are so many half-finished and buggy projects on github. If I'm not prepared to release and support it, I'll either find someone that can or not release at all. What you've never had, you don't miss-right? One day I might get the energy and time-window, but don't hold your breath. Both xControls use the 2d picture control for the button/tab bar. You can add buttons/pages either at design or run-time. Where things might be different of how one envisages these things working is that the buttons are, in essence, callbacks. Pressing a button invokes a VI (which is why it's called the Execution toolbar) but most of the features are around managing the buttons/panels. Both the toolbar and tab bar work very similarly that way (tab bar obviously shows the VI in a sub panel). They are pretty feature complete. I suppose the tab bar could add an optional close icon but I never needed it. Hmmm. Maybe I'll add that now .... perhaps not

I like your optimism. Maybe you are right. Emerson Reports Fourth Quarter and Full Year 2023 Results; Provides Initial 2024 Outlook Interestingly, Europe seems to be their biggest growth.

Device drivers are on a separate installation DVD (it'll be 10's of GB). While they are probably on the FTP site somewhere, you can download it from the main NI website.

A long, long time ago in a galaxy not so far away I developed two xControls in order to create a VI installer. The VI Installer hasn't really gone anywhere but the xControls that it used were for a Toolbar and a Tab Control. (The string indicator which supports colours on the tab page below was another but that is already available - Markup String). The two xControls are pretty well defined and feature complete but for them to be introduced into the wild, they need "productionising" (documenting and tidying up FP/diagrams and creating VIPM installers). I've sat on them for years so it's not going to be me that does the last few percent and I don't want to be the one that people go to for support (I have enough out there already that I have to support). So if someone wants to take up the mantle, give me a shout and I'll figure out how to release them. The XControls are self contained with their own examples: The "Execution Toolbar" xControl example. The Tab Control xControl example: If no-one is interested then I'll keep them in my private box and sit on them for another decade.

Not a huge leap but an improvement on events (IMO) would be Named events (ala named queues). Events that can be named but (perhaps more importantly) can work across applications in a similar way that Windows messages can be hooked from an application-all driven from the Event structure. I initially experimented with a similar technology when VIM's where first discovered (although it didn't work across applications). Unfortunately, they broke the downstream polymorphism and made it all very manual with the Type Specialization Structure - so I dropped it. Another is callbacks in the Event Structure. Similar to the Panel Close event, they would have an out that can be described. But getting on to the LabVIEW GUI. That needs to go completely in its current form. It's inferior to all other WISIWIG languages because we cannot (reliably) create new controls or modify existing ones' behaviour. They gave us the 1/2 way house of XControls but that was awful, buggy and slow. What we need is to be able to describe controls in some form of mark-up so we can import to make native controls and indicators. Bonus points if we can start with an existing control and add or override functionality. All other WISIWIG languages allow the creation of controls/indicators. This would open up a whole new industry segment of control packs for LabVIEW like there is for the other languages and we wouldn't have to wait until NI decide to release a new widget set. At the very least allow us to leverage other GUI libraries (e.g. imgui or WXWidgets).

He should have. All the stuff he needed was on the NI site that I gave him a link to.

Looks like you have a custom theme in Windows where the cursor is defined. If you look, it changes from a left-pointing arrow to a right pointing arrow.

I cannot replicate this behaviour. (LV 21.0.1f2 )

We need more Xerox Parc and less Trailer Park.

Well. C++ is just as old and C is 10 years older - so go figure! The whole software discipline hasn't really moved on in the last 60 years (check this out!) and while I do see AI changing that, it's probably not in the way you think. If AI is to be instrumental to programming it must come up with a new way of programming that obsoletes all current languages-not automate existing languages. Software needs it's Einstein vs Newton moment and I've seen no sign of that coming from the industry itself. Instead we get more and more recycled and tweaked ideas which I like to call Potemkin Programming or Potemkin languages. I disagree. LabVIEW, so far, has been immune to AI but it has also been trapped in the Potemkin Programming paradigm (ooooh. PPP ). It needs another "Events" breakpoint (when they introduced the event structure and changed how we program). Of all the languages, LabVIEW has the potential to break out of the quagmire that all the other languages have languished in. What we don't need is imports from other languages making it just as bad as all the others. We need innovators (like the guy that invented malleable VI's for funsies) only in their 20's and 30's - not 70's.

You've really been gulping down that AI coolade, huh? I was going to mention PIL but IIRC it only supports standard tags (like the .NET that you criticized) so didn't bother to mention it.

Being picky vs Can't be both (and that's 10ms) However. You have a timing issue in the way you benchmark in your last post. The middle gettickcount needs to be in it's own frame before the for loop.

With the replace array it makes no difference but in your original it made about 10ms difference (which is why I thought it was a compile optimization)

What's interesting about ensegre's solution is the unintuitive use of the compound arithmatic in this way. There must be a compiler optimization that it takes advantage of.

My go (improvement of ensegre's solution ). SR_demo.vi Original: 492 ms ensegre original: 95 ms ensegre with multiply by 3 instead of 3 adds: 85 ms Conditional indexing: 72 ms Replace array (this one): ~20ms.

Didn't your AI guru suggest exiv2?

Back-saved to 2009 Untitled 1.vi BTW. Snippets don't work on Lavag. Always post the VI.

Nope. Not gonna fly, I'm afraid. This is the problem with LV POOP. I like the bit at the end-a video to show us just how complicated it is. Is this a Test Stand lite? Or is it actually a test framework for unit testing?