Tim, it seems that the width of a collapsed TPanel set programmatically
is not retained when the panel is expanded. It appears to revert back to
the size it was before it was collapsed. I haven't tested height.

I used the EWB2 supplied "panels" project, dropped another button on
form at the right side of the sizer and added the following to its
OnClick event:

procedure TMainForm.Button2Click(Sender: TObject);
var
   i: integer;
begin
   for i:=0 to ScrollPanel1.ControlCount-1 do
      TPanel(ScrollPanel1.Controls[i]).Width:=
              TPanel(ScrollPanel1.Controls[i]).Width+10;
end;

You can see the effect by clicking the first button to add the panels,
collapse one or more of the panels by clicking their minimize buttons
and then click the second button one or more times to resize all of the
panels.

The collapsed panels will appear to increase in width but when they are
expanded they revert back to their original width.

--
Rick

Rick,

<< Tim, it seems that the width of a collapsed TPanel set programmatically is not retained when the panel is expanded. It appears to revert back to the size it was before it was collapsed. I haven't tested height. >>

Yes, that's how the minimize capability is designed.  You can't modify the dimensions of a control while its minimized and expect them to stick because the control is not in its "normal" state.

Tim Young
Elevate Software
www.elevatesoft.com

On 24/10/15 05:19, Tim Young [Elevate Software] wrote:
> Yes, that's how the minimize capability is designed.  You can't modify the dimensions of a control while its minimized and expect them to stick because the control is not in its "normal" state.
>

Don't worry, I expect a lot of things

Programmatically increasing the width of the minimized panel causes its
caption bar to increase in width visually so when its restored it's a
weird moment of jumping back to the panel's original size. Feels like
it's lying to me.

I don't understand why we shouldn't expect the panel to reflect the
newly set width. This is not like minimizing a window to the task bar
but more of a collapsed control.

--
Rick

Rick,

<< I don't understand why we shouldn't expect the panel to reflect the newly set width. This is not like minimizing a window to the task bar but more of a collapsed control. >>

You're using *your* personal preferences and needs as a substitute for others, which isn't how I get to operate.  I have to take into account what someone *may* do, and minimization *can* include both a width and height modification, so *both* have to be restored.

Tim Young
Elevate Software
www.elevatesoft.com

On 27/10/15 05:34, Tim Young [Elevate Software] wrote:
> Rick,
>
> << I don't understand why we shouldn't expect the panel to reflect the newly set width. This is not like minimizing a window to the task bar but more of a collapsed control. >>
>
> You're using *your* personal preferences and needs as a substitute for others, which isn't how I get to operate.  I have to take into account what someone *may* do, and minimization *can* include both a width and height modification, so *both* have to be restored.
>

Tim, I guess I was just viewing the situation from a Delphi perspective
rather than my own. I understand that EWB has to deviate from Delphi in
various ways but just looking for consistency where possible.

In Delphi you can create a two TForm application with the main form
containing a button that when clicked changes the width of the second
form. If the second form is minimized then it appears as a title bar of
set width at the bottom of the desktop. Clicking the button on the main
form does not alter the appearance of the minimized second form however,
when the second form is restored then it is displayed with the new width
which is as a result of the programmatic change (by clicking the
button). In other words, it doesn't revert to the width it was before it
was minimized. Also, the minimized title bar doesn't change in
appearance like it does with a minimized EWB TPanel.

I know that EWB TPanels are not the same as Delphi TForms but just
thought it made sense for them to operate in a similar fashion
considering their common nature.

There also seem to be some unexpected differences between EWB TPanels
and TDialogs. For example, clicking on the client area of a TDialog will
bring it to the front whereas this does not happen with TPanels.

I also have not found a way to respond to clicks on caption bars.
Clicking a caption bar on a TPanel or TDialog brings it to the front but
does not bring focus to any client controls. I would like to capture the
click and then set focus to a contained control.

Not meaning to impose my preferences on you or anyone else (although I
don't deny wanting an easy life ).

--
Rick

On 10/26/2015 8:52 PM, Rick wrote:
> In Delphi you can create a two TForm application with the main form
> containing a button that when clicked changes the width of the second
> form. If the second form is minimized then it appears as a title bar of
> set width at the bottom of the desktop. Clicking the button on the main
> form does not alter the appearance of the minimized second form however,
> when the second form is restored then it is displayed with the new width
> which is as a result of the programmatic change (by clicking the
> button). In other words, it doesn't revert to the width it was before it
> was minimized. Also, the minimized title bar doesn't change in
> appearance like it does with a minimized EWB TPanel.

Little off topic but reminded of this :

http://blogs.msdn.com/b/oldnewthing/archive/2004/10/28/249044.aspx

Not sure if this is the case anymore but windows forms never really
minimized/maximized so resizing was easy (it just took place in the
coordinates far far away when done to a minimized window).


Raul

On 27/10/15 12:12, Raul wrote:
> Little off topic but reminded of this :
>
> http://blogs.msdn.com/b/oldnewthing/archive/2004/10/28/249044.aspx
>
> Not sure if this is the case anymore but windows forms never really
> minimized/maximized so resizing was easy (it just took place in the
> coordinates far far away when done to a minimized window).
>

Perhaps there are technical reasons why resizing a minimized EWB TPanel
is not possible (or at least very difficult) but if that's the case then
perhaps it would be best not to allow programmatic resizing of the
minimized caption bar. Maybe it should retain the same appearance even
if the width is altered in code.

I guess it's just a matter of understanding if a particular situation is
due to bugs or working as designed. That's the only reason why I queried
this in the first place. I'd rather not write lots of work-around code
if it can be fixed.

--
Rick

Rick wrote:

> Perhaps there are technical reasons why resizing a minimized EWB
> TPanel is not possible (or at least very difficult) but if that's the
> case then perhaps it would be best not to allow programmatic resizing
> of the minimized caption bar. Maybe it should retain the same
> appearance even if the width is altered in code.

Strikes me that it would be handy to have access to the "internal"
stored width that will be used to restore, as I can see how it might be
nice to have the panel animate to its required size when it is
restored. If the developer can test its minimized state, they can then
set the "restore size" specifically, without altering the current width.

--

Matthew Jones

Raul,

<< Little off topic but reminded of this : >>

Pretty close.

Tim Young
Elevate Software
www.elevatesoft.com

Rick,

<< Perhaps there are technical reasons why resizing a minimized EWB TPanel is not possible (or at least very difficult) but if that's the case then perhaps it would be best not to allow programmatic resizing of the minimized caption bar. Maybe it should retain the same appearance even if the width is altered in code. >>

Minimization is handled via control interface state changes, therefore EWB cannot make *any* assumptions about what is modified during minimization, other than the fact that it needs to restore the previous width/height.

Tim Young
Elevate Software
www.elevatesoft.com