Why is my user interface monitor resolution dependent?

The user interface I created with Labview is screen resolution dependent. That means I built a user interface application exe on my computer. But when I run the exe on another computer with lower resolution, the application window was enlarged and some of the controls were cut off. I have had the problem all the time and it bacame a famous issue in our engineering group . By the way, I didn't check any box in the VI Property\Window Size window. Can you help me to fix this problem?

I use Labview 7.1.1 and had this issue, the fix is under VI Options.. goto Window Size and check "Maintain proportions of window for different monitor resolutions", there is also a check box for "Scale all objects on panel as the window resizes".
Give these a try they should work for you.
Andrew Alford
Production Test Engineering Technologist
Sustainable Energy Technologies
www.sustainableenergy.com

Similar Messages

Why has itunes user interface been ruined?

Why has the itunes user interface been ruined? It used to be easy to use. Basic functions dont work any more. Editing a Play List requires extra steps. I cant restore the useful side navigation bar where I could easily add a song to one or more play list...
Incredibly frustrating.

When I plug the iPhone in the sync options comes up once, but once you leave you cant get it back. There is phone icon in the top icon nave bar - but clicking on it does nothing. What is the point of the icon if it does nothing?
How do you get back to the sync options screen where you can select the music you want without having to disconnect and plug it back in again?
It used to be easy... More frustration...

The new ribbon user interface in Win 8.1 should display appropriate buttons depending on the currently displayed folder within the explorer.exe window.

