Can't Programatically Resize Graph?

[10Things_Rob]

Is it really not possible to programatically resize a graph control (Bounds property is read only ?!?!?!)

You must be kidding me.

Surely I am missing something?

I suppose a workaround is to make it giant and then resize the plot area?

LV 8.0.1

[Jason King]

Resizing the plot area will have the side-effect of resizing the graph.  I wish I could tell you the rationale behind this, but the behavior predates my tenure at NI.

J

[Ben]

"Surely I am missing something?"

Maybe.

Try

Plot Area:Size:Width

and

Plot Area:Size:Height

Ben

[tst]

---

@Jason King wrote:
I wish I could tell you the rationale behind this, but the behavior predates my tenure at NI.

---

So, how about asking the all-mighty Greg or Steve? Why is the Bounds property read-only? It would be nice to have a single property for the GObject class so that we can upcast and still resize our objects (and also so we don't have to chase the property each time we want to resize, not to mention the fact that in this specific case the Plot Area properties control the size of the graph and not of the entire control, which is bigger).

P.S. Rob, I understand you gave another "10 things..." presentation at NIWeek. Are you going to upload that one as well?

Message Edited by tst on 08-17-2006 12:28 AM

[tst]

I just ran into this thread again and I realized that this is one of the "why?" questions we've mentioned in the past that would require an answer from one of the bigger cannons.
So, how about it, Jason? Can we get one of them in to explain this?
How about changing it for future versions?

[Jason King]

I don't know that the historic "why" is going to help you out at all.  I can certainly make an educated guess.  The "bounds" property is provided by the base "control" class (if you weren't aware, we have a class hierarchy for all of our objects exposed via VI Server).  Our objects are quite diverse, and their "bounds" represent different things as they have different parts - increment/decremnt arrows, digital displays, cursor legends, labels, etc.  As such, they would need independent code to handle sizing properly when the bounds property is written.  I imagine that when the bounds property was added, we didn't have the time (nor intent?) to do all the work necessary to make writing this property work.  Reading this property is easy, though, as we just cache this in a field of the object.  As the need has arisen, people have gone and added writeable "bounds" properties that make sense for the type of object they added it for.  For the graph, I'm not certain if the rectangle returned by the bounds property includes things like the cursor legend and plot legend - I'm guessing it does.  Setting the size via this field doesn't make much sense - the chances are you're trying to size the plot area/main graph area, and not the other objects. Exposing the property this way makes things easier on the user, even if it isn't exactly what you might expect.

This is just my educated guess.

J

[tst]

This was my guess as well and I do know all about the class hierarchy (and as I even mentioned earlier, I believe the Bounds property comes from the Gobject class and not from the Control class).

As I mentioned, however, this does not necessarily make it easier for the user because users then have to start hunting for the resizing properties all over the place and because you don't know what the actual size of the control is without checking the Bounds property (this is important because it could affect the placement of other UI elements as well). Since each object seems to have one element which would significantly affected by resizing the entire object I would expect that it shouldn't be terribly complicated to do this, but I haven't given it much thought and I don't know if it's worth spending time on.