[Gambas-user] A few questions

Doriano Blengino doriano.blengino at ...1909...
Wed Sep 24 20:30:18 CEST 2008


Benoit Minisini ha scritto:
> On mercredi 24 septembre 2008, Doriano Blengino wrote:
>   
>> Yes, this is true. But I installed the v2.7.xxx (debian repository) on
>> another machine to see if it had many improvements and, as far I could
>> see from a quick tour, there was nothing exiciting. I have to say that
>> my 2.0.0 is very stable... and I am happy with this unless I found a
>> bug. I prefer stability over everything else... ;-
> Don't trust only what you see. Look in the ChangeLog too!
>   
I will do it (this is the same thing I continuosly say to my wife...)

>> Sorry... I was talking about *not* to use an observer. I tried to
>> "object.attach()" fmPreview, and the result was that
>> fmPreview.form_open() didn't execute anymore. I understand this was
>> because I deviated, by mean of attach(), the events from fmPreview to
>> another place. But I was thinking that events directed *to* fmPreview
>> (such form_keypress, form_open and so on) took a different path than
>> those generated *from* fmPreview.
>>     
> Alas no!
>   
Does "Alas no!" mean "it is not so", or "instead it is not so"? I 
suppose yes.

>>>> 3) I tried to instantiate an observer directly from fmPreview, instead
>>>> of the main program, and then object.attach() it to the main program,
>>>> but it didn't work.
>>>>         
>>> You cannot "Object.Attach() to the main program". A default observer
>>> (badly named Parent in Gambas) is not a program, but another object.
>>>
>>> In the case of a static class (a module), the observer is the class
>>> object.
>>>       
>> Yes, but... the instruction object.attach() was written inside the code
>> of a form, so it was belonging to a class.
>>     
>
> The Object.Attach() method does not depend on its context, contrary to the NEW 
> instruction.
>   
I can not catch the point. It seems to me that I can use object.attach() 
everywhere, because in its parameters:

	STATIC SUB *Attach* ( _Object_ AS Object, _Parent_ AS Object, _Name_ AS String )

...I specify the object to steal events from (Object), to which 
listener/observer send those events to (Parent), and the name the 
handlers begin with. But I suppose that if Name is "test", the compiler 
looks for "test_xxx()" methods in the class currently being compiled (or 
currently being running), otherwise what the heck could it do? So I 
deduce object.attach() depends on its context, in the sense "it depends 
in which class the instruction attach() is compiled".
Forget the saying "main program"... it was an unhappy way to mean "the 
rest of the program"...

>> My application is encapsulated pretty well, and it works smoothly.
>> It is encapsulated well because fmPreview does a lot of things, and the
>> only callback is the getpage event.
>> On the other side, the main program (ie, the form which needs to print)
>> only setups() fmPreview to pass the template name of the print, and
>> through "reply = fmPreview.ShowModal()" knows if the user aborted,
>> printed none, some, or all the pages. I cannot see a simpler way to do
>> this, but if someone knows, ...welcome!
>>     
>
> When I will rework the Gambas printer system, I will make a Printer control 
> that will emit events each time it needs a page to be drawn. This way, 
> everything will be done "in background", and the UI won't be necessary 
> blocked during the process.
>   
I did exactly so. The application is not blocked but, because of the 
ShowModal(), the main program (eh eh eh...) cannot continue. This is by 
design, because of legal concerns.
> At the moment, you could make things a bit cleaner like that:
>
> * Make frmPreview raise a "GetPage" event.
>   
Already done this way.
> * Add a Register method in your frmPreview that takes an Object as argument.
>   
That was exactly what I wanted to do...
> * In that Register method, creates an observer on the form (ME) and attach it 
> to the form (ME) to the argument. This way, the argument will receive the 
> GetPage event (and other form events if it wants, but don't tell him).
>   
So I should write:

    obs = new observer(me) AS parameter_of_sub

This is a little inconsistent with the syntax '...as "whatever"'. I will 
see if it works.

> * You can create a Unregister method too.
>
> This is the same method as you did, but it is cleaner to write as you just 
> have to Register/Unregister outside of frmPreview.
>   
I would do this thing inside fmPreview.Close(), just as now. If it 
works, this is what I wanted - call all the printing with a single 
instruction.
> If you want to use the preview from a module named Module1, the following 
> should work:
>
> frmPreview.Register(Module1).
>
> Then the register method should receive the Module1 class object, which can be 
> used as any other object for registering.
>
> Tell me if it works!
>   
Yes, I will do.

> The Gambas parser is guilty: as soon as it gets an "AS" keyword, it 
> expects a
> class identifier after. The compiler then complains shortly later, whereas 
> theoritically that syntax could compile without problem.
>   
Same as before - does the "var = new .... AS xxxx" expect xxxx to be a 
literal string, any string expression, or a class name? Anyway I will 
inspect.

Many thanks for the moment, I will send news to you.

Best regards,
Doriano Blengino





More information about the User mailing list