Window sizes - useable area

[PA-Paul]

Hi All,

I'm sure the answer to this is out there somewhere, but I can't find it...

I'm putting together the user interface for an application. We're currently writing it based on a resolution of 1024x768 (as my experience of resizing for different resolutions/aspect ratios is not good!). But I want to maximise the amount of real estate available within that - so there'll be no tool bar and no scroll bars when it runs. But I need to know what useable screen area that leaves me with. How do I find that? Its easy with the scroll bars and tool bar in place, but I can't figure out how much space they take up.

Any one know the answer?

Cheers

Paul

[Minh Pham]

Hi All,

I'm sure the answer to this is out there somewhere, but I can't find it...

I'm putting together the user interface for an application. We're currently writing it based on a resolution of 1024x768 (as my experience of resizing for different resolutions/aspect ratios is not good!). But I want to maximise the amount of real estate available within that - so there'll be no tool bar and no scroll bars when it runs. But I need to know what useable screen area that leaves me with. How do I find that? Its easy with the scroll bars and tool bar in place, but I can't figure out how much space they take up.

Any one know the answer?

Cheers

Paul

I wonder if you have tried these two property nodes for Front panel window?

1. Front Panel>>Keep window proportions

2.Front Panel>>panel bounds

[hooovahh]

I've never had much success with the whole Scale Front Panel Objects (inside Window Size of VI Properties). Things end up not looking right after scaling and stretching.

I'm not sure how to do this but I head a good solution is to design your application with multiple resolutions. Like 1024 X 768, 1280 X 720, and 1280 X 800, then have your code switch between them when resizing. It limits the user alot on their choices but at least it will look the way you want in those resolutions.

[Wire Warrior]

Hooovaah,

Are you suggesting that multiple UI's be created as unique VI's and then launched at "run time" with a dynamic launcing scheme? If not I don't think I under stand how to do this. Interesting way to solve the problem though.

Thanks

Jason

[PA-Paul]

Hoovah - I've wondered about a solution along those lines before, but have no idea how to implement it... Although I did see an openG Vi - write front panel to ini. I've not played with it, but I guess it dumps front panel positions to an ini file? In which case, it may be possible to build an ini file for each resolution and then use the read equivalent of that VI to set the positions/sizes on restart... Still sounds like it would take quite a long time to implement.

I'm playing with using panes to achieve what I want at the moment, but even that's not easy - why can't decide on a "per control" basis which elements within a pane to resize?! I only seem to be able to select one, all or no items to scale with the pane!

Ho hum...

Any other suggestions welcome!

[crelf]

Hoovah - I've wondered about a solution along those lines before, but have no idea how to implement it... Although I did see an openG Vi - write front panel to ini. I've not played with it, but I guess it dumps front panel positions to an ini file? In which case, it may be possible to build an ini file for each resolution and then use the read equivalent of that VI to set the positions/sizes on restart... Still sounds like it would take quite a long time to implement.

