A few Linux bugs in LV2021

[Sparkette]

I love that Community Edition is on Linux now. That said, I've run into a few issues with it and I'm hoping someone can help:

• LabVIEW has issues with images from other applications in the clipboard. When I have something copied from KolourPaint (an open source MSPaint clone) LabVIEW will often crash, sometimes immediately, sometimes not until I try to paste it. (This happens immediately after launching it as well.) From other applications I've tested, LabVIEW appears to ignore the image entirely. If something other than an image was in the clipboard before the image, it'll paste that; otherwise, Paste will just remain disabled as if the clipboard were empty.
• A lot of times, I'll select a custom control using the "Select a Control..." right-click menu item, and it'll display the outline of the control for a split second, but then it'll go away as if I pressed Esc. I don't recall whether this has happened with subVI's, but it's possible. (edit: it just did, so yes.)
• Sometimes, often when I drag something on the block diagram, wires will suddenly move to illogical locations. One place where I've noticed this often is with tunnels on the bottom edge of a structure, where the wire will suddenly arrange itself so it connects from the left instead (while the tunnel remains on the bottom.)
• The audio input/output VI's don't work, instead saying the selected device is invalid. (This does not include the audio file ones, which work as expected.) Trying to place an "Acquire" or "Play Waveform" Express VI shows no detected devices in the dialog, and if I click OK anyway, LabVIEW crashes.
• Dragging and dropping files into LabVIEW does not work; instead, the files go to the window behind the LabVIEW window.
• I'm not sure whether or not this is actually a bug, but whenever LabVIEW opens a file dialog, it uses the crude built-in one, like in the Windows version when you select an LLB, instead of the normal system dialog. (If anyone knows of any way to replace the dialog with a custom VI, that would be great.)

I'm using Arch Linux with KDE Plasma, in case it helps.

Edited January 28, 2022 by flarn2006

[hooovahh]

Thanks for the info. LabVIEW Linux doesn't get much love.  Combined with the large variation in Linux environments can mean issues like these.  Can you post this on the dark side?  Is there a Linux desktop sub forum?  If not sending these to NI as a service request would also help.

[Jordan Kuehn]

1 hour ago, flarn2006 said:

• Sometimes, often when I drag something on the block diagram, wires will suddenly move to illogical locations. One place where I've noticed this often is with tunnels on the bottom edge of a structure, where the wire will suddenly arrange itself so it connects from the left instead (while the tunnel remains on the bottom.).

Perhaps this same issue that is a bug, per AQ's reply:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LV2021-Deactivate-Wire-Auto-Routing/idi-p/4183557

[Sparkette]

39 minutes ago, Jordan Kuehn said:

Perhaps this same issue that is a bug, per AQ's reply:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LV2021-Deactivate-Wire-Auto-Routing/idi-p/4183557

Looks like it; thanks for the link. Guess that one isn't Linux-specific. Though there aren't that many days in January left...

1 hour ago, hooovahh said:

Thanks for the info. LabVIEW Linux doesn't get much love.  Combined with the large variation in Linux environments can mean issues like these.  Can you post this on the dark side?  Is there a Linux desktop sub forum?  If not sending these to NI as a service request would also help.

When I do, is it okay if I just link to this thread here?

Edited January 28, 2022 by flarn2006

[hooovahh]

1 hour ago, flarn2006 said:

When I do, is it okay if I just link to this thread here?

You can, but it would probably be best to just paste in your issues and any example code that demonstrate the issue in the report.  That way the issue can be tracked more easily by NI.

[Dataflow_G]

6 hours ago, flarn2006 said:

• The audio input/output VI's don't work, instead saying the selected device is invalid. (This does not include the audio file ones, which work as expected.) Trying to place an "Acquire" or "Play Waveform" Express VI shows no detected devices in the dialog, and if I click OK anyway, LabVIEW crashes.

Yeah, LabVIEW's Linux audio support hasn't been touched in years. It's built on OSS, which was superseded by ALSA on Arch Linux in 2002. None of the Linux distros LabVIEW Community Edition supports ship with OSS support, but I believe it can be added via an ALSA-OSS translation layer. Also worth noting LabVIEW for Linux can only write 16-bit WAV files, and not IEEE float WAVs (which can be written in LabVIEW for Windows).

