09-10-2007 08:23 AM
09-10-2007 10:10 AM
09-10-2007 12:14 PM
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.
09-10-2007 12:26 PM
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
09-10-2007 01:01 PM
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!
09-10-2007 01:12 PM
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
09-10-2007 02:43 PM
@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.
09-10-2007 02:53 PM
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
09-10-2007 03:18 PM
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?
09-10-2007 05:00 PM