Labview resizing control.....

[tartan5]

Hello All,

I am in the middle of developing an application that will be bundled with our product.  I have developed many such applications using visual studio, however this is my first adventure using Labview.

As many of you know, one of the most common variables in distributing an application is the und-user screen resolution.  With the relatively recent explosion of differing screen resolutions and aspect ratios, making applications resolution independent is even more important than ever.  Along with this, giving the customer the ability to resize the appliction at will is a huge benefit.  On many occasions I have walked into a customer's site to see my application shrunk down to a corner of the window, where the use can still see it, almost like an indicator.

For visual studio, I had purchased a third party control.  Plunk the control onto the window (it became invisible at run time) and all of the controls, fonts, etc resized as the screen was resized.  When visual studio went to .Net, this particular control no longer worked.  I had to evaluate 5 different controls to get one that even came close to working properly, and even then I had to work with support and beta test many versions of that control to get the bugs out. 

Now I know that Labview has the panel resize options, etc and I have played around with them.  However, as most of you know, many problems still exist, such as the fonts not resizing, and multiple window changes cause control distortion, even when brought back to the same panel size.

So, what I am wondering is this:  A) Does anyone make a control that I can purchase that does a good job in this regard, or B) if not, how about opening a discussion on how to implement a control to do just this?

If I need to, as I forsee doing more applications with Labview, I could tackle this on my own, but as I am new to LV my learning curve may be steep so I'd like to draw on the abundance of talent and experience I've read on this board.

I was thinking of a control that would enumerate all of the controls, labels, etc on the panel.  During the development cycle it would store all of the control / font sizes (internally? to a file?) as the developer intended the panel to appear.  At execution time (after it is built) each time the panel is resized, the control would set the height/widths and font sizes as needed.  Why store the development time sizes?  To eliminate the errors that creep up when sizing the panel up and down multiple times.  I assume this occurs in LV since original size is not tracked and pixel displacement is non-uniform across the pane, and the moving / scaling is non-integer in nature but gets applied to integer properties.  For example, when resizing from the lower right corner, to say half the width / height, controls in that corner move ALOT while controls in the Upper-left only move slightly, yet all controls are scaled in size the same amount.

I would love it if someone could dope-slap me upside the head and say "just do this".  If not, what are some of the methods I should be looking at, and pitfalls to avoid?

Thanks for your input!  

[Wiebe@CARYA]

What you suggest (all resize info in a file) might be a good solution for
you, but not for others. That is why there is no "control" (we call it VI's
or library, a control is an object on your front panel only). Another
problem is that there are a lot of ways to resize controls. By percentage,
some might be fixed, by pixels, by pixels up to a maximum, or minimum, left
right top or bottom aligned, etc. So I usually make a vi that does the
scaling for each individual front panel.

If you have money to spare for this, I'm sure someone can make exactly what
you want (depending on the amount of the money). But you won't get an "out
of the box" solution, but rather a framework, or a set of utility VI's. If
you're lucky, someone over here might even make it for you...

It's not too difficult to do what you want, but it's not very easy either.
You'll run into a few problems that are hard to solve...

If you'll give it a try, there are plenty of people that help you out over
here.

Regards,

Wiebe.

[tst]

I actually did look into writing such a framework (actually based on what I saw with VS.NET, where you can set all kinds of anchoring and resizing options) and I can tell you in advance that it is a lot of work.

Essentially, my idea was this (I'm saying was because I'm probably not going to implement it, although I still have my papers on this somewhere):

