Supress DLL Popups

[maluigario]

I am using a DLL that has been provided for LabVIEW that controls a power supply via one of the PCs ethernet ports.  I have made sure to properly handle all of the errors that leave the VIs provided.  However, there is still an odd popup that the DLL fires if I do not have the power supply connected:

As you can see, the popup is not the same as the error popups you normally get during "Automated Error Handling" (something which I had manually disabled and made no difference).  The library is, for some reason, not password protected or even read-only, so I can even show you the contents of the VI that launches this and even where in the execution it occurs:

So it is definitively occurring during the "Call Library Function Node" portion of the execution.  I had manually added an error indicator to the Error Out terminal on this node, and that did not prevent the popup.  So this is something beyond the realm of my experience entirely.

My question is: How do I prevent this popup?  During initialization of my program, I attempt to initialize the power supply even if it isn't connected so that I KNOW whether or not it is connected and can change behavior accordingly.  But with this behavior, the user will have to click "OK" on this dialog box any time this specific device is not connected even when the application is running in a way that does not require the power supply.  

[GerdW]

Hi maluigario,

I see two options:

1. Connect the power supply before starting your VI...

2. Live with this dialog...

The dialog is created inside that DLL, so you would need to change that DLL. To do so you need the (LabVIEW) project used to create it...

[maluigario]

Surely there must be some way to suppress events like this from called libraries.  It seems strange to me that you would want a library generating modal, blocking dialogs without there being some way to prevent them.

Let me also clarify that it is an LLB and not a DLL that I have for this device.  No idea if that makes any difference.

Perhaps there's another way around this one.  If I can determine that no device of the given name is connected before making the call to the library.  It is asking for a "Resource Name" as a string, but I am passing it an "instrument handle":

Is there a way to use a different VI to determine if a device called "Power_Supply" is even connected at all?  I can then skip trying to initialize it altogether.

[cbutcher]

This is a little bit of a long shot, but LabVIEW has a private property that suppresses dialogs. I don't know if it can/will affect this specific dialog (perhaps not).

I don't know what or where the property can be found, but Sam Taggart has a VI in his Class Manipulation toolkit that manipulates this property.

It can be downloaded here: https://gitlab.com/sas_public/class_refactoring_lib/blob/develop/Source/Class%20Refactoring/Suppress...

The licence is BSD-3.

If you find this works, you could then try finding the property directly (googling for .ini keys might be necessary).

If you have a LAVA account and prefer that, the same/similar VI is linked here: https://lavag.org/topic/17845-silently-close-a-scripted-vi-with-unsaved-changes/ (a few posts down, by Darren)

[GerdW]

Hi maluigario,

Let me also clarify that it is an LLB and not a DLL that I have for this device. No idea if that makes any difference.

In the image in your first post you are calling a DLL function using the CLFN: you are working with a DLL!

There is a (huge) difference: a LLB is an (old and mostly obsolete) library to bundle LabVIEW VIs (among some other LabVIEW related file formats) while a DLL is a library of functions, usable on a Windows OS.

If I can determine that no device of the given name is connected before making the call to the library.

How is the device connected? On LAN you can most often ping devices…

It is asking for a "Resource Name" as a string, but I am passing it an "instrument handle"

These are just labels…

Is there a way to use a different VI to determine if a device called "Power_Supply" is even connected at all? I can then skip trying to initialize it altogether.

Ping the device…

[JÞB]

---

@maluigario wrote:

Is there a way to use a different VI to determine if a device called "Power_Supply" is even connected at all?  I can then skip trying to initialize it altogether.

---

Yes there is!

[rolfk · Accepted solution]

---

@maluigario wrote:

Surely there must be some way to suppress events like this from called libraries.  It seems strange to me that you would want a library generating modal, blocking dialogs without there being some way to prevent them.

---

There generally isn't! A DLL can do whatever it wants to do and that includes calling a myriad of different APIs that could display a dialog box or even creating such a dialog box fully from scratch using the Windows user32 API. The caller of such a DLL has to live with that and can't generally disallow such things in any way.

As it looks this instrument driver is a so called IVI driver. This is a driver usually developed in LabWindows/CVI (but Visual C can work too), and the resulting DLL is then wrapped with a VI library to make the driver available to LabVIEW users too. The idea behind it is that an instrument developer only has to develop one driver and can support both LabWindows/CVI and LabVIEW users alike. The drawback is that the entire driver implementation is inside the DLL and therefore not easily debug-able for the user, especially if used from LabVIEW.

Have you checked the instrument driver network if there is a driver available for this device that is a native LabVIEW driver? Even if your exact model may not be supported a driver for a similar device from the same manufacturer might still mostly work. And since it is in full LabVIEW you can usually make such an "almost matching your model" driver very easily to work with your device with a little reading of the programming manual.