To begin with, in file-explorer (.\system32\explorer.exe) normally, the new ribbon user interface in Win 8.1 does indeed display appropriate buttons depending on the currently displayed folder within the explorer.exe window.
But when one re-parents the explorer window handle to any window handle other than 0000 (desktop's window handle), then the UIRibbon fails to do so.
You might ask 'Who does that ?' and I would say no-one usually, however I use BrightExplorer which
is a great little app that gives me a tabbed file-explorer experience.
Now, this app works fine since Windows 7, but with Windows 8 the file explorer introduced the new UIRibbon in its UI. It's that new UIRibbon that gets confused by what I think may be be caused by the re-parenting that BrightExplorer does
to pull a file explorer session into its tabbed control.
This phenomenon relates to Windows 8 + and is observed only by doing the following steps:
Download BrightExplorer from BrightNewWorlds.com by going here: BrightExplorer,
In the address bar go to This PC,
then go to any other folder and note that the UIRibbon is not keeping track of the changing folder selections.
Does anyone out there feel that they can do something about this, or have advise?
Kind regards,
Robert van der Meijden

To begin with, in file-explorer (.\system32\explorer.exe) normally, the new ribbon user interface in Win 8.1 does indeed display appropriate buttons depending on the currently displayed folder within the explorer.exe window.
But when one re-parents the explorer window handle to any window handle other than 0000 (desktop's window handle), then the UIRibbon fails to do so.
You might ask 'Who does that ?' and I would say no-one usually, however I use BrightExplorer which
is a great little app that gives me a tabbed file-explorer experience.
Now, this app works fine since Windows 7, but with Windows 8 the file explorer introduced the new UIRibbon in its UI. It's that new UIRibbon that gets confused by what I think may be be caused by the re-parenting that BrightExplorer does
to pull a file explorer session into its tabbed control.
This phenomenon relates to Windows 8 + and is observed only by doing the following steps:
Download BrightExplorer from BrightNewWorlds.com by going here: BrightExplorer,
In the address bar go to This PC,
then go to any other folder and note that the UIRibbon is not keeping track of the changing folder selections.
Does anyone out there feel that they can do something about this, or have advise?
Kind regards,
Robert van der Meijden

How do I fix incorrect resolution for Firefox user interface on Retina display Mac?

I have a 15" retina display Mac (roughly a year old) running Mountain Lion. A couple weeks ago the user interface in Firefox seems have switched from using the normal zoom level of every other application to the native dpi of the retina display monitor. This means that the UI elements are all extremely tiny, etc. Is there anyway to reset this without simply reinstalling or reseting the rest of my configuration?
Currently running Firefox 27.0.

You can try to modify the gfx.hidpi.enabled pref on the <b>about:config</b> page (<=0: disable; 1:all screens same res; >1:enable always).
*http://kb.mozillazine.org/about:config
Try to disable hardware acceleration in Firefox (you need to close and restart Firefox).
*Firefox > Preferences > Advanced > General > Browsing: "Use hardware acceleration when available"
*https://support.mozilla.org/kb/Troubleshooting+extensions+and+themes
You can set the layout.css.devPixelsPerPx pref on the <b>about:config</b> page to 1.0 and if necessary adjust layout.css.devPixelsPerPx starting from 1.0 in 0.1 or 0.05 steps (1.1 or 0.9) to make icons show correctly.
*http://kb.mozillazine.org/about:config
See also:
*https://support.mozilla.org/kb/forum-response-Zoom-feature-on-Firefox-22
Use an extension to adjust the text size in the user interface and the page zoom in the browser window.
You can look at this extension to adjust the font size for the user interface.
*Theme Font & Size Changer: https://addons.mozilla.org/firefox/addon/theme-font-size-changer/
You can look at the Default FullZoom Level or NoScript extension if web pages need to be adjusted after changing layout.css.devPixelsPerPx.
*Default FullZoom Level: https://addons.mozilla.org/firefox/addon/default-fullzoom-level/
*NoSquint: https://addons.mozilla.org/firefox/addon/nosquint/

Multiple monitors, duplicate user interfaces

Hey everybody,
My application consists (as the title suggests) of a computer running 4 touchscreen monitors. Three of the monitors will be completely different, but the 4th will need to be a combination of the other 3. The 4th is bigger, so it will actually fit all of the front panel from monitor 1.
Here is a depiction of what the setup will be.
The hard part is that I need Monitor 4 to act exactly like the other monitors in its respective sections. It would be nice to be able to do this without duplicating code or having to send my data to multiple places every time. Do any of you have experience in UI duplication, or know of a clever way to do this?
What I'm thinking I'll have to do is create a new interface for the 4th monitor that triggers the other user interfaces and vice versa. The downside is that it takes extra development on top of the UIs I already have and if I change something with the first 3 UI, I have to go in and change the 4th manually. I would also have to do some fancy global event triggering LIKE THIS in order to communicate between two different VIs.
Any help is highly appreciated.
Thank you!
James
LabVIEW Professional 2014
Solved!
Go to Solution.

GerdW,
My architecture follows a Queued Message Handler structure and allows communication between each module.
Can you elaborate on "duplicate FP"? Is there a way to duplicate just the FP for control purposes, but have the code only running once in the background.
johnsold,
Each GUI is it's own top level Queued Message Handler that sends its information to seperate QMHs through shared API. Essentially this means that each module has its own Master portion that can send its data to another module's Slave and vice versa. This architecture would allow for near-simultaneous user inputs from different locations because the first one to be written to the queue would just get handled first, then overwritten by the other, which isn't a problem.
Can you link to an example of pulling a VI in to a subpanel while simultaneously running another instance of the VI? Every time I try this, I get an error.
Edit: Thanks David
Thanks,
James
LabVIEW Professional 2014

Open Serial Driver VI runs in user interface thread - why?

I know the serial port compatibility functions are "phased out" and you should use the newer VISA functions - but why on earth is the open serial driver VI set to run in the user interface thread? If you happen to use these compatibility VIs your serial communication will be blocked by e.g. a user that opens the calendar view of a date and time control...- and the only reason for that is that that particular VI is running in the user interface.
Change the thread of that VI - and the serial communication runs as it should, so why is it that that particular VI, unlike all the other VIs in that library, is configured that way?
MTO

The S/N dialog is part of the process model.
For the Sequential Model (SequentialModel.seq), the default S/N dialog in found in the 'PreUUT' sub-sequence and implemented as a DLL call.
The PreUUT sub-sequence of the SequentialModel is a callback, so you can override it in your own test sequence.
Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.
"You are what you don't automate"
Inplaceness is synonymous with insidiousness

CS6 Hi Resolution Screen User Interface Problems

I have a new Lenovo Yoga 2 laptop which has a native resolutions of 3200 x 1800. When I install the CS6 suite on this laptop, the user interfaces are too small to be seen.
Here are some screen shots. Oddly enough, inDesign is the only application that looks proper.
Photoshop
Illustrator
Dreamweaver
InDesign
I've tried to find a solution to this but I can only come up with "Retina" based fixes... Have you guys made these fixes for PC users?

I have the same computer and have patiently waited for the fix.... what a waste of time!!! This is absolutely incredible that a company that wants to compete in the graphic software market will not support resolutions which are rapidly becoming the standard... ADOBE your non-support is an absolute disgrace to your customers that spend money on your software....

Why oh why was it fixed when it wasn't broken..the user interface

This is a serious error on Apples part to alter the way this critical program operates
its like taking away critical controls from an automobile...like the steering wheel
Its that bad its at the level like Microsoft would have done.
It may operate with all the same features...but where are they...not on the iTunes desktop
where one could surf iTunes to look at, get, explore
big mistake & an even bigger one not to listen to customers...
Bruce L. Farrar

Steve
Sorry I just cant see how you can compare iTunes 10.7 & iTunes 11 - yuo are in the minority !!
Everyone I speak to has the same view on this:
That 11 hasnt the same user interface & controlability.For me this is fundamental in the way I used iTunes to "surf" what was available from what I already had.I find the way I have to go through things in a list poor to unusable. OK Apple may want to have the same interface accrooss the whole product platform - but why the capability of a Mac with a omplete keyboard & larger screen allows for more possibilities than say an iPhone which I reackong any user will realise & accept...basically the iTunes on mac platform has been dumbed down & is now far less capable
The search "engine" that hasnt got fields to select to narrow down or focus a search is just riduculous & it doesnt work that well as whats comes back has to be searched through again.
Using iTunes 10.7 & before was an "adventure" into music or material you knew & you found things you didnt know about & to do this was easy & enjoyable. Ifound previosly I could find a single track out there quickly & also explore.
Whats happened is fundamentally bad - lets give a comparison - say if the whole user interface of the MacOS or write was altered, made significantly different...everyday tasks that you could do before had to be re learnt or just couldnt be done.
Even Microsoft are carefull about making changes to the way things work & the way that a user interfaces with this...one carefull step at a time OK Microsoft "things" have to recieve this type of carefull scrutiny & adjustment - but Microsoft onthe whole take thier customers with them. Learning point that Apple have yet to realise & learn from
Previous to this from Lion to Mountain Lion there was Frontrow a simple little program that gave a feature that me for one used (& enjoyed) regularly.....on the Mac doing something important...take a break, relax & enjoy some music...one press of the remote & you had all you music & videos there to be used...like a big iPod...really ver good. Finished relaxing or taking a break get back to work just where you left off, an impressive feature that was taken awy & replaced with NOTHING.
So for me at least the usability & functionallity of the Apple experience has deteriorated...for no appreciable gain....for just a commonality of controls accross the products.
Its called "change for changes sake" & in this case the customers werent consulted they were totally ignored in being left with something that is retrograde.
The very fact that I am here with others making comment is proof postive that the situation is a definate backwards step. I just hope that for Apple its a "blip" i.e. an error that will realised & corrected...
I have been using Apple products from 1989...I am not a Microsoft refugeee or reluctant convert who is throwing mud..just the opposite in my family we have:
4 Macbook Pros,
an iMac,
4 iPods,
4 iPhones
Apple TV
all backed up ona time capsule.
We have lived through the bad times & good...I realise that Steve Jobs cant come back...but I am sure he would have listed & then gone back to the teams & forced the change backs through.

Why do I get -18001 Errors using Customised TestStand User Interface

Hi all
I have a problem when attempting to run my application on my host NT PC. I have a customised operator interface to TestStand written using Labview 5.1.1 and built using the LabVIEW application builder. I am running the TestStand Development (Run-Time) System on my host PC.
The problem is that as soon as I go to run my sequence of vis (mass compiled using the same version of LabVIEW and assembled for run-time distribution) I receive the error '-18001 VI Not Executable.'
I think this is probably to do with how I've included the ActiveX server in my LabVIEW User Interface application, but knowing very little about ActiveX I'm not sure exactly what the problem is.
If anyone
has any ideas, I would be extremely grateful for any assistance you could offer. My TS version is 1.0.1
Thanks
Dave

David,
I would like to add to Richard's input. The typical reasons a VI cannot be executed that cause this message are:
1) There is an error in the VI such that the run arrow of the VI is broken when the VI is open in the LV development environment. This problem is usually easy to debug because you should get the error (shown below) when running your sequence in the sequence editor using the default "LabVIEW" ActiveX server provided by the LV development environment (not the LV ActiveX server provided by your operator interface which is by default named "TestStandLVGUIRTS" ).
An error occurred in the 'MyVIStep' step of the 'MainSequence' sequence in 'MySequence.seq'.
LabVIEW : VI is not executable.
An error occurred accessing the LabVIEW ActiveX automation server. Error Code: -18001
2) The same error will occur when
a. you are using any LV ActiveX server other than the "LabVIEW" server provided by the LV development environment, AND
b. at least one of the called VI was not assembled for distribution properly. This means that not all test VIs and their *entire* hierarchy were distributed.
I am not sure exactly what you have done so have compiled some information that I think will help. Below I have included the document, Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter, which will appear in the NIDZ shortly. Another useful document is the NIDZ document Distributing LabVIEW Test VIs, which you can obtain from our website. Read these documents before preceding with the steps immediately below, which give you an example process for distributing. This may help provide a better understanding and guidance in the distribution process. We are working to simplify this process in future versions of TestStand.
For the following example distribution I recommend that you are use default shipping code so that the problem is not complicated with potential errors added through customizations you have made.
Building The Operator Interface
The following are steps if you are using a LabVIEW operator interface.
1) Copy the contents of \OperatorInterfaces\NI\LV to \OperatorInterfaces\User\LV.
2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
3) In LabVIEW Select Tools>>Build Application or Shared Library
4) In the builder click the Load button and load \OperatorInterfaces\User\LV\testexec.bld. This build script is configured to create testexec.exe that contains the LV ActiveX server with the name of TestStandLVGUIRTS (see the Application tab of the builder).
5) In the builder click Build.
6) Once the application testexec.exe is built, run it once so that the server TestStandLVGUIRTS is automatically registered. You do not need to run a sequence. Close texec.exe.
Creating a LabVIEW Run-time Server
If you are using the LabVIEW operator interface then skip this section. The following steps are meant for those who use an operator interface written in a ADE other than LabVIEW. They provide you with a LabVIEW run-time server that is used by TS to run your VIs.
1) Copy the contents of \Components\NI\RuntimeServers to \Components\User\RuntimeServers.
2) Open a new VI in LabVIEW. Make sure all other VIs are closed.
3) In LabVIEW Select Tools>>Build Application or Shared Library
4) In the builder click the Load button and load \Components\User\RuntimeServers\LabVIEW\TestStandLVRTS.bld. This build script is configured to create TestStandLVRTS.exe that contains the LV ActiveX server with the name of TestStandLVRTS (see the Application tab of the builder).
5) In the builder click Build.
6) Once the application TestStandLVRTS.exe is built, run it once so that the server TestStandLVRTS is automatically registered on your development machine. Close TestStandLVRTS.exe.
Assembling the Test VIs for Run-Time Distribution
This distribution process uses one of the shipping TS examples that calls LV VIs.
1) From LV mass compile all VIs in the directory \Examples\AccessingArrays\UsingLabVIEW\. Please make sure that there were no error messages in the Status tab of the Mass Compile dialog box.
2) In the sequence editor open \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq
3) Confirm that the sequence runs without problem.
4) In the sequence editor select Tools>>Assemble Test VIs for Run-time Distribution.
5) If you are using TestStand 2.0 select \Examples\AccessingArrays\UsingLabVIEW\AccessingArrays.seq as the file from which the VIs should be assembled.
6) Set the target directory to be something distinct like C:\temp\AssblVIs.
7) If you are using TestStand 2.0 skip adding Dynamic VIs
8) Save with or without diagrams. Its your choice.
Change Search Directories
Once the VIs are assembled successfully, you must add the new target directory to the TS search directories.
1) In the sequence editor select Configure>>Search Directories.
2) Add your target search directory (e.g. C:\temp\AssblVIs) to the search directories.
3) Close the Edit Search Directories dialog box.
4) Confirm that your sequence steps now reference the assembled VIs. Right click on a step in the sequence and select Specify Module.
5) The dialog should show that the code module is found in the target directory (e.g. C:\temp\AssblVIs) that you just added to the search directories.
6) Run the sequence. This is the initial test to see if the VIs are assembled properly.
Switch the LV Adapter to use the TestStandLVRTS server or TestStandLVGUIRTS
1) In the sequence editor select Configure>>Adpaters.
2) In the Configurable Adapters control select the LabVIEW Standard Prototype Adapter and then click the Configure button.
3a) If you are not using the LV operator interface then switch the ActiveX server to TestStandLVRTS.
3b)If you are using the LV operator interface then switch the ActiveX server to TestStandLVGUIRTS.
4) Close the adapter configuration dialog boxes. You will get a couple of questions boxes. Just click OK each time.
5) Now run your sequence. If successful you are no longer using the LV development environment to run your VIs. This shows that the VIs were assembled correctly, the LV ActiveX server is working properly and that the search directories are configured properly.
You can now try and run the sequence using your operator interface on you development computer. If this test works it means that you have also confirmed that your operator interface is working correctly with all the other components. Now it is just a matter of moving all the component correctly to the target machine.
Distributing Components
-To distribute your operator interface use the distribution tool of the application development environment (ADE) in which you built your operator interface.
-To distribute the TS engine using the Run Engine Installation Wizard tool. This tool is typically not used for distributing your sequences and VIs, which you will probably distribute more frequently than the TS engine. It does distribute and register your LV run-time server (if you are using one) as long as you have stored it in \Components\User\RuntimeServers. It also distributes other TS components that you have stored under the directory \Components\User\.
-You can use whatever distribution system you like to distribute your VIs and sequence files (e.g. ZIP and network transfer are popular) . Ensure that you distribute the assembled VIs and not the development VIs. Also ensure that the location of the VIs on the target machine is one of the TS search directories.
Hope this helps.
Regards,
Kitt
=========================================
Title:
Overview of Distributing TestStand when your Sequences use the LV Standard Prototype Adapter
The general outline of the components to be distributed and the actions to take are followed by a more detailed description.
Components that need to be distributed:
TS engine
Operator interface
LabVIEW executable that will act as a LabVIEW ActiveX automation server (If the operator interfaces is written in LabVIEW, it can function as the LabVIEW ActiveX automation server.).
LabVIEW run-time engine
LabVIEW test VIs
Test sequence files
Actions before distributing:
It is recommended that you test the distribution components on the development machine before you distribute them to your target machine. In this manner you can more easily debug errors that you may encounter
Create the executable that will serve as your LabVIEW ActiveX server on the target machine (components 2 or 3 above).
Assemble the test VIs for distribution.
Update the TestStand search directories so that the sequences reference the assembled VIs.
Configure the LabVIEW Standard Prototype Adapter to use the LabVIEW ActiveX server that you will install on the target machine.
Test the distribution components on the development machine.
Enter section headings, separating each section with a line break:
TS Engine Component
Operator Interface Component
LabVIEW ActiveX Server
Configuring the LabVIEW Standard Prototype Adapter
LabVIEW Run-time Engine Component
Assembling your Test VIs for Distribution
Note
TS Engine Component
With any TestStand distribution you must install the TestStand runtime engine on the target machine. The Run Engine Installation Wizard tool, found under Tools menu of the Sequence Editor, facilitates this process. The wizard tool will create two files, SetupTSEngine.exe and TSEngine.cab. Move the two files to your target machine and run SetupTSEngine.exe to install the TestStand engine.
These installation files include the current configuration settings that exist in the Sequence Editor at the time the tool is invoked. It also includes all process models, TestStand types and step type modules. If you have customized components of TestStand and saved them under the directory TestStand\Components\User, then the components will also be included with the engine installation.
You must purchase at least a base deployment or debug deployment license for each machine on which you install the TestStand engine.
Operator Interface Component
You will also need to install an operator interface executable on the target machine. This program acts as a client to the TS runtime engine, controlling the execution of sequences and displaying their progress. TestStand ships with several versions of TestStand operator interfaces, which are written in different application development environments (ADE). For distributing the operator interface executable, refer to the application development environment in which it was created.
LabVIEW ActiveX Server
You must have a LabVIEW ActiveX server on the target machine. TestStand uses the LabVIEW ActiveX server to run VIs using either the LabVIEW development environment or the LabVIEW runtime engine. The LabVIEW ActiveX server is provided by either LabVIEW development environment or by any LabVIEW executable that has been built with �Enable ActiveX Server� selected. This setting can be accessed in the LabVIEW Application Builder during the build process. When this preference is enabled, you must enter a server name. You will use the server name to configure the LabVIEW Standard Prototype adapter in TestStand.
If your operator interface is written in LabVIEW, then it can act as the LabVIEW ActiveX server on your target machine. TestStand ships with two operator interfaces written in LabVIEW. The standard LabVIEW operator interface is located in TestStand\OperatorInterfaces\NI\LV, while a simplified version is located in TestStand\Examples\OperatorInterfaces\Simple LV. LabVIEW buildscripts are provided for these applications to facilitate building an operator interface in the latest version of LabVIEW. The settings of these buildscripts are such that the applications are LabVIEW ActiveX servers with the server names of TestStandLVGUIRTS for the standard operator interface, and TestStandSimpleLVGUIRTS for the simple operator interface. The applications register the servers the first time they are executed. If you want to manually register or unregister one of the servers, you can invoke the executable with the /RegServer and /UnregServer command-line arguments respectively.
If your operator interface is programmed in a language other than LabVIEW, then you will need a separate LabVIEW executable to provide the LabVIEW ActiveX server on your target machine. For this purpose, TestStand ships with a LabVIEW run-time server application located in TestStand\Components\NI\RuntimeServers\LabVIEW. A LabVIEW buildscript is provided for this application to facilitate building a run-time server in the latest version of LabVIEW. The settings of this buildscript are such that the application is a LabVIEW ActiveX server with the server name of TestStandLVRTS.
Note: When an ActiveX executable server is accessed, the executable is launched automatically if it is not already executing.
Configuring the LabVIEW Standard Prototype Adapter
When TestStand runs a VI using the LabVIEW Standard Prototype adapter, it does so using a LabVIEW ActiveX server. By default the adapter is configured to use the �LabVIEW� server, which is provided by the LabVIEW development environment. If you do not have the LabVIEW development environment on your target machine then you must configure the LabVIEW Standard Prototype adapter within TestStand to use a different server (e.g. TestStandLVGUIRTS, TestStandLVRTS, or TestStandSimpleLVGUIRTS).
To configure your LabVIEW Standard Prototype adapter, select Configure>>Adapters from the menu. In the Adapter Configuration dialog box that appears, select the LabVIEW Standard Prototype Adapter in the Configurable Adapters section. Click the Configure button. You can select or type a server name in the Select or Type Which LabVIEW ActiveX Server to User control. If your server name is not in the list you will need to type it.
As explained in the LabVIEW ActiveX Server section above, TestStand ships with LabVIEW buildscripts to build a LabVIEW operator interface and a LabVIEW run-time server application. These applications are LabVIEW ActiveX servers with server names TestStandLVGUIRTS and TestStandLVGRTS, respectively. You can configure you LabVIEW Standard Prototype adapter to use one of these servers.
LabVIEW Run-time Engine Component
If any of your sequence steps use the LabVIEW adapter or if your operator interface is written in LabVIEW, then you must install the LabVIEW runtime engine on the target machine. It is important that your LabVIEW run-time engine is the same version as the VIs that TestStand executes.
You can find installation files for the LABVIEW 5.1 run-time engine in the LabVIEW installation directory, Labview\APPLIBS\installs\RunTime. In addition, you can choose to automatically distribute and install the LabVIEW run-time engine with the distribution of a LabVIEW executable. Refer to LabVIEW documentation.
Assembling your Test VIs for Distribution
After distributing TestStand, you must ensure that your sequences are able to locate the VIs they call, and the VIs must be able to locate their required resources.
One common mistake is to simply copy the original VIs from the development machine to the target machine. Once you have configured your LabVIEW Standard Prototype adapter to use a LabVIEW ActiveX server other than LabVIEW, your sequence will not be able to execute your original test VIs that your sequences call.
TestStand provides the Assemble Test VIs for Distribution tool, which gathers test VIs and their required resources, and places them in a common location for distribution. You can then modify your TestStand search directories so that your sequences reference the assembled VIs. These topics are covered in the NIDZ document Distributing LabVIEW Test VIs.
Links: See Distributing LabVIEW Test VIs below
Note
Remember to test your distribution components on your TestStand development system before distributing TestStand. If the execution does not work on the development system it is not going to work on your target machine. On your development machine you have more ability to debug problems you may encounter.
Note: One common problem of testing distribution components on your TestStand development system is that your sequences reference the original Test VIs instead of the assembled test VIs. Refer to the NIDZ document Distributing LabVIEW Test VIs for assistance.
Once the components work on your development machine, you are ready to install them on your target machine. The order in which you install these components on the target machine is irrelevant.
==============================================

