ShaunR

Splitters are your friend. This is one app that I've had for a while. Splitters are used to segregate the different sections and most controls are just default ones. There are no issues with maximising etc. The hard part is the button bars and Tab Bar which are actually xControls. (this is the example for the buttons bars xContol) (This is the example for the tab xContol) The most annoying for me is the things you said you don't care about. lol.

"The software you are refactoring had one and it is too costly to change the training materials". How's that? It is likely that a great deal of pressure had to be applied to even allow a rewrite and the manager probably had a hard time arguing for a budget to do it. Getting hot under the collar over a button isn't a hill I would die on. I would concentrate of making my life easier supporting it going forward than what it looked like-which was decided a long time ago.

The glib answer is that LabVIEW is a tool for engineers who generally prefer function over form. The actual reason is that the LabVIEW UI is limited, difficult and clunky to modify from the defaults. Just pop up a menu for example (no icons, can't change the background etc). The ability to create our own controls is also fraught with issues and extremely time consuming. The the only real option is XControls - which are a bit hit-and-miss. Give on-the-fly theme changing a go and you will quickly run into trouble with many controls. Making a pretty UI can double or triple the project time in some cases. There is also the subjective nature of "good looking". I hate the flat, monochrome icons that are all the rage, for example. What I may think is "cool", you may think is ugly.

I vaguely remember some beautiful UI's. It might have been a coding challenge since there were quite a few - can't really remember now. I just remember thinking "wow, I'd never have the patience for that, but that is awesome". Mine tend to be very utilitarian with the occasional lip-service to aesethics.

Lots of applications have an exit button in toolbars. They tend to be older since menu's became the preferred way to exit as not all applications had menus in those days. But historically test and automation were full screen, single purpose applications - often with touch screens - and it's hard to click a window button if there is no window titlebar.

Stop isn't to close an application. It is closer to a reset. It is to stop/terminate/curtail the currently executing task and return the application to a known state. The application is still running. The application is still initialised and the application is still in contact with devices. In desktop terms; a "Stop" is to an exit/close as an exit/close is to a reboot. Not all applications need a Stop button (think of things like Notepad) but if you have a Start button you will probably need a Stop button.

. Yes. If my muscle memory hadn't kicked in it would have been paltry.

ECL 4.0.0

It's not my problem, so to speak, about how they accomplish it. Personally, I would go with an off-the-shelf HTML rendering engine for FP's - which is, in effect, what I have already done.

I think you are missing the point. We can handle *most* things in UTF8 due to the primitives we have but what we can't do is display any of them on a FP. I don't really care if that is a windows limitation or not. If NI have to write a UTF8 renderer for their controls, then so be it. While they are at it, they could make the nonsense we have to go through to colour text much easier too.

That sounds like I would be shooting all the toes off of my feet as well as the feet. We already have this for UTF8. What we can't do is display it (ignoring the file control for now). If you roll your trouser-leg up and poke your tongue out at the right angle; you might get the ini switch and the associated property to sort of work for some encodings. But I ditched that a long time ago in favour of HTML and I don't remember it working for UTF8.

We already have the UTF8 primitives that cater for 99% of cases The real problems are indicators and controls (I'm looking at you, file control). I would be happy if we could display and use UTF8 in controls and indicators. I don't really care about other encodings as I could always convert them to UTF8 for the edge cases. Also. Wouldn't need a special wire

I find it mildly amusing that a non-native English speaker knows more about my language than I do. Maybe if I had gone to Grammar School and learnt Greek and Latin, I would be more equipped to argue. However. I got an F in French so it probably wouldn't have gone well

If it's just the time you are working in LabVIEW-that is doable without writing something for windows. You could just monitor open LabvIEW windows and or projects (count them if you want). You can make it easier by namespacing VI's (e.g. myproject_someFunction) which, to be honest, I generally do as a matter of course. At a bare minimum and If you are working in projects, all you need is to monitor projects in memory and timestamp when they appear and disappear. Not folder activity-more of a project activity.

Nice. I guess there is something very LabVIEWy now!

This a blast from the past. SAE J1939 is an old Japanese protocol-the precursor to OBD. It has the same connector as OBD but slightly different pinout. If you look for software that supports early 90's Japanese car diagnostics, there used to be a few examples around. It's a bit hit-and-miss since, at the time, everyone was doing their own thing. If IIRC the early Mistsubishi's used it (FTO, GT, Galant) so a searching for J1939 with those names might reveal something. I very much doubt you'll find anything LabVIEWy so you will probably have to write a protocol driver.

Shameless plug but feedback would be great since there's a lot that's changed. A few more eyes on it would help immensely before going live. The Encryption Compendium for LabVIEW (ECL) has had a major update. It's completed and a couple of weeks away from release as the documentation is in progress so there may be a few errors on that front. It's a commercial package so the gibs free crowd will, I hope, be disappointed. So what's new? IPv6 support (Thanks Rolf for your help with that). I've been wanting this for sooooo long but it required moving away from the NI primitives and nasty text programming. I bit the bullet and now have it, although a lot less hair SFTP Since NI released their poultry offering I thought I'd productionise the SFTP I had in my back pocket for quite a while and offer something actually useful. It comes with a full client example and supports recursive uploads, downloads and deletions (be careful with that last one). It also uses events for progress and status feedback in a similar fashion to the Websockets below. The event topology will be come a common feature of protocols in future additions. Websockets The ECL is a better home than a separate product since it was very difficult to distribute when trying to support TLS. Reworked from the ground, up it sits nicely in ECL and is the start of more encrypted protocol support in the future. Oh yes. Almost forgot. The ability to use Windows Certificate Store because ... why not? (and I wish I had thought of it ) If anyone would like to play before its release proper in a couple of weeks time, I can give you a trial copy (valid for 30 days). PM me and I'll send you a link.

No idea (but highly unlikely). I've never used LabVIEW NXG and it's now defunct...so never will. Speaking of which. Does that mean we no longer have to call the proper LabVIEW "LabVIEW Classic"?

Not natively in LabVIEW. You have to use the IShellwindows interface in windows 10.

You didn't look very hard; did you! We've just been discussing the callback functions and posted examples of using them. The answer to your question though is no. you cannot use them in the way you are thinking.

In the Window menu on the LabVIEW toolbar there is an "All Windows" [last] choice (CTRL+SHIFT+W) that pops up a dialogue which you can sort. There is also a VI hierarchy and Class hierarchy graphical representation of VI's that are in memory that are accessible from the "View" menu in the toolbar. That may be easier for you if you are familiar with the hierarchies and the project is not too large (also highlights the importance of VI icons).

Nope. All the nodes are calls to the LabVIEW executable which houses the memory manager and you have most of what you need from the circular buffer example I linked to. Job done. I'll go to lunch.

One step at a time. Something about bridges and crossing them. After all. You have eloquently outlined the fall-back position.

Why have a work-around when you can have a solution?

You could implement it using the LabVIEW memory manager but it's not for the faint-at-heart. I once played with it for a circular buffer which isn't a million miles away from what you need. Oooh. Look. Words similar