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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites
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 post
Share on other sites
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 post
Share on other sites

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 post
Share on other sites
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 post
Share on other sites

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.

  • Similar Content

    • By Gan Uesli Starling
      We have a gage supplied by a company that shipped it with a *.exe application targeted for LVRTE 2009. I need to retarget it for 2017, but don't have the source code. The supplier had said they'd gladly supply me with a copy of the *.LV source, but they have looked and cannot find their own copy in-house.
      History of Need: Our global corporate mother ship's IT department, in their infinite wisdom, is mandating an upgrade from Win7 to Win10. That with yet even further constraints. They enforce a list of "approved versions" of "approved applications". And for LVRTE, they are insisting upon 2017, with 2009 being a red light.
      So, then, my query. Is converting an app without the source for a higher LVRTE doable at all? File is attached.
      If it is doable, instructions on how?
      Concentricity-Gage.exe
    • By 0_o
      Hi,
      When I try to install LabVIEW 8.5.1 runtime or visa 4.1 on an Intel NUC with CPU i5 7260U I get:
      Microsoft Visual C++ Runtime Library
      Runtime Error!
      Program ........\LV RunTime 8.5.1\setup.exe
      This application has requested the Runtime to terminate it in 
      an unusual way.
      Please contact the application's support team for more 
      information.
       
      Just in case I installed Visual C++ 2005 redistribution and checked under add remove programs that the Windows feature of allowing version under .net 3.5 to run was enabled.
      This is not an ARM based processor so why does LabVIEW has a problem installing on the NUC?
    • By Wim
      Hi,
       
      I’m having issues with a LabVIEW application that I made.
       
      Quick summary:
      The application is used for reliability tests.
      Users can configure profiles/experiments. These are translated to a voltage/current output.
      Experiments can be started to run parallel on a rack of power supplies.
       
      More Details:
      The application is OO-based. Each active experiment is an ‘experiment executor’ object which is a class with an active object. The process vi is a very simple statemachine which handles init of the hardware (VISA (Powersupplies connected via Ethernet, VISA TCP/IP)), iteration handling of the test, summary logfiles, UI and a few other things.
      Typical usage of the application is:
      16 samples tested in parallel. Most of them run the same experiment (== same output) but on different powersupplies.
      These samples are tested simultaneously, and started at the same time.
      System details:
      LabVIEW2011 SP1 (32bit) // VISA 5.4.1
       
      Observations:
      In development:
      I can simultaneously start 16 samples summary file of the experiment settings are written to disk  (16times in parallel == 16 samples and all vi’s are set to reentrant)  duration is about 10s for each file. (depends on the length of the experiment, different profile steps that are used etc) it is  a simple ini format file, about 136KB size Experiments start execution. (== output and measurement on the power supplies) Parallel reentrant VISA communication with power supplies works perfect, internal looprate in the ‘avtive’state of the process is about 500ms (with 16 parallel samples)  
      In runtime:
      When I start the samples, the parallel processes are started BUT:
      Writing if the ini summary file gets slower and slower each time a new clone/sample is launched. I see this, because for debug I open the FP of that vi.  Writing of the file gets slower and slower… fastest file == 30s, slowest (== last sample started == 250s) Parallel reentrant VISA communication, looprate is 20-30 SECONDS (iso 500msec in development) Can someone help me with this ?
      16 parallel process isn ‘t that much.
      I always thought that runtime would be faster than development env.
    • By Corks
      Hello All, 
       
      My current company is in the process of expanding, and we are seeking experienced LabVIEW developers for our Denver office location. Please see below for position details:
       
      Automation Engineer – LabVIEW Control Systems
      DMC has openings in several automation engineering positions, based on experience level. 
      Location
      Denver
      Job Summary
      With a broad understanding of engineering fundamentals, DMC Automation Engineers provide programming, troubleshooting, testing & measurement, and technical support & solutions to a wide range of clients. Automation Engineers quickly learn new technologies and absorb specific industry knowledge to provide custom software engineering, problem solving, and helpful assistance during each phase of a project. Working both independently and within teams, Automation Engineers assist with project management, meeting deadlines and keeping excellent communications and feedback channels with team members and clients.
      Minimum Qualifications
      Engineer Level I (1-3 years relevant experience):Bachelor of Science in Mechanical, Electrical, or Computer Engineering, Computer Science or related field Background in LabVIEW Programming

      Engineer Level II (2-5+ years relevant experience):
      In addition to the above requirements, several years of experience with design and implementation of LabVIEW projects Certified LabVIEW Developer or Certified LabVIEW Architect Project-based development experience
      Desired ExperienceReal-Time FPGA cRIO PXI RF Vision CAN Modbus

      Required Skills
      Engineer Level I
      Programming Quickly Learn New Technologies Complete grasp of scientific method of problem solving Ability to follow patterns & build upon established models Understanding complex system designs Estimation of time to complete familiar tasks. Identify & communicate through proper channels new opportunities for DMC
      Engineer Level II (In addition to above skills)Experience with current test and measurement as well as data acquisition hardware and devices. Ability to specify correct hardware based on system requirement. Project Planning/System Architecture Design Program Implementation Debug System Testing Communication with team members and clients Documentation Ability to create methodology to solve novel problems Ability to design systems based upon previously used system Convey knowledge in presentations, SOPs, Knowledgebase articles, client case studies, and white papers Estimation of own and others' time for completion of familiar tasks Project proposal writing

      Other Skills/Abilities
      Customer Service Communications Technical Writing General Admin
      Responsibilities
      Engineer Level IProgram applications to meet & exceed customer requirements Develop robust applications in accordance with DMC programming standards & best practices Project Planning/System Architecture Design Assistance Program Implementation Debug System Testing Communication with team members and clients Documentation Respond to customer needs

      Engineer Level II (In addition to above responsibilities)
      Perform programming and engineering tasks in supportive and leading roles at all stages of projects. System design and design assistance. Help Train/Orient/Bring Up to Speed new employees. Convey knowledge in presentations, SOPs, Knowledgebase articles, client case studies, and white papers. Develop & maintain relationships with key contacts with vendors. Develop & maintain relationships with clients, keeping feedback channels open and healthy. Assist in writing project proposals. Seek, identify, and discuss new opportunities with new & existing clients, through proper DMC channels.

      Interested?
      Email your resume and cover letter to: jobs@dmcinfo.com
       
      Full Listing: http://www.dmcinfo.com/employment/automation-engineer-labview-control-systems
       
      General Information: http://www.dmcinfo.com
    • By crabman
      Hello Everyone,
      I am a small-time application builder on Labview, I have tried to find answers to the following two questions a lot on the NI site but could not get any definite yes or no answer
      So here are the questions
      1) I know that DSC module requires run-time license on the end-users computer, my question is, that if I use the datasocket binding on the controls/indicators property box and assign a couple of OPC tags (like 20-30 max) and not use the shared variable engine, do I still have to get a dsc runtime license, or is there anything like OPC tag-based license for the end-users PC?
      2) Does database connectivity toolset and report generation toolkit also require runtime license on end-user PC's?
×
×
  • Create New...

Important Information

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