Why hasn't Adobe navigation and user interface design improved as much as it could have over time?

I haven't tried CS6. I'm sure it's great based on what i've seen alone. But as a user of adobe products for a number of years, i have to noticed there are still a lot of stagnant,awkward, stiff, irriating, slowing down elements found in the navigation and user interface on cs3-cs5, that i'm sure could have been eliminated or improved on at least from 2005 or 2007 onwards. I find some of these things inexcusable and unprogressive from bad traits that defined 1980's and 1990's general computer navigation and so on.
CS5.5 has lessned this a bid bit and is more fluid in bits and pieces but for those using cs3-cs5 and in general, i find some things just horrid. As a graphic designer no one is supposed to admit the flaws or irrations of these programs. We must hail them as god, never critisize, and always adjust to new things which i think is a bit fascististic and silly
The way the tools, options are laid out can be improved to be quicker, and easier to find and use. Using your voice as a commanding system would be helpful as well.
A lot of cmds are too complex to remember, they can be simplier or resemble the name of the tool or option. Its makes a chore to follow this system and competition for the smart *** who memormized all the cmds.
The way in which you loose floating side boxes, and the amount of tools or names hidden in the bars sometimes seem random and its always a constant search to find them incase you forget where they are.
The inability to open cs4 or 5 files in cs3 is just beyond extremly annoying. Whey shouldn't you be able to open cs1 or 2 files or photoshop 9 files as well? Every five years work expires as well?
The layering system gets tricky and seems that a lot of things don't work when you normally move things. Its about going back, remembering and clicking on this or that, looking it up to make everything work. Sometimes which leaves you in a rut and wastes a good amount of time. You will always find this even after you've been using it for years.
The use of the fill paint/airbrushing, clone tool, lasso tool, pen tool, history being two steps back can be vastly improved to be much better to use
Masking and tools that have more complex features should find a way be automatically done or sampled. They can also have less complex steps and tha ability to be previewed, automatic or simpler ( in case you can't remember how to do something or aren't getting it)
A lot of the special effects, and blending modes are useless, outdated, super-ugly and don't resemble true darkroom effects ( such as polarization, and bas-relief for example) which they could much more vividly done. There also could be more options that are closer to repro cameras/CTP software for halftoning and more complex digital effects.
Having to press or get used to pressing muliple keys or clicks for the most basic things simultaneously can be reduced to be easier
Adjusting text, new documents, photos should have a smoother, quicker navigational experince where things a lot of room to be , clicked back, re-done, saved in the wrong place etc..
Indesign could use more shapes, include more features that illustrator has, and possibly even photoshop to save time.
There should be a way to remind you of features, complex things you've forgotten, other than history and daily usage/practice of the programs
The help should resemble more of "visual -learners" guide books with voice features.
There are a lot more
Regarding other things:
I think the price encorages more piracy and allows people to not have a concept of what is means to owning software.
The loss of a manual or lessening of them for certain programs is a loss because it's always useful to physical info you can flip through while looking at your program.
I think adobe should make entirely better products for professionals or people in the industry rather than spoonfeeding the same software to all.
They should also make less expensive add-ons like before for graphic software.
What do you adobe could have improved over time and if so what do you think they could have improved on?

