GUI construction issues

  • Thread starter Thread starter Zytan
  • Start date Start date
Z

Zytan

I have a tab control, with several tabs, with RichTextBoxes in a few
of them, they are all dock = fill. One of them becomes larger than
the rest (position = 0,0 instead of 3,3). It's not a big deal, but I
hate that this GUI editor just doesn't work sometimes, and it's
noticeable. Does anyone know why these quirks occur, and how to fix
them?

thanks,
Zytan
 
For the single tab page that this doesn't work on, if it make the
control not filled, and drag it to meet the top-left of the tab page,
I can see that it chooses its resting place 3 pixels off. There are
no other controls that could possibly effect this. Unless other
controls in other tab pages are invisibly causing issues, but I can't
see this. The editor is simply broken.

Zytan
 
Even manually changing the designer code to be like the rest doesn't
fix the problem. The code is even left changed to my settings, so it
doesn't change it back. But, when the program runs, or the form is
shown in the GUI designer, it shows "Fill"ed more than it should be,
where the rest are spaced away 3 pixels.

Zytan
 
Even manually changing the designer code to be like the rest doesn't
fix the problem. The code is even left changed to my settings, so it
doesn't change it back. But, when the program runs, or the form is
shown in the GUI designer, it shows "Fill"ed more than it should be,
where the rest are spaced away 3 pixels.
Click to expand...

While I can't rule out the "editor is broken" theory, I haven't had any
such issues with my tab controls in my forms. I've never seen the
behavior you describe.

I strongly suspect that there's some sort of layout issue going on and
that the behavior you're seeing is "by design", even if frustrating. You
should look carefully at all the properties for the tab that doesn't work
and compare them to the tabs that do work. I think it's likely
*something* is different, and when you find out what's different you'll
probably find out how to fix it. :)

Pete
 
While I can't rule out the "editor is broken" theory, I haven't had any
such issues with my tab controls in my forms. I've never seen the
behavior you describe.
Click to expand...

I've seen things like with with tabs a lot. Sometimes I'll put a
RichTextBox in there, and anchor it to all sides, and snap it to all
sides (made one side is snapped to a button or something) and when I
run the form, the positioning of the RichTextBox is changed. Manually
setting it up again fixes the issue.
I strongly suspect that there's some sort of layout issue going on and
that the behavior you're seeing is "by design", even if frustrating.
Click to expand...

I don't think so, because I have multiple tabs of the SAME tab
control, and each tab has just one RichTextBox with dock = fill. So,
I can't imagine why the behaviour should change from one to the other.
You
should look carefully at all the properties for the tab that doesn't work
and compare them to the tabs that do work.
Click to expand...

I looked in the form designer code, and they are all the same, except
the position values. Even when I go and manually change the position
values to be the same as the rest (which is what the GUI designer is
supposed to set), the GUI designer and the run-time app both choose
different position values, even though my code remains unchanged (the
position values in the code remain the same as the others, after I
changed it to be the same). So, that implies that the positioning
logic of dock = fill, in both the GUI designer and the run-time, are
choosing new positions (that is, the position values are totally
meaningless, since they are computed in real time).

So, you are correct that it is form positioning logic. I just don't
see why the logic should differ from one tab to another tab, in the
same tab control, when both tabs only have a single dock=fill
RichTextBox.
I think it's likely
*something* is different, and when you find out what's different you'll
probably find out how to fix it. :)
Click to expand...

I agree. The evidence suggests that the form positioning logic *is*
using different data, and thus arriving at a different result. Just
*what* is different?

(This is not a big deal, it's just an annoyance.)

Thanks, Pete

Zytan
 
Back
Top