[Gambas-user] Resize event...

[Stephen Bungay]

 > 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.


 > 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.


 > 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 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.

 >
 > 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.

 > 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.


Doriano Blengino wrote:
> Stephen Bungay ha scritto:
>>    Well, after much consultation with Benoit I finally understand what 
>> is going on and how to get around the problem.
>>
>>    For the benefit of anyone else who has been reading this thread, 
>> Doraino and I were talking about instantiating a form inside a container 
>> on another form and resizing that embedded form when the parent is resized.
>>
>>    In a nutshell the solution is to reference the instantiated form by 
>> it's handle reference, created at the time of it being instantiated, and 
>> NOT by its' name.
>>
>> For example, consider an application that has three form classes, 
>> FormMain, FormX, and FormY. Form Main will contain a tabstrip and inside 
>> that tabstrip we want to instantiate FormX on tabstrip index 0 and FormY 
>> on tabstrip index 1. When we resize FormMain we want the embedded forms 
>> in their tabs to resize appropriately. Our FormMain Class logic might 
>> look like this;
>>
>> ' Gambas class file
>> Private mFormInitialized as Boolean
>> Private mhFormX As FormX
>> Private mhFormY AS FormY
>>
>> Public Sub Form_Open()
>>    InitializeControls
>> End
>>
>>
>> Private Sub InitializeControls()
>>    TabStrip1.Index = 0
>>    mhFormX = New FormX(TabStrip1)
>>
>>    TabStrip1.Index = 1
>>    mhFormY = New FormY(TabStrip1)
>>
>>    TabStrip1.Index = 0
>>
>>    mFormInitialized = True
>> End
>>
>>
>> Public Sub Form_Resize()
>>    With TabStrip1
>>         .Width = .Parent.width - 10
>>         .Height = .Parent.height - 20
>>         mhFormX.Resize(TabStrip1.Width - 10, Tabstrip1.Height - 10)
>>         mhFormY.Resize(TabStrip1.Width - 10, Tabstrip1.Height - 10)
>>    End With
>> End
>>
>>    The resize events in the forms referenced by mhFormX and mhFormY will 
>> now fire as expected, the embedded forms resize events will now fire as 
>> expected.
>>
>> Steve.
>>   
> Something strange is happening now.
> I remember something wrong when embedding forms in tabstrip, for sure, 
> and proof is you encounter the same problem. But yesterday I tried again 
> to embed, and I found nothing wrong - both resize and open event were 
> called in the embedded form (resize event was a little slower when 
> embedded, but who cares). I tried both QT and GTK.
> I never changed my version of Gambas, which is 2.0.0, so it is not a 
> version issue. The only wrong thing is that a
> 
>     mhFormY = New FormY(TabStrip1) as "evformy"
> 
> doesn't work, and an observer is needed.
> 
> Now we come to your source. The "mFormInitialized" variable serves what 
> purpose?
> 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.
> Next, who says that FormX wants to be resized to its 
> "container.width-10" and "container.height-10"? When I say independence, 
> 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.
> 
> 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.
> 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.
> 
> 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
>