You have this wishform to suggest improvements to Adobe products:
https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
and the Creative Suites forums are here:
http://forums.adobe.com/community/creativesuites
This specific forum is only for discussions on the forums themselves, so you are not very likely to get any change by posting your comments here.

Why does my Wallpaper JPG (created CS5) pixels on 1 monitor and not another? Artwork is 600dpi, rgb,jpg, 30" x 16.5" size, 16:9 ratio. Does monitor resolution matter?

OS 10.6.8, my monitor resolution = 2560 x 1440.

Don't worry about inches or ppi. Only worry about pixels when designing for a monitor. You will be much happier with the results.
inches x ppi = pixels
30 x 600 = 18000 pixels
16 x 600= 9600 pixels
Printing as you can see is another matter, it requires a much higher resolution. Usually around 300ppi but I think you can see the difference.
Find the highest resolution of the two monitors and design for it. Then reduce for the other monitor never the other way around. It is much easier to remove pixels than to add them.

UI (User Interface) text size and colors

Recent versions of Elements (7, 8, 9) have changed to a user interface which is predominantly shades of gray and black with few if any user options for color or font. The font size cannot be altered because Adobe use their own pixel-based font which is not compatible with Windows Desktop settings. So on many flat screens with high resolutions the font becomes almost unreadable. The upper case 'E' in the menu bar Edit for example, is a mere 2.03mm high on a 22" display at 1920x1080 resolution.
This has been mentioned a number of times over these releases to no avail, but at last there may be a change on the way for PSE 10 (later later this year?).
So if you feel the gray/black UI needs attention I suggest you visit
http://feedback.photoshop.com/photoshop_family/topics/my_eyes_need_help_with_photoshop
where there are a number of comments. This is monitored by Adobe so may influence the next release. The more request there are I suspect the more likely some action. Adobe have already commented: "The amount of conversation that this thread has generated among Elements customers was unanticipated." on the thread.
If you wish to place a comment you will need a Photoshop Account and to be logged in. If you didn't create an account when you installed the product then just click Create Account at the top of the link above.

