How often is LabVIEW and NI hardware actually used in industrial applications?

[wiebe@CARYA]

---

@altenbach wrote:

---

wiebe@CARYA wrote:
But those projects are not incongruous. That (fun) thread isn't meant give an impression of normal LV usage but quite the opposite.

---

Not only that, but for really well written LabVIEW applications, the UI is so customized that you would never know that there is actually LabVIEW under the hood. For example, have a look here.

---

I know 😉:

[Hooovahh]

[Intaris]

We did a major overhaul of our UI some years back. Customised controls, developed a standard colour palette, standardised practically all controls, made a lot of custom buttons and so on.

Did not look very LV when we were finished. A lot of customers remarked "Oh, so you've stopped programming with LabVIEW.". Lol.

But lord it was hard.....

[altenbach]

However: For us programmers, it is important to not judge a VI by its front panel.

It's the diagram where the true artistry comes in! Else its just putting lipstick on a pig (as we've seen many times in the forum here). 😄

[Hooovahh]

"Well I mean it obviously isn't written in LabVIEW." (This is Hooovahh thread)  But yeah I agree it can take some effort to get UI and UX working in a non-LabVIEW looking way.

[AeroSoul]

How do you even customize the window that much?

I get the buttons, the menus, graphs etc., but how do you customize the outer window?

Just disable default LabVIEW window and do it from scratch by hand (including programming the minimize/maximize and exit buttons?)

[wiebe@CARYA]

---

@AeroSoul wrote:

How do you even customize the window that much?

I get the buttons, the menus, graphs etc., but how do you customize the outer window?

Just disable default LabVIEW window and do it from scratch by hand (including programming the minimize/maximize and exit buttons?)

---

Make a borderless (not really possible in Windows 10) VI with a subpanel. Put all UI's in the window 'template'.

Making a fake title bar is hard. I've used pure LV, by overlaying a 1% transparent window over the template when moving in the title bar (and left right top bottom borders), and catch that window's events.

Atm I switched to windows APIs that change the title bar region to the template's title bar. 

Of course, the different template methods (none, windows, LV) are in a class hierarchy, so I can switch, even when running (applies to new windows).

Custom menu's are plain hell (multiple screens, screen limits, menu's in modal windows, etc., etc.):

I've considered switching to .NET, but at this stage the pure LV method is working. Pre-OO, so messy inflexible programming. 

[AeroSoul]

I assume the keyboard shortcuts are just an event catching key presses and an if statement executing desired functions?

[wiebe@CARYA]

---

@AeroSoul wrote:

I assume the keyboard shortcuts are just an event catching key presses and an if statement executing desired functions?

---

Basically, yes.

Menu items spring from a few string resources. Menu's are enabled by user level, and the levels are adjustable in a (signed) configuration file. But in the end, a key event is handled exactly like that.

When a shortcut is used, a menu item is activated, or one of the buttons is pressed, a user event is send. So all 'menu' actions are channeled through this user event, decoupling all the GUI complexity from the code handling it.

Even when I have LV menus, I usually generate a user even or value signaling event (sometimes in a callback event). This enables me to trigger a menu item from code, which is very convenient.

We're getting OT here 😊...

[AeroSoul]

Hey, i've never done a GUI like this, but i want to someday and this is useful stuff.

The menu we have right now is probably like 10 years old and when i tried to slightly update it once, we got half a dozen calls about things not working. Mind you, these instruments are operated by scientists, so i'd expect they could read a button label.