Labview resizing control.....

[tartan5]

Tst,

Ha, I just re-read the end of your last post, "P.S. No, I don't know how to access these in LV 8.x".

I didn't know what you meant at the time, but I do now (LOL)!

Does anyone know if tags are a (hidden) feature that is not going to be supported in the future?

As another approach, could I use control references, and are they (the references) persistant over application launches (ie staticly assigned at compile time, not likely) or do the references change each time the exe is run (likely).  What other method(s) would be the most reliable in saving control state info?

[tst]

I believe tags are available in the RTE (at least for reading), but that would have to be tested. I also believe that they're not going to go away - the very fact that you got a help page for a feature which is private is a good indication of that.

Private features are a problem - they are undocumented, unsupported, may cause crashes, may not work as expected, may change their interface or implementation between versions or may disappear at some version. That's why they're not exposed.
I don't believe object tags will suffer that fate (in fact, NI probably uses them in its own code), but then again, they have been around for at least 5 versions of LV and they're still private, so that's not a very good sign. If you put them in production code, you *might* find out that your application your crash and that you won't get support from NI. I don't think it will, but there is no way to tell.

You could try looking at the LAVA forums' scripting board to see if there is any way to access these in LV 8.x, but essentially they now require a license (which most people can't get) and any workaround will require using tricks.

Object references are not persistent between runs, which is why I said this would pretty much be the only solution - it allows you to hold the data with the object itself. The only other option, really, is to save the data in a file by control label, but that means that you then can't rename your controls, you can't have controls with duplicate labels, you have to account for special characters and you can't operate on decorations.

Just for fun, here's a very basic example I put together of how something like this might work based on your idea of maintaining the original ratio. Obviously, a real system would have to encapsulate everything and handle position and other things as well, but I believe this shows the problems (and the potential) nicely.

[Wiebe@CARYA]

Tst,

Look at the LabVIEW.exe export function ResizeObjFromRef... It uses a
reference, Dx and Dy to resize any object on the front panel. It works on
all objects, even if normal property nodes can't resize them.

Note you need to give a delta x and delta y! So first get the size, then use
the difference between the size and what you want.

Never class problems anymore!

Regards,

Wiebe.

[tartan5]

I did a quick and dirty test last night, where I just handled everything in the resize event.  I scaled the control width/height, the x/y position, and the font for a few different controls.  The text box and switch looked great.  However a control like the modern led button suffered from what I believe to be internal scaling errors (see pic attached).  I could be wrong, but I believe that for sucessful scaling to occur on compound controls (Controls built from multiple components) the internal position / bounds for the subcomponents need to be stored as singles, not integers.  This of course is just my hypothisis, and hopefully someone who knows better will tell me I'm wrong (Because I'd be happy to be!)

Howard

[tartan5]

Hi Wiebe,

I hate to say it, but I'm new to the Labview environment (but not application development).  How do I "Look at the LabVIEW.exe export function ResizeObjFromRef"?  Is their a tool in Labview to do this?

Thanks!

[Wiebe@CARYA]

It is advanced... But not too difficult.

You have to use a Call Library Function node. Then, use View all (not *.dll)
and browse to LabVIEW.exe.

I might be able to post a sample, but not today...

Regards,

Wiebe.

[Wiebe@CARYA]

When you say you "handled everything in the resize event", do you mean your
own resize event inside an event structure, or the auto-resize/resize to
panel ratio option in LabVIEW?

When I do manual resize, I always base the sizes on the panel size, not the
previous control size. So it really doesn't matter how the sizes (and
positions) are stored.

Regards,

Wiebe.

[tartan5]

I used a resize event in an event structure.  Outside the event, when the vi first ran, I got the original panel bounds, plus the control position and height/width.  During resize event I defered the panel update, then calculated the new control size, position, and new font size, updated the control, then re-enabled the panel update.

Panel-Width-Scale = New-Panel-Width / ORIGINAL-Panel-Width

Panel-Height-Scale = New-Panel-Height / ORIGINAL-Panel-Height

New-Control-Width = ORIGINAL-Control-Width * Panel-Width-Scale

New-Control-Height = ORIGINAL-Control-Height * Panel-Height-Scale

New-Control-Xpos = ORIGINAL-Control-Xpos * Panel-Width-Scale

New-Control-Ypos = ORIGINAL-Control-Ypos * Panel-Height-Scale

New-Control-Fontsize = ORIGINAL-Control-Fontsize * Panel-Height-Scale   (Not perfect, but a good first test.......)

[tst]

---

wiebe@CARYA wrote:

It uses a reference, Dx and Dy

---

Is the function definition documented somewhere? I tried to config it, but it keeps throwing exceptions.

In any case, this is definitely nice, but it won't handle everything I'm thinking of (e.g. anchoring, class-specific behaviors, etc.). I also don't really using like things which were not built into the IDE. Then again, scripting stuff is necessarily any safer.

[Wiebe@CARYA]

It's not documented.

Keep the dll settings on "C" calling convention. All LV functions use it.
Then, wire a casted reference (to U32 or I32), and two DSizes as I32.

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 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.

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

My problem was, that (even with scripting) it was not possible to set sizes
of some objects. Ever tried to resize a graph? You can resize the graph
arrea, but who cares? So you need to resize in an iteration, resize the
graph area until the control bounds fit! In <8 it was not even possible to
resize a table or listbox control (you had to calculate the number of
visible rows)... How stupid is that!

Regards,

Wiebe.