Changing window size

[Vaibhav]

Thanks Norbert,

I will do the experiments by keeping the smallest resolution in mind, but you know, having scroll bar to see a complete video will kill that effect which i want to give by full screen project on a wall (gives a virtual presence). But of course, controls eliminated is out of question. Let me study different possibilities, for e.g.,

- by keeping 1280x800 (the highest common resolution between the two modern types of monitors) as my original resolution while making the program. and it will further maximize to 1280x1024 if needed by user. this will be very strange indeed. so better to ask the user to set his monitor resolution to 1280x800 (which is possible in ost latest monitors).

- by keeping 800x600 as the original resolution and that can be expanded to any monitor, again need to see effects.

- creating two different versions of GUI, and call them runtime after determining the monitor resolution. ( Do u have any idea if I need to handle the VI's inside variables/reeferences in a different, aka explicit, way or just have to select specific VI for execution? )

By the way, how/where can I find user interfaces installed with NI TestStand? I have LabVIEW 8.6 professional development version.

Thanks.

[Norbert_B]

Vaibhav,

having two different frontends for a single application is not too easy to accomplish. The main reason is, that most commonly, the conrol of the application is linked to the frontend (also called UI). So the UI has to collect all data necessary for execution as well as showing all information during execution. So simply switching between UIs is a difficult task.

If your architecture encapsulates data and functionality, so it is abstracted from the UI, this task will be manageable. Otherwise, not......

If you like to do something like this, you have to implement some kind of "launcher" which loads the appropriate UI. The UI then uses "the API of your application engine in order to control the applciation".

The TestStand UIs are installed if you install TestStand. LabVIEW does not install those.

If you don't have TestStand, either ask your local NI Sales Representative for an evaluation copy of TestStand or download it from www.ni.com/teststand.

hope this helps,

Norbert 

[Vaibhav]

Norbert,

I am not going to switch from one UI to another at the user's disposal. It will be just in the beginning while launching the application. So it will be just like a normal program/application, except that this application will be called by another application, once (not even in the loop).

I guess you mean the same thing in "If you like to do something like this, you have to implement some kind of "launcher" which loads the appropriate UI. The UI then uses "the API of your application engine in order to control the applciation," no?

I think it will be automatic, I don't have to do any API programming myself. Right?

I am making an experimental GUI selection application, and will post here to make sure if I understood well.

[Norbert_B]

Vaibhav,

yes, you can do the selection in the launcher automatically by asking the OS for the screen resolution (Windows SDK).

My remark regarding the different UIs was not focused on "switching during runtime" but in order to prevent redundancy. If you implement the application in the UI itself, you have two different programs for your application. If you want to change some behavior, you have to remember to change two different VIs; this is not recommended.

hope this helps,

Norbert 

[Vaibhav]

Hi Norbert,

---

yes, you can do the selection in the launcher automatically by asking the OS for the screen resolution (Windows SDK).

---

Windows SDK?

I used VI Server nodes.

---

My remark regarding the different UIs was not focused on "switching during runtime" but in order to prevent redundancy. If you implement the application in the UI itself, you have two different programs for your application. If you want to change some behavior, you have to remember to change two different VIs; this is not recommended.

---

Yes, that's true. So what do you suggest? Can you please explain me how can I prevent the redundancy?

In simple terms, I have made one VI, then I made another copy of that VI, with just a little different arrangement in the front panel. So first I find the monitor resolution, and then call appropriate VI. of course, now I have to maintain two programs. Can you please explain me your approach in simple terms.

Well, I have finally made a sample example of what I am talking about. I have attached the zip file, with all the support files.

1) AlternateGUI.VI - the main application which decides which GUI to call

2) GUI_1.vi, GUI_2.vi - the two versions of the same functionality.

3) Build\AlternateGUI.exe - executable.

The VI names are passed as path, so they don't have to be in memory while called.

Waiting for your comments.

[billko]

Just a comment:

I try to keep my applications limited to 800 x 600 if possible.  If there are more controls/indicaters (hereafter generically referred to as "controls") than would comfortably fit on this panel, I consider some alternatives, all involving tabs.  I might put the most important ones on the first tab in a series of tabs, or I make tabs and group the controls by function or some other category.  Sometimes a hybrid with the main controls on the front panel and categorized tabs is the way to go.  I hope I've given you some ideas.

Bill

[Vaibhav]

Hi Bill,

---

billko wrote:

Just a comment:

  Sometimes a hybrid with the main controls on the front panel and categorized tabs is the way to go.  I hope I've given you some ideas.

Bill

---

Thanks for your comment, but I am sorry, I couldn't understand your point. Can you explain me in simple terms what are you trying to address here?

[Vaibhav]

Hello,

any replies?

[Norbert_B]

Vaibhav,

Windows SDK gives you information about the screenresolution. VI Server does that with the property "Application:Display:Primary Workspace". But i am not sure which version of LV introduced this property.

If you don't have this property available, use the Windows SDK, which is infact a set of dlls in the Windows\System32-folder. The most common dlls are user32.dll, kernel32.dll and other *32.dlls.

When talking about reduction of redundancies: The program has to be a "user interface", not the application itself. So you can simply change the user interface without implementing the application twice. Please refer to "plug in architecture" for more information about this approach.

hope this helps,

Norbert 

[billko]

---

Vaibhav wrote:

Hi Bill,

---

billko wrote:

Just a comment:

  Sometimes a hybrid with the main controls on the front panel and categorized tabs is the way to go.  I hope I've given you some ideas.

Bill

---

Thanks for your comment, but I am sorry, I couldn't understand your point. Can you explain me in simple terms what are you trying to address here?

---

Viabhav:

Sorry that my post wasn't clear to you.  What I meant was if you make an application with a fixed size - that is, one that you've disabled resizing - (I forgot to add that in, which is why the post was probably confusing) of 800 x 600, it would fit nicely on every computer that was capable of running Windows.  The other parts of the post were various ways you can get around having more controls than would fit on an 800 x 600 application.

By "hybrid" front panel, I'll give you an example of what I mean, referring to a virtual power supply.  At the top, I might have display for volts, amps, whether the power supply is operating in a voltage or current controlled setting, and whether or not any warnings or protection occured.  I'd also have the enabled/disabled switch there, too.  In tabs, I would have controls grouped together.  Maybe basic controls like dialing in voltages and current limits on the first tab, things like overvoltage/overcurrent protection settings, front/rear outputs on the second tab and things like bus selection, GPIB address (communications stuff) on the third.  That would avoid control clutter, putting the most commonly used control in the front, relegating the less used ones to other tabs.

All this is so you can avoid the resizing headaches that happen when you resize a window.

I hope I've made myself clear.  If it isn't I'll try again in a different way.  It's my firm belief that if someone isn't learning what I'm teaching, it's because I haven't figured out how that person needs to be taught yet.

Bill