Re: [Gambas-user] A few questions

[Benoit M. <ga...@us...>]

On mercredi 24 septembre 2008, Doriano Blengino wrote:
> Benoit Minisini ha scritto:
> > On mardi 23 septembre 2008, Doriano Blengino wrote:
> >> Hi,
> >>
> >> I am facing a series of little problems (gambas v. 2.0.0).
> >
> > You should use a more recent version of Gambas, otherwise what I will say
> > may not work.
>
> 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!

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

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

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

At the moment, you could make things a bit cleaner like that:

* Make frmPreview raise a "GetPage" event.

* Add a Register method in your frmPreview that takes an Object as argument.

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

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

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!

> >> 5) Does TableView raise keypress events when in edit mode? I see
> >> nothing, but I would need it to do certain things. Is there another way
> >> to do a controlled editing in a tableview?
> >
> > TableView is made in Gambas, so you just have to look at the sources in
> > gb.form to understand how it works. It mainly inherits GridView and uses
> > Observers (and the Watcher class) to do its job.
> >
> > And, no, you won't see the keyboard events while editing, as they are
> > caught by the internal editor widget. In that specific case, we could
> > imagine adding a property to get a reference on the editor widget so that
> > you can put your own event observer on it to catch the keyboard events.
>
> In the meantime I realized that. But I didn't want to replicate all the
> code to position a textbox in the right place, set the focus on it,
> implement xxx_data() and friends. But I could reimplement TableView in
> my application, inherit all, and only add a property which contains the
> editor widget reference needed to catch its keypress event... could be...
>
> Many thanks. In my experiments I tried a code snippet like this:
>
>     DIM sName as string
>
>     sName = "test"
>     ...
>     hSomething = new SomethingElse(ME) as sName
>
>
> but the compiler complains about sName being an "unknown identifier". Is
> this the intended behaviour, ie the AS clause wants a literal, or
> something else?
>
> Regards,
> Doriano Blengino
>

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. 

I admit that the message error is not very accurate there, it should 
be "unknown class identifier".

Anyway, for doing special things, you can use Object.Attach()!

Regards,

-- 
Benoit Minisini