A starting point may be this Sorenson driver but I can't vouch for its compatibility with your model (we don't really know your model series number). 

[JÞB]

---

@rolfk wrote:

---

@maluigario wrote:

Surely there must be some way to suppress events like this from called libraries.  It seems strange to me that you would want a library generating modal, blocking dialogs without there being some way to prevent them.

---

There generally isn't! A DLL can do whatever it wants to do and that includes calling a myriad of different APIs that could display a dialog box or even creating such a dialog box fully from scratch using the Windows user32 API. The caller of such a DLL has to live with that and can't generally disallow such things in any way.

As it looks this instrument driver is a so called IVI driver. This is a driver usually developed in LabWindows/CVI (but Visual C can work too), and the resulting DLL is then wrapped with a VI library to make the driver available to LabVIEW users too. The idea behind it is that an instrument developer only has to develop one driver and can support both LabWindows/CVI and LabVIEW users alike. The drawback is that the entire driver implementation is inside the DLL and therefore not easily debug-able for the user, especially if used from LabVIEW.

Have you checked the instrument driver network if there is a driver available for this device that is a native LabVIEW driver? Even if your exact model may not be supported a driver for a similar device from the same manufacturer might still mostly work. And since it is in full LabVIEW you can usually make such an "almost matching your model" driver very easily to work with your device with a little reading of the programming manual.

A starting point may be this Sorenson driver but I can't vouch for its compatibility with your model (we don't really know your model series number). 

---

Looking at the pop-up Icon, the DLL was sourced from LabVIEW.  Why not see if you can get your hands on that project?

[rolfk]

---

@JÞB wrote:

---

---

Looking at the pop-up Icon, the DLL was sourced from LabVIEW.  Why not see if you can get your hands on that project?

---

I kind of doubt it. While the icon in the left top corner is a LabVIEW icon, this does not mean that the underlaying DLL is LabVIEW originated. Unless the underlaying library goes to some lengths, standard windows generated by it in any way will simply inherit the application icon from the caller.

Also the viOpen text really indicates that it is calling the VISA C API rather than the LabVIEW VISA Open node. In addition, writing a fully IVI compliant driver in LabVIEW is not exactly easy. That's usually the area where C programming is used. It's also not as important for a native LabVIEW driver. IVI is a rather complicated standard meant mainly to deal with the underdefined nature of standard C APIs.

[maluigario]

cbutcher:

This is a little bit of a long shot, but LabVIEW has a private property that suppresses dialogs. I don't know if it can/will affect this specific dialog (perhaps not).

I don't know what or where the property can be found, but Sam Taggart has a VI in his Class Manipulation toolkit that manipulates this property.

It can be downloaded here: https://gitlab.com/sas_public/class_refactoring_lib/blob/develop/Source/Class%20Refactoring/Suppress...

Thank you for the suggestion, but unfortunately, it did not work.  The VI itself is also password-protected, so I can't even see what it is he might have been trying to do.

GerdW:

In the image in your first post you are calling a DLL function using the CLFN: you are working with a DLL!

There is a (huge) difference: a LLB is an (old and mostly obsolete) library to bundle LabVIEW VIs (among some other LabVIEW related file formats) while a DLL is a library of functions, usable on a Windows OS.

I see now the source of my confusion.  The VI that I posted earlier was a VI that was packaged with an LLB that is distrubuted by Sorenson.  The VIs in the LLB themselves call a DLL which is installed elsewhere on my PC.  

Ping the device…

This software is distributed among a few different platforms and is meant to perform a few different roles, which is why we have an enum to represent which kind of power supply is connected.  On every platform, though, the power supply itself in NI-MAX is labelled as "Power_Supply".  So if possible, I do not want to start hard-coding LAN connection strings into the code.  I was looking for a way to reference the device using the NI-VISA/NI-MAX name.

JÞB:

The suggestion you gave got me started down the right path in my testing (I will show what did work for me in a separate post), but didn't work for my purposes.  Basically, if I use the VISA Resource selector, it will show me all of the resources even if they are not at the time connected.  So even if the Power_Supply resource is powered off, because it has been registered with NI-VISA, "VISA Find Resource Function" will still say that "Power_Supply" exists.

roflk:

A starting point may be this Sorenson driver but I can't vouch for its compatibility with your model (we don't really know your model series number). 

I had no idea that there was a repository for 3rd party LabVIEW drivers within National Instruments.  The ones you linked to definitely will work for the power supply whose DLL is giving me trouble, so thank you.  I think I found a workaround that doesn't require changing libraries, but I am going to keep this for possible future improvements.