Font sizes are hard-coded in teh apps and there is no way to change that. The new CC versiosn support high-DPI displays and resolve those issues (mostly).
Mylenium

What is the best way to get data to a user interface?

Hi,
I'm using labview 6i. I have an application with a handful of "core" vi's that actually run my application, doing the data acquisition, analysis, and control. I am currently using these same vi's for my user interface. I also have a number of vi's that contain menu's for configuring the "core" vi's. My questions is, what is the best way to seperate the "core" vi's from the user interface vi's. Global's, data socket, control references, others?
Thanks for the help.

Hi Sal,
I have been a strong advocate of control refnums ever since LV 6i hit the streets. I recomend you look into using them to provide this conectivity.
You could accomplish this by using a variation on the following.
In your UI, create refnums for each of the controls or indicators that must be monitored or updated. Pass the appropriate refnums to each of the "core.i's" at program init time. Inside each of the core.vi's, use property nodes to read the control's values when appropriate and similarly for display purposes. (Note: Not all boolean mechanical actions are compatible with this technique. In those case you will have to explicitly write false values after find the control to be true or vise versa).
By using this technique, you can keep the UI diagrams clea
n. Depending on your app. the UI diagram could consist of the init's I mentioned above, and a while loop that watches if it's time to exit.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Cs6 user interface too small to use

