On Sun, 27 May 2007 12:48:56 -0700, giddy <gi*******@gmail.comwrote:
[...]
Somehow when i _resize_ the scrollable space doesnt adjust correctly.
My calculations are perfect.
I beg to differ. :)
I Set AutoScrollMinSize.Width to the
current cient width , and the height to the number of rows X (space +
boxHeight).Once you resize , the scrollbar adjusts with this odd
additional space , if you scroll on the bottom you'll see a that
space.
I saw a variety of problems with the code you posted. Key problems though
included *two* different ways for you to leave the OnResize() method
having called SuspendLayout() but without calling ResumeLayout(), as well
as inefficient and buggy calculations for the rows and columns. I didn't
rewrite it completely, but here's a version that at least corrects what I
felt were the most problematic issues:
protected override void OnResize(EventArgs e)
{
if (ClientSize.Width == 0)
{
return; //incase the form is minimised.
}
cols = (int)Math.Ceiling(((double)ClientSize.Width / (space
+ szClr.Width)));//the cols that can fit
rows = (int)Math.Ceiling((double)_clrBoxes.Count / cols);//the
number of rows NEEDED
//reposition all boxes
this.SuspendLayout();
Point pt = new Point(space, space);
int b = 0;//box count
int xMax = ClientSize.Width - szClr.Width;
while (b < _clrBoxes.Count)
{
if (pt.X >= xMax)
{
pt.X = space;
pt.Y += (space + szClr.Height);
}
_clrBoxes[b].Location = pt;
pt.X += space + szClr.Width;
b++;
}
this.ResumeLayout(true);
base.OnResize(e);
}
Note that, among other things, when you handle everything else correctly
the issue of recursive calls does not exist, and you do NOT need to set
the AutoScrollSizeMin explicitly. Because the things affecting the
minimum size are controls, the Form automatically updates the scroll bars
to account for changes in the location of the child controls.
Also, note that in the new code, layout of the child controls always
begins at (0,0) rather than at the scroll position. The Form's own layout
code corrected for the erroneous use of the scroll position while laying
out the child controls, but I believe that in the long run no good could
have come from doing it that way.
There are other subtle differences between the code above and the code you
wrote, but I don't feel a need to enumerate each and every difference.
Suffice to say, where a difference exist, it's my opinion that my code is
better. :)
Also , when i click a box , its selected property turns true and it
highlights.But when one selects a box i want the last one to
deselect , so what would my best option be? Setting up an event so
everytime a box is clicked i can store it and then set Selected=false
when another is selected??
I see at least two options. One is to maintain a form-level variable that
keeps track of the current selection, so that when you select a new child
control, you can deselect the old selection. The other, and IMHO the most
appropriate method given that you are using Control-derived contents for
the form in the first place, is to take advantage of the fact that
controls already have a concept of having "focus", and automatically deal
with acquiring and losing focus.
Using the second method, you would simply allow the form itself to deal
with actually maintaining the focus state and then check the Focused
property to determine which font to use to draw the control. You'll need
to add handlers for the GotFocus and LostFocus events to invalidate the
control so that it will be updated, but otherwise everything else is
handled for you. You don't have to handle mouse-tracking, using the tab
key to change focus from one control to the next works automatically, and
of course you don't need the _selected field or Selected property doing it
that way.
Pete
