LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview resizing control.....

Not sure why your method won't work. Seems to me the double to integer
conversion can only result in one pixel errors. Unless you do your
conversion to early in the calculation. Panel-Width-Scale should be a
double...

I use a set of VI's (all basic math) to do my resizing. All based on the
panel dimensions.

So I have a VI "split rect by percentage" and "split rect by pixels". It
takes a Hor/Ver boolean as input, so I can split the input rect both ways.
It also has an input From Right/Bottom that is used to split the rect at the
pixels from the bottom. Some other VI's: "align controls", "position control
in rect", "set size", "set height", "set width", and then some...

Works like a charm.

It might be difficult though to put all options (I create a VI for each
panel) in a configuration file.

Regards,

Wiebe.


0 Kudos
Message 21 of 32
(4,013 Views)
Oops. One thing though..

The Dx and Dy are pointers to the values! Sorry about that.

Regards,

Wiebe.


0 Kudos
Message 22 of 32
(4,010 Views)
Hi Wiebe,
 
Do you just do your resize once, when the panel is done being resized?  Perhaps that introduces less errors into the controls themselves.....I was continously updating the controls as the panel was resizing.  Now, keep in mind that I was also resizing the panel such that the Modern boolean push button control was significantly smaller than when I placed it on the form.  Then, when bringing the form (and hence the control) back to original size, some of the control design elements were distorted, while others seemed OK. 
 
You can see this in the design environment...... Drop a modern Boolean push button, resize it small. then back to original size.  At least in 8.5, I can't get it to look like the original.....
0 Kudos
Message 23 of 32
(4,008 Views)


wiebe@CARYA wrote:

The Dx and Dy are pointers to the values! Sorry about that.

Ah. That was the key. The attached example shows how to use it nicely. The problem is that not all controls play nicely with this when you use the total bounds rect and it's not entirely accurate when you use the master bounds rect. It also doesn't work fully for all controls (see down).


I'm not sure what you mean by "anchoring, class-specific behaviors, etc". It handles all objects on the front panel, also controls inside clusters, subpanels and tabcontrols.

It may handle all controls, but it will only resize them. I also wanted to do anchoring (e.g. anchor a control to the bottom right corner instead of the upper left, although this is probably easier now that we have panes) and class-specific resizing (e.g. when you have an MC listbox, you can decide whether resizing the control would make the columns\rows larger or add more). For that, you would need some extra code for each class, both for configuration and for implementation.


It does not allow you to resize object, that can't be resized by hand. Like a simple numeric control: it can't be resized vertically. So it will only resize horizontally.

Sure you can, just look at the example I posted in reply 12. This demonstrates another problem with this - with class specific properties, you can change the aspect ratio of every control (I think), even ones where you can't control this manually - for example, a gauge has a housing size property.


Don't you mean: "Then again, scripting stuff is *NOT* necessarily any safer."?

Yes, that's what I meant. Maybe spell checkers should be made context sensitive and become syntax and logic checkers as well Smiley Wink


Ever tried to resize a graph?

Yes I did, and I used the exact method you described - resize the plot area until the total control size reaches what you want.


___________________
Try to take over the world!
Message 24 of 32
(4,002 Views)
I also put my code in the resize panel event, so it updates after each
resize. I filter this event, so it only uses the last resize event.
Otherwise you'll get the latency effect, where all the controls keep
resizing 10 seconds after you made the movements.

I see what you mean with the boolean push button. This is a bug, and it will
be hard to find a work around...

Regards,

Wiebe.


0 Kudos
Message 25 of 32
(4,000 Views)


@tartan5 wrote:

Drop a modern Boolean push button, resize it small. then back to original size.  At least in 8.5, I can't get it to look like the original.....

OK, this definitely looks like an issue of integer math rounding errors. I'm not sure whether this is a bug or not. It is definitely unwanted behavior, but I don't think there is anything that gurantees you would get the same aspect ratio even when controls have vector graphics.

For this to work, the internal representation of the sizes of these control should probably be changed to floating point and only be rounded for the actual display. I don't know whether this should be considered as a bug, but I suggest you go to the Product Suggestion Center and try giving a detailed request about why this should be changed.


___________________
Try to take over the world!
0 Kudos
Message 26 of 32
(3,993 Views)
>
> I'm not sure what you mean by "anchoring, class-specific behaviors, etc".
It handles all objects on the front panel, also controls inside clusters,
subpanels and tabcontrols.
>
>
> It may handle all controls, but it will only resize them. I also wanted to
do anchoring (e.g. anchor a control to the bottom right corner instead of
the upper left, although this is probably easier now that we
have panes) and class-specific resizing (e.g. when you have an MC
listbox, you can decide whether resizing the control would make the
columns\rows larger or add more). For that, you would need some extra code
for each class, both for configuration and for implementation.
>

But this anchoring can be done by calculation. Once you can set the size and
position, it's all a matter of picking smart VI's that
do these calculations.

The class specific stuff remains a pain. For a graphical programming
language this stuff sure has bad support!

>
> It does not allow you to resize object, that can't be resized by hand.
Like a simple numeric control: it can't be resized vertically. So it will
only resize horizontally.
>
> Sure you can, just look at the example I posted in reply 12. This
demonstrates another problem with this - with class specific properties, you
can change the aspect ratio of every control (I think), even ones where you
can't control this manually - for example, a gauge has a housing size
property.
>

I ment that the ResizeObjFromRef didn't do this.

Regards,

Wiebe.


0 Kudos
Message 27 of 32
(3,985 Views)

Any update on this discussion.

 

I want to be able to resize an intensity graph during run-time.

 

Ideally, the user can drag a corner and have the graph resize.

 

I currently have one VI where I have a single intensity graph which resizes to the pane - the user just drags the VI pane and it works great.

 

However, if more than one control on the pane needs to be visible, it creates difficulties.

 

Thanks,

 

Don

 

 

0 Kudos
Message 28 of 32
(3,361 Views)
.......what I hoped to be able to do was something simple like the following but because one cannot write to the 'bounds' property of an intensity graph control during run-time, and the 'position' property of controls only exposes 'left' and 'top', this type of approach is not workable (as of LV8.5)....Don
0 Kudos
Message 29 of 32
(3,352 Views)

Hi DonRoth,

 

I think this KB in combination with your event structure may be what you're looking for.

 

 

Jeff | LabVIEW Software Engineer
0 Kudos
Message 30 of 32
(3,332 Views)