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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-user >
------------------------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user