I have just bought a new laptop with a high resolution screen - 2560x1440 - and like many others, I'm finding that the user interface for my cs6 software is too small to use.
I have just found the following advice for HiDPI devices on Adobe Illustrator Help:
For displays with resolution greater than or equal to 2560*1440, Illustrator can be launched at 1.5 times or 2 times scaled-up UI, depending on the OS text size.
I'm not very computer savvy, and I don't know how to do that - can anybody help please?
Judith

This only applies to Mac, not Windows.
Mylenium

User Interface Fonts (CS4)

My wife just got a new PC and a 23.5" widescreen monitor. It's great, but with the high pixel density of the screen (1920x1080), DW CS4's fonts in the menus and other user-interface items are really small and hard for her to see. Windows 7 has a way of setting on-screen fonts to a larger size, which works in most programs, but (unsurprisingly) not in DW.
I think from past discussions that I recall that this is pretty much a lost cause, but since we're thinking of upgrading to CS6 when it comes out, I'd like to know if this situation has been remedied even in CS5 or CS5.5?
With the increase in screen densities this is getting to be a real issue, and it's just not good practice to render these fonts at what is essentially a fixed pixel size. We're also not getting any younger (I'm in my 60s), and it's not fun to have to strain to see what's on the screen.

User Interface (GUI) fonts like menus and such are set in Windows in the advanced Display settings, even in Windows 7.
That won't (or it may - I don't know) increase things like items in the Files panel, but you can set a larger size and different font for other menus.
The Code panel can be adjust infinitely in the DW preferences.
I work on a 1024X600 netbook and a 1440X900 19" monitor, but I still keep the resolution as high as I can get it, even though I need my glasses to see it.

Why is my user interface monitor resolution dependent?

Similar Messages

Maybe you are looking for