[Gambas-user] Super Events. Are they posible?

[Jorge Carrión]

I don't mind at all to be mentioned, Tobi (Vanitas, vanitatis...hehehe)

What I've done 'till the moment is a sqlite3 database with the help
contents (don't want Remote Server Access for this) in .config/gambas3/
wich is installed in first execution of application.
After that I joined each control that need help in a group called "Help"
and the event help_keyrelease call the Help Form sending the form's and
control's name.
With this information the form control shows in a sepparate window the
adecuate help or raise a globe with it.
It works fine, BUT... I can't group all this controls in another group,
what is something I need sometimes... or I have to code all keyrelease
events for every control separate, what is tedious an slow to code...

That last option is the second most boring thing in a development... after
writes the help itself, naturally :-D

Regards





2014-02-13 2:46 GMT+01:00 Tobias Boege <taboege at ...626...>:

> On Wed, 12 Feb 2014, Jorge Carri?n wrote:
> > Oh, Fabien... I don't understand.
> > At the begining of the fMain class in a simple proyect with a textbox in
> > the fMain form. and a second form, Helpform, that  just contains a label.
> > I've declared this
> >
> > Static Public Sub Application_Read()
> >
> >     Dim f As Helpform
> >
> >     If key.code = Key.F1 Then
> >         f = New Helpform
> >         f.showmodal
> >     Endif
> >
> > End
> >
> > But the Application_Read sub never is called....
> > I don't understand.
> > The doc on gambasdoc is not very clear. it's suppoused Application_Read
> > catch the Standard Input... ?From the Shell? ?From the keyboard? I don't
> > understand...
> > Is ask too much ask for a little example?
> > Thanks in advance.
> >
>
> Application_Read() watches stdin which is not what you need.
>
> Actually, I don't think there is a good solution. Objects are bound to a
> single "default" or "main" observer (occasionally called its "parent" but
> this is misleading when we talk about control containers which are also
> called "parents" but aren't necessarily main observers) which intercepts
> events of the observed objects. Normally (when you use the form editor)
> controls are bound to the form they are put on. That's why you can write
> something like Public Sub btnClose_Click() in your form's class file for a
> Button btnClose on the form.
>
> In addition to the main observer, you can create other Observer objects
> (Observer is a class in the gb component) which are... additional observers
> and duplicate events raised by the observed object. Or you can attach an
> object to another main observer at runtime using Object.Attach().
>
> However, if you use the latter method, the event handlers you wrote in your
> form code will not work anymore. So we will have to use the Observer stuff
> which lets us catch event duplicates behind the scenes.
>
> This technique requires to create an observer for *each* control that you
> want to incorporate into your help system... or (!) we can create only
> *one*
> observer per Form instance and use some really black magic called the
> Grab()
> method whose existence is very fortunate here...
>
> Let's consider the second, obviously more efficient, approach. This would
> require to add an observer for each of your forms. To automate this task,
> we
> need a way to hook the creation of forms without imposing the need to
> change
> any existing code (which should be our ultimate goal). This is normally
> done
> by overriding a class in the global symbol table. Then we can "hook" the
> _new() special method and register the newly created form with our help
> system which will create an observer and watch the window.
>
> In the attached POC code, I have deliberately used a Control's Tag property
> to store the help text. It's up to you to make it better. Then, in the new
> Form class, a new observer for the form is created with the form itself. If
> the user presses F1, the form goes into "help mode" which means that the
> form will grab any user input (from mouse and keyboard) of its controls so
> that, e.g., Buttons don't raise Click events anymore but instead the form
> raises a MouseUp event. Help mode is indicated visually by the mouse being
> set to Mouse.Pointing. Then we can display the help on the form observer's
> MouseUp event handler.
>
> I hope the project helps. At least it satisfies me because as you will see,
> you don't need to change any existing code, but only override the Form
> class.
>
> And in case you're still curious: the first approach (creating observers
> for
> every control) would *not* work the same way (if at all) because you cannot
> override the Control class. This yielded an error I have never seen before
> about the inability to override a class which is already inherited or the
> like. Likely, my POC code will not work in your project if you have any
> classes derived from Form.
>
> Thanks for that interesting question ;-) We'll definitely write an article
> about this topic on gambas-buch.de. Do you mind if I mention your name?
>
> Regards,
> Tobi
>
> --
> "There's an old saying: Don't change anything... ever!" -- Mr. Monk
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>
>