[Gambas-user] Resize event...

[Doriano Blengino]

Stephen Bungay ha scritto:
>  > Now we come to your source. The "mFormInitialized" variable serves what
>  > purpose?
>
>    mFormInitialized is a hold over from something I used to do in VB, 
> and ocaisionally find useful in Gambas, so I just never removed it. Call 
> that a force of habit. It has proven useful allowing the Initialize 
> Controls subroutine to behave differently based on the value of the 
> boolean flag.
>   
Agreed.
>  > Then, where is the point to explicitly resize FormX and FormY in a
>  > manner so convolute? At the time the form is instanciated, it could be
>  > resized - so a single routine can be used to open as many forms are 
> needed.
>
>
>    Actually it is resized at the time it is instantiated. What were 
> doing here is making sure that the embedded forms that we want to resize 
> actually do resize.
>   
No, it is not so - and, your way could be more correct.
The children forms are first instanciated - stop. Then, when a 
Form_resize event arrives for the main form, the main form resizes the 
children forms.
So we are both wrong... :->>
Your way could be more correct, or mine... it depends on the logic of 
program and other things, like the order initial events are sended to forms.

>  > Next, who says that FormX wants to be resized to its
>  > "container.width-10" and "container.height-10"? When I say independence,
>
>
>    Um... not to put too fine a point on it but the one who says that a 
> form 'wants to be resized is the programmer, purely their judgement 
> call, and no one else's. The programmer is the one in control, if he/she 
>   doesn't want FormX to be resized then simply don't call the resize 
> method. If he/she wants to resize it to container.Width-50 them by all 
> means do so. It is up to them. Full stop.
>   
I wrote a sort of MDI application, where the MDI (children) forms are 
not walking in the main window but instead are put inside a tabstrip 
(the same as you). There are four or five different form types, and 
there can be multiple instances of the same form (with different data). 
At any given moment, the tabstrip can have 1 tab, 2, or 8 (there is a 
limit). So, in the resize event of the main form, I don't want to call 
each children form. I want that the embedded forms receive a resize 
event if, and only if, they are resized. If my main form is resized, but 
my tabstrip is not, then the children form should not be resized. If my 
main form has two tabstrips - one expanding and the other not, then 
things get more complicated. I don't want to be in control for 
everything, where should be mechanisms to do the work in place of me.

>  > I mean that FormMain has to embed another form, without knowing what
>  > that form will do with its geometry. If the explicit call to
>  > FormX.resize() has only the purpose to raise a resize event, well - I
>  > understand: when the resize event fires, the embedded form can do
>  > whatever it wants. But for me, the resize event was firing without any
>  > special processing.
>
>    Yes, the point is that the embedded form can do whatever it wants, 
> but it basis its' actions on what form main has done. Therefore the 
> embedded form can be loosely coupled to it's host, passing information 
> back and forth via properties and events.
>   
Passing information through properties and events? I had a lot of 
problems with it...
I think embedding a form inside a tabstrip makes sense if you have many 
of them, dynamic. If it is not so, then why not copy and paste controls 
from a tabstrip page to another, and voilà?
With dynamic forms, problem is when a form chooses to close. How to 
close the hosting tab?...

>  >
>  > All this seems messed, but I have a solution/request. How about an
>  > extended syntax to RAISE, which permit to send an event to a specified
>  > object? Like this:
>  >
>  >     RAISE resize TO mhFormX
>  >
>  > If the TO keyword is not specified, the event is sended, just like 
>  >now, to the parent object.
>
>   I can see where that would be useful for raising events that can not 
> be raised any other way. With the resize event we can raise it simply by 
> calling the resize method, so that is not a good example.
>   
There is a lot of difference, indeed. A raise event only tells to the 
destination form "you have been resized; please check". Calling its 
resize method simply resizes the form and does not tells "you have been 
resized". If you choose to resize the destination form, then you 
override its logic. If you send it an event, you use its logic. This is 
different...
More about this. If a form receives a resize event, and decides to 
resize itself, then a new resize event is fired, which causes the form 
to be resized, which unleash another resize event... stack overflow! So 
you can not resize a form inside its resize event handler... or what? I 
will investigate on this too.

>  > Anyway, this should be not needed in this case - I repeat - for me the
>  > embedded forms receive form_open and form_resize - still I am sure that
>  > there was something wrong, but can't remember what...
>  >
>  > This evening I will send my test project, if anybody can care.
>
>    I'd be interested in learning your results and, although I'm no guru, 
> perhaps I might see something you miss,... and of course it works the 
> other way around... you might see something I've missed. Certainly if 
> you had not replies to my initial email I might not have started talking 
> to Benoit and would still be flailing about. Community helps.
>   
Right. This evening, at home, I will send the project which shows that 
events fire correctly.

Regards,
Doriano