Jump to content

Controls change positions on runtime system


Recommended Posts

Hello everybody,

 

I've got a situation where some controls change their position on the build application however only on the target system.
This is not just limited to a specific type of control and it does not even effect all controls on the same FP.

Up till now the behavior seems to be limited to controls inside a tab-control.

 

My development machine is Win7 with LabVIEW 2011 installation and the target system operates on XP.

I'm not to much bothered by it since it does not effect my main UI (which is build using classic controls btw), but it is a rather strange behaviour.

 

Now for a solution:

I had some good results by moving the controls in the dev-environment with space-right / space-left once, therefore the position is not altered, but the build

application seems to run just fine for most of the controls.

 

I might be able to post a screenshot next week.

 

Does anybody had experienced a similar behavior with such a setup?

 

This issue might be related to that topic: http://lavag.org/topic/16911-prevent-control-resize-when-changing-monitors/

However my controls change their actual position, where the related topic changes height & alignment (of the text inside).

Link to comment

This is almost always caused by font changes between systems (e.g. if you use the system font or application font, which would be different between XP and 7). It probably only affects some of the controls because the different controls have different fonts.

 

Try setting the controls to a specific font to see if this stops happening. Alternatively, make sure that LabVIEW.ini and your app's INI file have the same AppFont and SysFont (or whatever they're called) lines.

Link to comment

Can you post screenshots of what it looks like on your dev box versus the XP target.

 

I had no access to the machine untill right now. Find the pictures attached.

Notice that some items move positions and the blue background-item (or how to name it) is shortened.

 

LabVIEW Environment (Win7 + LV2011)

post-17453-0-29077400-1372063386_thumb.j

 

Runtime Environment (XP + LV2011RT)

post-17453-0-19385600-1372063395_thumb.j

Edited by LogMAN
Link to comment
This is almost always caused by font changes between systems (e.g. if you use the system font or application font, which would be different between XP and 7). It probably only affects some of the controls because the different controls have different fonts.

 

Try setting the controls to a specific font to see if this stops happening. Alternatively, make sure that LabVIEW.ini and your app's INI file have the same AppFont and SysFont (or whatever they're called) lines.

 

All controls have the same font. I don't understand how the font type or size should effect the position of the control, but I checked it anyways.

On my last post I attached some pictures with an alternative background for the tab-control (the bluish thing...)

I accept that the font does have an impact on the position of the text itself (the background seems to small, but actually the text changed its width).

 

What beats me is that if I make a shift-right / shift-left in the dev-environment the Runtime does sometimes look just fine... Is there some kind of raster that I can't see?

Link to comment
The controls have different names from one picture to the other. They are the same controls, right?

 

Yeah sorry for that one, I use a translation tool to automatically translate translatable objects on the Runtime system.

The source is in English and the target in German. However the controls are the same and the translation has no effect on the positioning. <-- Tested that one already

 

 

How do you know the fonts are the same? Have you explicitly changed the font in the development environment? If the control is set to, for example, Application Font then this will probably be different across XP and 7.

 

 

 

The font is indeed Application Font. Therefore the target system might display stuff a bit different (as with the tab control text width). I'll try that next time I get access to the system.

Edited by LogMAN
Link to comment

Try paste this into the .ini file for your application.

 

appFont="0" 13

dialogFont="2" 13
systemFont="1" 13
 
 I am not 100% sure what the "0" etc refers to, other than somehow it maps to a font. You can change this to something like appFont="Tahoma" 13 to force your Win7 PC to use Tahoma in the built app, rather than the default of SegoeUI. Fonts in LV are a bit of a dark pit...

 

I'll do that for sure. Thanks for the input.

The "0"... might be related to an enumeration according to:

 

post-17453-0-90975800-1372102852.png

 

That would make:

0 = Application Font

1 = System Font

2 = Dialog Font

 

I guess it'll cause the system to use the default LV font that is related to the specific item.

 

I'll try it and tell you guys if it works.

Edited by LogMAN
Link to comment
Hmmm, but if that is the case then how does my "trick" work at all if it just uses the default fonts? I thought it forced the font to be something other than the default.

 

Well you could. If you write "Arial" instead of "0" than you'll get Arial font instead of the default one.

Right now we assume that the default font on an XP machine is different from the one on the Win7 machine.

Up till now I couldn't reproduce the behavior on my virtual machine, but I'll try on the real system anyways.

I have no access to the target system for some weeks, so feel free to suggest some more ideas :)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.