You *could* do it that way, but what I think hooovahh is referring to (correct me if I'm wrong hooovahh) is using VI Server to communicate between the FP nodes of a VI that's dedicated to UI interaction and a VI that's acutally doing all the work. All you need in the UI VI is an event loop that has the following responsibilities:

• send the data from controls that are interacted with to the main VI
  
• receive data from the main UI to push to FP indicators that need to be updated (through user events)
  
• watch some Boolean somewhere to know when to close (can be acheived with the user events mentioned above)

So it's a pretty sparse VI, and can be recreated quickly for differing resolutions. Another huge benefit from using this technique is that you can have different UIs for many different user requirements (not just screen resolutions). If you have an operator UI and an engineer UI then you can switch between them without actually screwing with the underlying main VI that's doing all the work. You can also distribute new UIs without touching the main VI (as long as it's designed well). One application is to distribute new UIs like plugins - very powerful.

There was a simple example in the original LabVIEW Advanced Application Development course (the one that VIE wrote) - we had a custom menu for the UI VIs where you could click on a menu and get a submenu showing all the different compatible UI VIs, and you could choose between them dynamically.

I'll see if I can dig it up...

[crelf]

There was a simple example in the original LabVIEW Advanced Application Development course (the one that VIE wrote) - we had a custom menu for the UI VIs where you could click on a menu and get a submenu showing all the different compatible UI VIs, and you could choose between them dynamically.I'll see if I can dig it up...

Okay, so I found it, but it's not in a state I'd be comfortable sharing here (it's got a bunch of our reuse in there that, unless you did the course and got the CD as part of that, I'm not going to share). Anyway, it's pretty easy to re-create. In fact, it's even easier than I mentioned earlier - everything communicates over a common queue: the control and indicator references on the UI VI are sent over to the main VI and then the main VI manipulates their values remotely - so then all the UI VI does is waits to be closed. If that's not clear, let me know and I'll code something up.

[hooovahh]

Yeah Crelf that's what I was talking about, never done it my self but I figured someone here would know what I was trying to say.

[ShaunR]

You *could* do it that way, but what I think hooovahh is referring to (correct me if I'm wrong hooovahh) is using VI Server to communicate between the FP nodes of a VI that's dedicated to UI interaction and a VI that's acutally doing all the work. All you need in the UI VI is an event loop that has the following responsibilities:

• send the data from controls that are interacted with to the main VI
• receive data from the main UI to push to FP indicators that need to be updated (through user events)
• watch some Boolean somewhere to know when to close (can be acheived with the user events mentioned above)

So it's a pretty sparse VI, and can be recreated quickly for differing resolutions. Another huge benefit from using this technique is that you can have different UIs for many different user requirements (not just screen resolutions). If you have an operator UI and an engineer UI then you can switch between them without actually screwing with the underlying main VI that's doing all the work. You can also distribute new UIs without touching the main VI (as long as it's designed well). One application is to distribute new UIs like plugins - very powerful.

There was a simple example in the original LabVIEW Advanced Application Development course (the one that VIE wrote) - we had a custom menu for the UI VIs where you could click on a menu and get a submenu showing all the different compatible UI VIs, and you could choose between them dynamically.

I'll see if I can dig it up...

A simpler way (and easier) is to use a good old fashioned data pool. Your UI is completely separated from the data therefore you can not only bolt on new user interfaces, but create different views of the same data.

Edited October 21, 2009 by ShaunR

[crelf]

A simpler way (and easier) is to use a good old fashioned data pool. Your UI is completely separated from the data therefore you can not only bolt on new user interfaces, but create different views of the same data.

Well, the user events are, in a way, a data pool but with less coding required by you.

If you're talking about a global of some sort, then yes - as long as you're okay with race conditions and possibly missed events - and that's a totally valid thing to do as long as you understand that. That's also a good method if you do want that total disconnection of the UI. If that's what you're after, another method can be addressing the UI VI front panel elements by name using VI server.

[jgcode]

Okay, so I found it, but it's not in a state I'd be comfortable sharing here (it's got a bunch of our reuse in there that, unless you did the course and got the CD as part of that, I'm not going to share). Anyway, it's pretty easy to re-create. In fact, it's even easier than I mentioned earlier - everything communicates over a common queue: the control and indicator references on the UI VI are sent over to the main VI and then the main VI manipulates their values remotely - so then all the UI VI does is waits to be closed. If that's not clear, let me know and I'll code something up.

Hi Crelf

I have the Book/CD. It contains really cool methods of separating the UI and Engine.

Do you prefer the Dynamic Events over the Queue method?

Do you have any more good points that may have been developed since then with respect to this architecture?

Cheers

JG

[PA-Paul]

Crelf wrote:

You *could* do it that way, but what I think hooovahh is referring to (correct me if I'm wrong hooovahh) is using VI Server to communicate between the FP nodes of a VI that's dedicated to UI interaction and a VI that's acutally doing all the work. All you need in the UI VI is an event loop that has the following responsibilities:

send the data from controls that are interacted with to the main VI

receive data from the main UI to push to FP indicators that need to be updated (through user events)

watch some Boolean somewhere to know when to close (can be acheived with the user events mentioned above)

The application I'm working on does vaguely follow this, in that I've written an "engine" VI, which is based on a queue driven state machine and I'm now writing a UI. The idea being that the UI vi (based on an event structure with the engine sitting in Parallel waiting for the UI to put commands into the queue) drives the engine and also tells the engine when to quit when a user hits the exit button on the FP. But the way I was going to send data back to the UI was via a second "uplink" queue, but might I be better off sending a control refnums for all of the controls on the UI and doing writing to the UI front panel like that? What happens then if I write a second UI which doesn't use all the same controls? Won't that cause problems?

Anyway, now I think about it, if I've written the engine right, making multiple UI VIs for different screen resolutions should be doable simply by copying the existing UI and then re-arranging the front panel controls/indicators to fit and then saving it as UI 1024x768 or somesuch...

Thanks for the thoughts!

Paul

[Daklu]

...unless you did the course and got the CD as part of that, I'm not going to share...

*grumble* *grumble* ...crotchety old geezers taunting us with code they have but won't post... *grumble*

Do you prefer the Dynamic Events over the Queue method?

Do you have any more good points that may have been developed since then with respect to this architecture?

*anxiously awaiting answers to these questions*

Creating thin, bolt-on UIs has driven my recent interest in the Observer pattern. Observer seems like a natural fit for this kind of task but I haven't figured out the best way to implement it yet.

[Daklu]

But the way I was going to send data back to the UI was via a second "uplink" queue, but might I be better off sending a control refnums for all of the controls on the UI and doing writing to the UI front panel like that? What happens then if I write a second UI which doesn't use all the same controls? Won't that cause problems?

I haven't done any benchmarking but everything I've read indicates a queue messaging implementation would be better/faster/stronger/smarter/prettier and offer tantalizing coversation to boot! Messaging also decouples the engine from UI better, making it easier to modify the behaviors of either.

However, control refnums is (probably) faster to implement. If you do go this route a second UI that uses different controls won't cause problems as long as the engine supports the superset of all controls on all user interfaces.

Chris has way more experience than I do so I'm not really qualified to disagree with him... but here I go. For anything except very simple VIs that won't change ever, I'd strongly recommend queues or user events over control refnums. IMO, there are too many disadvantages with control references to even consider using them in this situation.

(After rereading Chris' post, I see he didn't actually suggest using control references; he was simply explaining the demo's implementation. Lucky me... I didn't disagree with him.)