ShaunR

And that's another big reason why ECL won't be available in Linux. It was ok when it used the NI binaries but the switch to standard OpenSSL binaries means that the CLFN usually loads system wide binaries (even if you define a path) and there is no way for LabVIEW to use "RTLD_DEEPBIND".

The problem with test stand is it tries to be all things to all people. IMO, simplifying is best. I haven't used TS for quite a while but when I did, I offloaded all tests to LabVIEW and just used it basically as a script. I had a VI with command/response capabilities (via TCPIP) which meant that TS sequences were a list of operations and just sent strings to execute tests and take measurements. One nice side-effect of the TCPIP meant that you could also execute tests remotely so an operator didn't even have to be sitting next to the machine the tests were running on (quality engineers loved that they could run tests and calibrate from their desks instead of going out to the machine).

I had a girlfriend like that. It turned out that her father used mix metaphors for comic effect but she didn't realise and thought it was the correct metaphor. When she said "everyone says it like that" what she meant was "my family says it like that"

Not that so much but he might be right and I've been using an eggcorn for my entire life.

A malapropism is similar but more common for comedy because it doesn't need to make sense in context (so it's easier and funnier).

I love Rolf's eggcorns. I never point them out because he knows my language better than I do.

it was meant tongue in cheek and specifically chosen because you've done it a million times (probably). I wonder what the forum mark-up is for that?

Don't have that problem with dynamic typing. Typecasting is the "get out of jail" card for typed systems. This one seem familiar? linger Lngr={0,0}; setsockopt(Socket, SOL_SOCKET, SO_LINGER, (char *)&Lngr, sizeof(Lngr)); DWORD ReUseSocket=0; setsockopt(Socket, SOL_SOCKET, SO_REUSEADDR, (char*)&ReUseSocket, sizeof(ReUseSocket));

Oddly specific. I would want a method of being able to coerce to a type for a specific line of code where I thought it necessary (for things like precision) but generally...bring it on. After all. In C/C++ most of the time we are casting to other types just to get the compiler to shut up. They broke PHP with class scoping. They are now proposing breaking it more with strict typing. Typescript is another. It's the latest fad.

Actually. your particular problem is that the variant type is only a half-arsed variant type. It's easy to get something into a variant, but convoluted and unwieldy to get them out again. I think "Generics" were supposed to resolve this but they never materialised. I shake my head with the recent push in the software industries to strict type everywhere. Most of the programming I do is to get around strict typing.

If only there were a way that one could use strings to define the event. We could call them, let me see, "Named Events"?.

There is a "best practices" document (this too) but I suspect you are looking for a less abstract set of guidelines.

We have the Start Asynchronous Call for creating callbacks in LabVIEW. There are a couple of issues with what you are proposing in that callbacks tend not to have the same inputs and outputs. What we definitely don't have, at all, is a way for implementing callbacks for use in external code (in DLL's). While what I'm proposing *may* suffice for your use case, it's the external code use case where LabVIEW is lacking (which is why it makes Rolf nervous ).

It's only software One isn't constrained by physics.

None of that is a solution though; just excuses of why NI might not do it.

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.