If you want to play/capture/record audio under Linux, I'm working on an open source, cross-platform audio library for LabVIEW called G-Audio. It's been tested under Arch Linux and CentOS, and supports playback and capture on ALSA and PulseAudio backends, supports writing PCM / IEEE WAVs, and can read WAV, MP3, FLAC, and Ogg Vorbis files.

[Sparkette]

8 minutes ago, Dataflow_G said:

Yeah, LabVIEW's Linux audio support hasn't been touched in years. It's built on OSS, which was superseded by ALSA on Arch Linux in 2002. None of the Linux distros LabVIEW Community Edition supports ship with OSS support, but I believe it can be added via an ALSA-OSS translation layer. Also worth noting LabVIEW for Linux can only write 16-bit WAV files, and not IEEE float WAVs (which can be written in LabVIEW for Windows).

If you want to play/capture/record audio under Linux, I'm working on an open source, cross-platform audio library for LabVIEW called G-Audio. It's been tested under Arch Linux and CentOS, and supports playback and capture on ALSA and PulseAudio backends, supports writing PCM / IEEE WAVs, and can read WAV, MP3, FLAC, and Ogg Vorbis files.

I see. Running LabVIEW through padsp appears to fix it, except the express VI's still crash LabVIEW when I click OK. Thanks though

Edited January 29, 2022 by flarn2006

[dadreamer]

On 1/28/2022 at 11:08 PM, flarn2006 said:

I'm not sure whether or not this is actually a bug, but whenever LabVIEW opens a file dialog, it uses the crude built-in one, like in the Windows version when you select an LLB, instead of the normal system dialog. (If anyone knows of any way to replace the dialog with a custom VI, that would be great.)

Might be worth trying to put useNativeFileDialog token into your config file (/home/<username>/natinst/.config/LabVIEW-x/labview.conf). Check both True and False values. upd: Doesn't work for me.

Then maybe try some third party dialog libraries out there, e.g. osdialog or Portable File Dialogs or Native File Dialog / Native File Dialog Extended , there are thousands.

Edited January 30, 2022 by dadreamer

[Sparkette]

7 hours ago, dadreamer said:

Then maybe try some third party dialog libraries out there, e.g. osdialog or Portable File Dialogs or Native File Dialog / Native File Dialog Extended , there are thousands.

I'm mainly concerned about LabVIEW's built-in uses of the file dialog, File→Open for example. Is there a simple way to replace that with a call to a third-party library?

[dadreamer]

On 1/30/2022 at 10:35 PM, flarn2006 said:

Is there a simple way to replace that with a call to a third-party library?

None that I've known of. It needs extra investigations, but I'm afraid no easy way around that.

upd:

At least you could try to adjust the File Dialog appearance, by replacing it with your own.

It doesn't have a block diagram and is in locked state. I suppose, the diagram is created on-the-fly, when the Dialog Editor opens a .rsc as it's always (?) empty anyway. The code to the buttons is assigned by the Dialog Manager API (defined in DIALOG.H; check LV 2.5 sources). Sadly dialogEditor token is not working in modern LV's, so you have to extract, alter and pack that VI "manually". Maybe it's better to experiment with LV 5-7, where the dialog menu entries are available.

Edited February 1, 2022 by dadreamer
additions

[Rolf Kalbermatter]

On 1/30/2022 at 7:21 PM, dadreamer said:

It doesn't have a block diagram and is in locked state. I suppose, the diagram is created on-the-fly, when the Dialog Editor opens a .rsc as it's always (?) empty anyway.

There is no diagram at all. The LabVIEW executable implements the functionality of those dialogs entirely in C(++) code and only uses the dialog resource to create the window. It's very important to NOT change the controls and their labels as that is how the code refers to them. You can adjust the size and color of elements and most likely even change the style of controls as long as you make sure that the control datatype and label ID remain the same but if you mess up, LabVIEW will crash hard.

[Sparkette]

As a side note, I'm pleased to see that you find my resource editor useful

[dadreamer]

I meant this second window. It actually allows coding there. But after saving and reopening all the code things are gone.

[Rolf Kalbermatter]

Yes the dialog resource is in fact a VI, but the diagram is never used no matter what you do. The LabVIEW kernel loads the dialog resource as a template but assigns its own (in C implemented) DlgProc to it which does the whole event handling. The diagram is totally decoupled from the VI as soon as the LabVIEW Dialog Manager loads the resource.