I'm working as part of a team of developers using Windows XP and CVI 2010. On several occasions someone else has edited a UIR I'm working on, using a different machine to do the edits, not touching "my" part of the UIR (separate panel) at all--with the result that some of the fonts on my panel resize. For example, I had some text defined to be Arial 12 point, but it's suddenly become Arial 13 point after the other developer made his change.
I have to believe something about the other developer's local settings, related to fonts, propagates to the UIR and screws things up for me. It's probably not the Windows display settings accessible from the Control Panel, because a third developer using a third machine says the display looks fine with none of the symptoms I'm seeing--and that developer's Display settings are the same as the ones on the machine I'm using.
I've seen a couple of forum threads, years old, where CVI has behaved this way, but apparently those problems are related to Metafonts (which I'm not using) and/or older OS's. However, I've found no other references that give any hints.
Has anyone had similar problems? Is this a known issue with CVI 2010? Besides fixes or workarounds, any help at all will be appreciated.
this behaviour could depend on the resolution adjustment you have set for the panels: if set to something more than 0 and your collegues have screens with a different screen resolution than yours the effect is that objects are resized when the UIR is opened. Saving the UIR makes the modification effective to you too.
Well, nothing seems to change but font sizes. The font sizes actually changed from what I originally set them to (I used the UIR to set the sizes). I would think that setting a scaling attribute like the one you mention would cause everything to scale. Although I doubt that setting affects everything I'm seeing, I can experiment. Unfortunately it would be difficult, maybe impossible for this project in practical terms, to coordinate with five or six developers in different places, asking them to experiment in conjunction with me.
I thought of another piece of information. I set my panels to use Windows-style controls whereas none of the other developers do. I hate to change that because the Windows-style controls look so much better to me than CVI-style controls. But I may have to change to CVI-style if that's a solution.
I want to observe that the behavior I'm seeing out of CVI isn't good. Example, I was relying on the "number of visible rows" attribute of a table to distinguish between that table and a similar one that has a different number of rows. The changed font size broke my code because it changed the number of visible rows (same ones were all visible in some sense, but not all the row space was shown, and querying the attribute gave a different value after the font sizes changed). You can argue that I should have queried some other table attribute (label text?) or otherwise done things differently (relying on calling environment to identify the table somehow). Maybe so, but NI should fix this problem--I do see it as a problem. I don't think the UIR should be a repository for machine-dependent settings.
Thanks very much for the help, and watch this space.
I can't explain why the fonts are changing in your panel. If you don't have the resolution adjustment or the scale contents on resize options enabled on your panel, then I can't think of any reason why your Arial 12 fonts would be changing to Arial 13. To find out exactly why this is happening, like you said, you'd have to work with your other team members in doing a few tests to see if you can narrow down the source of the problem. For example, is the simple act of loading the .uir in their computer, and then resaving it without making any other changes, sufficient for the fonts to change?
One pratical suggestion I can give you now, however, concerns your table rows. If you enable the Auto Size and Scroll (when loaded) option, then you can guarantee that the number of rows will remain constant, even as your font sizes change. In fact, that's the reason for the this option -- when you use a system-dependent font (like NI Dialog) it's oftentimes the case that the font can change from PC to PC. It's precisely for this purpose that this option exists.
Thanks very much for the suggestion.
Actually, I've discovered that it was NOT only the fonts that changed size. There were other rescalings, but they were so small in magnitude that I didn't notice. I've changed a couple of panel settings to match those of a colleague whose panel objects, she says, don't change in response to others' mods of the UIR. One of them was the setting mentioned by Roberto (set that one to zero). The other was an auto-resize setting, I think.
One of these hours someone else is due to change the UIR. I've hand-set the original table column widths and font sizes to what they were originally, and we'll see if the upcoming change breaks me again. If so, I'll try to go with strictly programmatic solutions for look-and-feel, such as what you suggested.
BTW, now I'm just going to look at the value of the table handle to determine which table it is, and dispense with querying attributes like number-of-visible-rows that are more likely to be transient. Rows, schmows.
Thanks again to you (and to you, Roberto) for the help.
Update: It was extremely difficult to coordinate display settings among multiple developers, and to understand all the whys and wherefores of strange and ill-documented resizing and rescaling effects.
The workaround was to hardcode panel sizes and disable rescaling. That got us to a "least common denominator" of display appearance: the same for all developers' displays, which is not an ideal solution (display appearance is degraded on the larger displays) but is satisfactory (it's acceptable to end users, and developers need not worry about unpredictable or insufficiently understood resizings and rescalings).
Before we deliver the system, hopefully someone will improve the application appearance for monitors to be delivered. I think those are of the larger type.
Thanks again to everyone who responded.