combo box scroll with mouseover

[wb2nvy]

See attached front panel image. I'm running Labview 2009F3. I have 57 items in my combo box and when I run the main vi and the subvi appears and I click the arrow on the side of the combo box, my list appears with a scroll bar, but merely mousing up and down outside the front panel of the subvi causes the scroll to move accordingly. I'm not clicking anything, just mousing around. I have the subvi setup to "shows front panel when called". Is this normal behavior for the scroll bar?

A second problem is I set the location for this to appear using the vi properties, Window Run-Time Position. I select custom, Set to Current Position (after I put it where I want it), then check Use Current Position. The first time I run the main vi, the subvi appears where it's supposed to be. Every subsequent time it appears higher and higher on the screen. How can I lock it into the location I want it to be? 

[smercurio_fc]

I'm a tad confused. What subVI are you referring to? Are you saying the list that appears is a subVI? Ummm... why?

[wb2nvy]

In the image I attached of the front panel of the main vi, you'll see in the lower right quadrant a subvi that pops up when called. It has a string indicator with 2 buttons below it, continue and reset, all of which are partly obscured by the combo box. The list is part of the combo box in this subvi.

[smercurio_fc]

All that I see from the image are what appear to be front panel items of the main VI. I don't see a subVI. I don't see any kind of window border. I also don't see an additional item in the taskbar with the subVI name.

Please post your code. 

[wb2nvy]

I thought my questions were sufficiently generic to answer without code details, but here it is.

[smercurio_fc]

The issue with the combo box is there because the combo box has focus. So, when you move the mouse above/below the actual control it's still receiving input. This only happens when you're within a few pixels of the drop-down list. It does seem a bit strange, but the system combo box works the same way.

As for the positioning, I agree that something strange is going on there. I found that if you uncheck the "Use Current Position" box and set the position you want then it works correctly. This should be investigated by NI.

Other code comments:

• It is very poor practice to hard-code paths as you have. This means that if you want to  change the location of the save files you have to change the code. Even worse, you have the same location hard coded in multiple places, which means you have to remember to change it in many places. Even worser, you used a string control to set the path instead of a path control and the Build Path function.
• In the RESET VI instead of having a 1 sec wait use the Wait For Front Panel Activity function. You could also use a simple event structure.
• In the RESET VI there is no need to continuously update the string indicator with the same message. This is pointless drawing. Just place the writing of the value outside the loop.

[wb2nvy]

smercurio, thank you for the comments, and verifying that the combo box is behaving strangely and it's not just me. And doing what you suggested makes the subvi stable in its position.

I started using LV about 4 years ago, and since LV programming is only about 10% of my job, I obviously don't have the experience of a full time LV programmer. So I appreciate comments on my code as long as it remains civil and not sarcastic, as it often is in this forum. I changed the path as you suggested. I didn't know there was a Build Path Function but I found it and am using it so the large portion of the path isn't repeated and the part of the path that changes with each case is appended, however I don't see the advantage of it over a string entry. Can you explain? I still have to concatenate the components of the file name with strings since the path function wants to insert a backslash after each argument. I would not want to use the path control because it's extremely unlikely this path will be changed, and I wouldn't want to take up space on the main vi front panel with a control that's unlikely to be used, and the operator of this program should NOT be allowed to change the path. I moved the string indicator outside the loop. You are correct. I originally placed it inside the loop because I was going to change the prompt depending on other things but you caught me in mid-development before I could clean things up. That's part of my reluctance to post code here because it draws criticisms of things I know are inappropriate but would be cleaned up later after bugs are worked out.

Thank you for your inputs.

[smercurio_fc]

The main reason for not using strings for paths is that it makes it platform-dependent. Also, it is very easy to make errors when entering paths in strings and not realize it.

I'm not telling you you can't have a path hard-coded in your VI. I'm simply pointing out that it puts you into the situation where if the path needs to change (for example to a different drive), then you need to update your code. Every single time a person says the path is never going to change, the path eventually has to change. It's a rule. It's in the Bible. If you're going to have the base path hardcoded you should only have the constant in one place, and branch wires from it. At least that way, if you need to change it, you only need to change it in one place.