LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

shared variables lost border

Hello,
Upon developing code on  my machine and moving it to a customer's, the shared variables lost their right and bottom borders. Upon saving code revisions there and moving back to my development machine, the borders are still missing (see attached image). New Shared Variables pulled from the library are correctly formed, but all the exisitng look like this.
 
Any Suggestions
 
PS I apologize if this comes through twice, I received an error on my previous submission

Data Science Automation

CTA, CLA, CLED
SHAZAM!
Message 1 of 7
(3,701 Views)
The missing borders also show up in the Help window (see attached). Also, double clicking and re-assigning the shared varible returns it to its correct state: however, there are two shared variable libraries with 100+ variables and 150 vis in this project...
Thanks!

Data Science Automation

CTA, CLA, CLED
SHAZAM!
0 Kudos
Message 2 of 7
(3,697 Views)

I can confirm this issue. I will post it to the bug list.

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 3 of 7
(3,668 Views)
I think I may have seen something like this before.  By any chance, does the customer's machine have its fonts setting set to large rather than normal, while your machine was set to normal?  I'm talking about when your right click the desktop,  properties, settings tab, advanced button.
 
I think I've seen it go the other way too where it seems like the shared variable has sort of shrunk in its space.  I had one PC set up at work with the fonts set to large (120 DPI) and another machine set to normal (96 DPI).  If VI files are saved on one machine and moved to the other, things like this seem to happen.
 
I have found that Labview is bad at handling the large font setting.  Back when we used Virtual Bench software for its O-scope and FFT (which I believe was written in LV), if I ran it on the laptop with the large font setting,  the labels on the buttons would be larger (OK), but the buttons would grow with the labels.  If the buttons were originally set up as side by side, they would then show up as overlapped.  It would be better if the Labview front panel used a defined font size rather than enlarging the font based on the Windows setting.  (I have found some other things that have problems as well such as poorly designed websites where the programmer coded the popup window to a specific size and did not allow it to be stretchable, yet the dialog text would increase based on this windows setting and the text would go out of the window and couldn't be read.)
 
My IT guy gives me a hard time about using the large font setting.  He says "You use a high resolution, but then go and enlarge the fonts using this setting which counteracts the use of a high resolution."  On the surface, that would seem to so.  But I like a high resolution for anything graphical such as Labview, FEA, AutoCAD, viewing JPEG photographs, etc., so I can see a lot on the screen at one time.  However, high resolutions, even on larger monitors, can cause such tiny Windows fonts, it can give me eyestrain.  I really think the underlying Windows operating system has not really done a good job of keeping up with the larger displays and even higher resolutions, but making it so that the text fonts are still a good readable size.  I just got a new work PC with a 22" wide screen LCD display.  So far I think I can live with the normal fonts Window setting, which helps with Labview and keeps it consistent with my development PC, but the font is still a little smaller than I would like.
 
Back to the SV problem.  What I remember is that some space gets allocated on the block diagram for the SV on the smaller font PC.  When the same VI is opened up on the other PC, the fonts grow, but that "window" of space for the SV does not grow with it.  I don't have a way to test this now, but try reselecting the variable, or deleting it and dropping a new one in its place.  I think that one will look okay on the 2nd PC.  If you create a sample VI on this customer PC with SV's, try taking that VI back to your original PC.  From what I remember, it will look like the SV shrunk, and the wires will seem to come up short.  It's like there is white space to the right and bottom of the SV.
Message 4 of 7
(3,617 Views)

Thanks for the information Ravens Fan! I think you are almost certainly right (I won't be on the customer's machine to check until next week), as the free labels moved around and changes sizes when I was over there as well. Those switched back when I came back, unlike the shared variables.

You are also right about the double-click and replace. Any newly-dropped or re-defined SV look just fine on either computer.

I still seem to be in a bit of a pickle. Although this is deployed to a cFP as an executable, we also transfer the source code to the customer. I don't want to have to tell them to change their display settings on their personal computers to suit us, but neither do I want to deliver bad-looking code. When I next follow up on the SRN for this, I will be sure to bring up the text-display issue with the AE, that may lead us in the right direction on how to avoid this or fix it quickly.

Thanks again!

Mellobuck

PS I started on Virtual Bench myself - back during LV 5.0 🙂

Message Edited by Mellobuck on 06-26-2007 11:47 AM


Data Science Automation

CTA, CLA, CLED
SHAZAM!
0 Kudos
Message 5 of 7
(3,605 Views)

Mellobuck wrote "but neither do I want to deliver bad-looking code."

See reply #66 in this thread. Smiley Wink

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 7
(3,588 Views)

to be in a bit of a pickle. Although this is deployed to a cFP as an executable, we also transfer the source code to the customer. I don't want to have to tell them to change their display settings on their personal computers to suit us, but neither do I want to deliver bad-looking code. When I next follow up on the SRN for this, I will be sure to bring up the text-display issue with the AE, that may lead us in the right direction on how to avoid this or fix it quickly.


If you think you'll have political issues with trying to convince them to change their Windows settings,  maybe  the choice would be to change the setttings on your computer to match theirs (once you know exactly what size they are using) for as long as you are working on their project.  Once you are done and have delivered the code to them, you can change back to whatever settings you like.

Having this issue with the block diagram is a nuisance, but not the worst thing in the world.  If you are lucky like Ben's thread, no one will see it.  I think your bigger issue is how it affects front panel objects such as buttons and labels.  What would look good on your PC won't look so good on theirs.  And unless you are running some embedded application like on a compact Fieldpoint, they would certainly be looking at the front panel on a PC screen.

(Edit, rereading your message I see you are putting this on a cFP.  So hopefully front panel issues won't affect you from a general user's interface point of view.)

There may be ways to adjust the sizes, screen positions, and other property nodes of front panel controls and indicators programmatically based on what the Windows settings are (font size, resolution, etc.) so that it looks good on any machine.  But that would require a ridiculous amount of programming.

Good luck!

Message Edited by Ravens Fan on 06-26-2007 04:04 PM

0 Kudos
Message 7 of 7
(3,578 Views)