[Gambas-user] Resize event...

[Stephen Bungay]

Look forward to it.

Doriano Blengino wrote:
> 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
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>