NetworkVariablePopup error -90

[ElectroLund]

I'm using the NVBrowser.cws example project listed in the help.

On one computer, the call to NetworkVariablePopup returns a -90 which (with the help of GetGeneralErrorString) gets decoded to: "The attribute value passed is not valid".

This is an odd error, since the only attribute for NetworkVariablePopup is the pass-by-reference pathname.

Now, on another computer, NetworkVariablePopup is working fine in the same project.  What is the problem here?

[Johannes_T]

Hello ElectroLund!

The fact that you are receiving that error, on a specific machine is indeed strange.

Can you provide more details please about your setup?

1. What version of LabWindows/CVI (both ADE and Runtime) are you using?
2. Is there any specific setup on the first machine (eg. firewall, other network access settings) different from the second machine, that you think it might cause the problem?
3. Can you reproduce the error using a simpler (even a basic) CVI application, in which you are just calling NetWorkVariablePopup? Which is the code needed for reproducing the symptom?

Best regards!

- Johannes

[ajenkins]

I'm not the OP, but we see a similar thing here too.  Works fine on two computers, but a third has the error sometimes.  All are Windows 8.  LabWindows/CVI 2013 SP1 and SP2.

It is definately the call to NetworkVariablePopup() that causes it, somewhere in the drawing routine of the table I think.  It seems to have something to do with the resolution settings, or maybe the external monitor?   Through some combination of rebooting and changing resolution settings, we were able to get it to go away, and then it came back later.  I'm still looking into a reliable way to reproduce it.

[Johannes_T]

Thank you ajenkins and ElectroLund for reporting this potential issue!

It would be very helpful for us if you could provide some code, or a project, that we could use to reproduce the symptom, in order to identify the exact cause of the problem.

Also note that NetworkVariablePopup is part of the Programmer's Toolbox library. This means that you can build and debug the function and determine exactly which underlaying function returns the error code -90.

Best regards!

- Johannes

[ElectroLund]

---

@Johannes_T wrote:

1. What version of LabWindows/CVI (both ADE and Runtime) are you using?
2. Is there any specific setup on the first machine (eg. firewall, other network access settings) different from the second machine, that you think it might cause the problem?
3. Can you reproduce the error using a simpler (even a basic) CVI application, in which you are just calling NetWorkVariablePopup? Which is the code needed for reproducing the symptom?

---

1) Both machines have CVI 2012 SP 2, 13.0.2 (278).  How do I find the runtime version?

2) I'm certain there are nuanced differences between the two machines in firewall.  I wouldn't know where to begin in expressing all of them, beyone screenshots.  Blecht.  Network differences are vast.  My development machine is on my corporate network.  This other failing machine is a production computer, which is not on the same network, but instead a local file server without internet access.  The two computers are both Win 7, 64bit.

3) Yes, using your example project which demonstrates the NetWorkVariablePopup function is about as lean a project as I can do, and this will fail on the production computer, but not on my dev computer.

Can you elaborate on how to build the popup function?  Where is its code located?

[ajenkins · Accepted solution]

Within NetworkVariablePopup(), near the end, there is a call that fails:

errChk(Browse(&data));  (approximately line 1820 of toolbox.c)

Within Browse(), line 2336 or so, you will see the following code:

if (data->showDataTypes)
{
     // NOTE - We have not yet populated all the tree nodes (folder, variables, etc).
     // So get the width of the machine column and arbitrarily set the width to twice that.
     errChk(SetColumnWidthToWidestCellContents(data->panel, data->tree, 0));
     errChk(GetTreeColumnAttribute(data->panel, data->tree, 0, ATTR_COLUMN_WIDTH, &colWidth));
     errChk(SetTreeColumnAttribute(data->panel, data->tree, 0, ATTR_COLUMN_WIDTH, 2 * colWidth));

     errChk(SetTreeColumnAttribute(data->panel, data->tree, 1, ATTR_COLUMN_WIDTH,
             treeWidth - scrollBarSize - 2 * frameThickness - 2 * colWidth));
}

Printing the values of the variables on the offending machine, I see that in my case:

treeWidth=380, scrollBarSize=16, frameThickness = 3, colWidth=199

Which means that, treeWidth - scrollBarSize - 2 * frameThickness - 2 * colWidth = -40, so that last line fails on the negative number with an invalid attribute code -90.

I modified mine to protect it with a hardcoded lower limit as follows:

if ((treeWidth - scrollBarSize - 2 * frameThickness - 2 * colWidth)>20)
{
    errChk(SetTreeColumnAttribute(data->panel, data->tree, 1, ATTR_COLUMN_WIDTH,
           treeWidth - scrollBarSize - 2 * frameThickness - 2 * colWidth));
}
else
{
   errChk(SetTreeColumnAttribute(data->panel, data->tree, 1, ATTR_COLUMN_WIDTH,
             20));
}

 This solved the problem for me for now and I am now able to call NetworkVariablePopup() on that machine. 

(But probably someone at NI should implement a real fix.  Different computers returned different values for colWidth, so there may be something in that calculation that needs to be looked at as well.)

[ElectroLund]

ajenkins, great fix!

I agree, we need a real patch in toolbox.c, as our modifying that file will get wiped with each update to our software.  These two functions (NetworkVariablePopup and Browse) have so many other dependencies in toolbox.c, I don't see an easy way to copy it over into my local application.

So for now, I've just modified my toolbox.c.  Thoughts?

[ajenkins]

Glad it worked for you too.

I have created a service request/ bug report #7491305 referencing this thread.  Let's see what they say.

[GatorChomp]

Hi Everyone, 

We are tracking this behavior under Bug ID #463586. Please follow the LabWindows/CVI release notes and patch notes for bug fixes which will be referenced by the Bug ID.

In the meantime, the work around provided by ajenkins should resolve the behavior when it is encountered.