• Enumerate all the controls in the front panel. This needs to be done recursively for panes, clusters and tab controls. Each object in the FP can have tags associated with it, although that is an unsupported feature. You have to use these, because otherwise you would have to recognize controls by their names, which I really don't like and I believe this can work for decorations as well. This is elegant because you can store any kind of data you want and it is saved with the VI. It is also easier when you need to load the data. The main problem is that this step takes time and would need to be performed during the splash screen.
• At edit time, you need a floating panel which will change its contents based on the class of control you selected (e.g. a table would have options for keeping a constant number of columns or not when the panel is resized). The main problem with this (and that's the main problem in general) is that you have to write the GUI and implementation for every class of control you will want to support. This is both because each class has some unique requirements and because setting the size of a control is done through different properties for each class.
• At run time, you just run it as a separate process which enumrates the objects at the beginning and then performs the resize\anchor operations with each resize. Again, this requires code to be written for each class of control, but more importantly, I'm afraid the performance might not be very good. This could probably be worked around by defering panel updates, but I didn't get this far because it seemed like more work than I wanted to do for a feature I wanted, but didn't really need.

LV 8.x should have helped this at least somewhat with panes, but I still wouldn't mind having this functionality (at least the anchoring) built into the editor. I suggest you visit the Product Suggestion Center and make NI an offer it can't refuse.

If you're willing to do quite a bit of work to get this to happen, I can try working on this with you.

[falkpl]

I have been using labview since 4.0 and have seen much improvement on the GUI fromt but the resize has always been a problem.  Anchors and resize bars would help alot but are not implemented.  I have also looked at developing a toolkit but worry that after spending much time doing this monsterous task it would appear as a free feature in the next version of labview.  Some things to keep in mind to simplify this resize issue. 

1.  Always put in a minimum window size on resizable windows.

2.  Layout all resizable controls on the smallest pannel size (this avoids the resizing hystoresis).

3.  Leave enough room of captions (use captions instead of lables on FP)

4.  use vector graphics on custome controls and pictures.

5.  Put special resizing issues into your resize event cale.

6.  Use panes

There are so many issues with resizable pannels

  Paul

[tartan5]

Hello Tst,

Even with the flexibility in VS, I found it difficult to acheive good results, hence why I had to resort to a third party tool. 

Wouldn't life be grand if every control included a set of read-only properties, say XOrigin, YOrigin, XSize, and YSize that were updated as you move the component around during development, but was fixed as you run the compiled program.  This would at least give you an absolute reference to use as you resize the panel, and eliminate the truncation errors we now see.

One interesting control I tested actually increased performance by grabbing an image of the window when the resize handle was moved, placing the image over the window, resizing the image as the corner was dragged.  Then when the corner was released, updated all of the controls / fonts as required, then hid the image.  It actually worked amazing well vs resizing the controls in real-time.......That might be very do-able in labview, show a picturebox, have it size to the window, etc....

On another note, is it possible to recurse through an xcontrol and get all of the components at run time?  I have just finished developing my first xcontrol (so it's fresh on my mind) but I'm not sure how the xcontrol is viewed by the environment (ie if all the sub-components can be reference / obtained)?

On your first point, are you suggesting that the resizer control would add the tags to each enumerated control itself?  That's almost as good as my wish above (LOL)....

I'm thinking that the simplest resizer would not have various anchoring options for each control.  Would you agree that it would be increadibly useful to just have a control that scaled everything proportionly to the window resize? So for any resize (or monitor resolution, etc) the resulting screen looks most like the screen as origionly developed?  Of course if you get too small, you can't read fonts, etc but that is where the min window size comes in...... However I can see where issues may come up (such as graphs) that might be a bit tricky, and where users may want to maintain the graph size as a priority over other controls.

Thoughts?

Best regards and thanks for your input!

[tartan5]

Hello Paul,

Could you elaborate on point 3 (captions vs labels) and point 6 (Use panes) and what issues you may have seen?

Thanks!

Howard

[tst]

---

@tartan5 wrote:

Wouldn't life be grand if every control included a set of read-only properties, say XOrigin, YOrigin, XSize, and YSize that were updated as you move the component around during development, but was fixed as you run the compiled program.  This would at least give you an absolute reference to use as you resize the panel, and eliminate the truncation errors we now see.

---

You could do that using tags if that is what is needed.

---

One interesting control I tested actually increased performance by grabbing an image of the window when the resize handle was moved, placing the image over the window, resizing the image as the corner was dragged.  Then when the corner was released, updated all of the controls / fonts as required, then hid the image.  It actually worked amazing well vs resizing the controls in real-time.......That might be very do-able in labview, show a picturebox, have it size to the window, etc....

---

It probably would not be needed. You can just defer the panel updates until after you're done with your resizing. I was thinking the performance issue would be in going over all the controls and changing their size, but there is probably not going to be one.

---

On another note, is it possible to recurse through an xcontrol and get all of the components at run time?  I have just finished developing my first xcontrol (so it's fresh on my mind) but I'm not sure how the xcontrol is viewed by the environment (ie if all the sub-components can be reference / obtained)?

---

No idea. I use LV 7.0, which does not have them. My guess would be that you can't, at least in the earlier versions. Maybe the newer ones allow this, but I would doubt that. You might need to write a resize method (or ability or whatever they're called) for the control. That is one example of how writing a generic framework would be complicated.

---

On your first point, are you suggesting that the resizer control would add the tags to each enumerated control itself?  That's almost as good as my wish above (LOL)....

---

Well, I wouldn't call it a control. It would be a special resize handling (TM) process, but yes, that is exactly what I'm suggesting. See attached for a simple example.

P.S. No, I don't know how to access these in LV 8.x.

[falkpl]

Point 3:  Using captions is good since changing lables can effect your code.  Some functions will work by referencing the lable of a control/indicator essentially like a traditional variable name.  In the resize event I have handled some resize issues by changing the working of a caption.  I.E. lets say on a full screen I use a caption called "MAXIMUM INTENSITY"  In my resize case I handle special cases where the size of the controller gets smaller than the width of the MAXIMUM INTENSITY" caption then I have the code replace the caption with "MAX INTENSITY" or even "MAX I".  The code in uneffected by these changes (No side effects)

Point 6.  If you use panes you can break up your pannel to smaller divisions which is easier to handle.  You can have some panes resize controls automatically where others will not,  they also act as anchors for some controls (lock controls in a pane).  It is not that easy to manage many panes though.  Unfortunatly the only way I have figured out how do make panes is with splitters which can be ackward to use.

One other trick I have used is to put a resize font in the resize event.  Get a reference to all controls (Controls[] property) and set the font size = some divisable of window width.

YES this is a problem with labview (I have very few complaints about labview and write 100s of vi each week but the lack of resize control like anchors and docking do bother me)

Paul

[tartan5]

Tst,

I looked up the get tag method, in the help is says "Available in Run-Time Engine and Real-Time Operating System = no".  Does this mean it can't be used once it is built into an exe?

[tartan5]

Another question.....How the heck do you get the tag.Get tag invoke node?  I can run the example you posted, but for the life of me I can't create a new one from scratch.  I'm using LV 8.5......All I see is the attached....