Hi folks,
I’m updating my UI pieces to ETO (It is time, and I’m excited). However, I’m not sure how to get my docking dialogs to resize in a width change when docked. I have an event handler that triggers with the event OnSizeChanged, and it resizes all of my components appropriately. It will fire with a height change, but not a width change.
So my question: is that by design, and if so how do I catch and handle the width change?
Arthur
Hey @Arthur,
The SizeChanged event should fire for any changes (width and height). Perhaps the controls within the panel are not letting the width get smaller, set the size explicitly somewhere, or are listening to the event on the wrong control.
If you can post a sample of what you are trying to do I can help figure out what might be going wrong.
Cheers,
Curtis.
Hi Curtis,
Thansk. That would be great. In my constructor for my Panel,IPanel control, I do the following:
this.SizeChanged += update;
It seemed to me this was the panel’s built-in inherited event that was meant for this.
And then update looks like this:
public void update(object sender, >System.EventArgs e) { this.Width = this.Parent.Width; SimSetBox.Width = this.Width; TimeBox.Width = this.Width; OutputFolder.Width = >this.Width; colorcontrol.Size = new >Size(this.Width, Height); colorcontrol.Invalidate(); Loop.Width = (int)((double)this.Width * 0.75); Invalidate(true); }
…these things being my tables, layouts, and groupboxes.
As I stated, this fires if I change the height by dragging on one side, but not if I drag a side. If I drag a side, and then drag the bottom, it updates the width.
I confirmed this behavior by setting a breakpoint as well. The point is hit on a height change, but not a width change.
So - thoughts? I might do a github commit this evening, and I can send you the file then.
Arthur
Hi @curtisw
Here is my ETO UI which is having trouble with this.
Here is what it looks like:
If I drag an edge for a width change, I get this:
If I then drag the bottom for a height change, I get this:
What do you think?
:::Aside - it actually looks much nicer than my original Windows Forms control, so props - if only I can get this behavior right, though…
Arthur
I think you’ll be better off if you can get it to work with automatic Eto layout features rather than manual adjustments upon events firing.
I’ve been using the DynamicLayout but there are several others available (I think I recall one expert here recommending StackLayout).
If you post small, focused questions about how to get groups of controls to behave, there are a few experts here (not me) who seem very helpful.
I spent a long time fiddling to get:
An upper left checkbox that doesn’t resize
An upper right row of buttons and combobox that’s anchored to the right edge of the form without the controls resizing
A section of controls in the main part of the form which expands the right but not the left section when the user resizes the width.
All of that is doable with nested DynamicLayouts (built up by row) and Panels (to get padding around things). I think that covers all of the needs I see in your screenshot above.
The result wasn’t all that intuitive from my prior experience in windows/mac ui libraries and html/css, but after the learning curve the behavior makes sense.
Hi @Nathan_Bossett,
Thanks for the input. However… these are all based on DynamicLayout. It is actually a number of DynamicLayout objects inside a DynamicLayout object.
Without attaching them to an event, they didn’t resize at all. I can see in your example, is that a modal dialog? Could the difference be that I’m using a registered Docking Dialog in Rhino instead?
In other words, during the loading of the plugin, it calls the following line:
Rhino.UI.Panels.RegisterPanel(this, typeof(UI.Pach_Visual_Control), “Pachyderm Particle Animation”, Properties.Resources.PIcon1);
kind regards,
Arthur
My form is an Eto.Forms.Form used nonmodally (it sits over Rhino but lets normal user flow in Rhino continue while it’s open).
I don’t THINK the layouts care what ‘owns’ them (form or docked panel) so long as it tells them how big they are when the owner gets resized but I haven’t built any docked panels yet. It does seem like your dynamic layouts are getting the ‘correct’ update messages and just aren’t configured to do what you actually want them to.
Things that I don’t want resized (such as the buttons) I assign a width to.
Things that I do want to resize (sometimes nested), I don’t assign widths to but just use AddRow to toss them into the sometimes nested dynamic layouts.
It was a little fiddly figuring out what Eto would decide it wanted to resize vs hold constant but that seems to be my learning curve rather than inconsistent behavior.
Looking at your example, I’m not sure what should be resized except possibly the file path text box: all of those controls seem to have relatively fixed width requirements at design time unless as a design decision you want that trio of buttons to be full width.
Hi @Nathan_Bossett,
I appreciate your help, but this isn’t my problem. The components resize in the way I need them to, but not when I need them to.
The entire dynamic layout should be resized when I change width (and all other components will follow suit). It does this as long as you are also changing the height.
If you just change the width, it looks like this:
Arthur
I’m afraid that I don’t understand what the ‘I want it to…’ behavior is then. I’ve reread the thread a few times and all I see is you saying what it does, not what you want it to do. (I do see the description of when the event fires and when it doesn’t, but not the desired visual output- actually, I like the when-width-dragged output better than the height-dragged)
Sorry…
Alright, let me try again…
You see the image in my last message? When I drag the side of the container, it should not look like that. It should look like this:
When I drag the side, it will not resize the components. When I drag the bottom, it will resize the components. I need it to resize whenever the size of the container changes, whether it be a width change or a height change. Right now it does not resize on a width change.
Arthur
Ok, so you want a two column layout (except for the three buttons) in which each pair of components stays lined up against its respective far edge?
Here’s how I did that on a basic form (definitely responsive to width resizing). I’m not going to claim that it’s the best way to do it, only the best way I’ve figured out so far.
If that doesn’t work in a docked panel I’d wonder if it might be a bug because I thought they were supposed to respond similarly regardless of what contains them but would enjoy playing with sample code (haven’t done docking with Eto yet).
internal void ShowMe()
{
Eto.Forms.DynamicLayout lay = new Eto.Forms.DynamicLayout();
Eto.Forms.DynamicLayout lay2 = new Eto.Forms.DynamicLayout();
Eto.Forms.DynamicLayout lay3 = new Eto.Forms.DynamicLayout(); ;
Eto.Forms.Button btn = new Eto.Forms.Button();
Eto.Forms.Button btn2 = new Eto.Forms.Button();
btn.Text = "Hello World!";
btn2.Text = "Good bye world!";
lay.AddRow(null, btn2);
lay3.AddRow(btn, null);
lay2 = new Eto.Forms.DynamicLayout();
lay2.AddRow(lay3, lay);
lay2.Height = 30;
lay2.AddRow(null, null);
Content = lay2;
Show();
}
Hi,
Thanks for this. Your code does behave as expected, so I tried disabling some of my code tracking the OnSizeChanged event, and now it does work properly.
I’m a little baffled because I started looking for those events because I couldn’t seem to get it to behave this way without them. I guess there was something I was overlooking. Anyway, thanks for your help.
If you would like to play with sample code, here is how I implemented this:
Arthur
Glad it worked out!
Thanks for the panel code references.
Interestingly, we did resolve this for Docking Dialogs, but I can’t seem to get the same behavior for object properties pages, a different kind of docking dialog.
I don’t really need this resolved for my own work, because when I handle the SizeChanged event in this form, the event fires whether we size vertically or horizontally, as expected.
Still, it looks like these two items don’t behave entirely the way they are supposed to, for different reasons.
I have workarounds, but if anyone cares that this is happening, here is what I think is going on.
All the best,
Arthur