[Gambas-user] A Gambas odissey

[Doriano Blengino]

Benoit Minisini ha scritto:
>>   ME.MoveTo(path)
>>   DO
>>     IF ME.movechild() THEN BREAK
>>     ME.Item.Delete
>>     ME.MoveTo(path)
>>   LOOP
>>
>> You should elaborate, as these are clearly bugs: stepping the source should 
>> always have no side effects (effect for things that depends on time or window 
>> activation/deactivation).
>>     
I tried again the code and it works, even when stepping the source. 
Sorry for that - may be it was a GTK bug, or may be I did not recreate 
the same situation. If it happens again, I will elaborate.
>> The TabStrip refused to Delete()
>> because it was not empty; so in the event handler of the Button I set up
>> a timer which, in the next event loop, deletes the TabStrip.
>> The purpose of the timer is not to delay things, but to posticipate
>> them. It is a mean to send an event to itself.
>>     
> OK, but "you" are not sending event to "yourself". The event is sent by the 
> timer.
>   
I did not say that by using a timer I send an event to myself, I said 
this is a workaround for sending an event to myself.
And I talked about this situation in response to your statement "it is 
useless for an object to send events to itself".

>> Aaahhhh! Look at http://gambasdoc.org/help/comp/gb/application
>>     
> Application.ActiveControl is implemented in gb.qt, so you are not looking at 
> the right page.
>   
Toucheé. Sorry.

> A component can reimplement an already existing class by adding methods, 
> properties... This is like inheritance, but by keeping the same name.
>   
Again, sorry. May be, then, that gambas lacks classic inheritance? :-)
>> I learned that, with Object.lock(), you can stop a control to send
>> events. I did not know. Problem is, you disable *all* its events.
>> With Object.Attach() you can change the event names of a control (all
>> the events), not a single event handler.
>> A group of controls can share events - yes: all the events or none of them.
>> You see, and please take this with friendship, this is not what I call
>> "flexible".
>>     
> It is less flexible than the Delphi way, but I yet think it is enough.
>   
May be, may be. Clearly, if I am used to do certain things, soon or 
later I find they are missing, if they lack.
I take this occasion to say that I messed up things when talking about 
events, and the impossibility to derive a control from another and 
simply add what it is missing. These things in gambas work - I just made 
them in my MyDirView...

>>   $bNoEvent = TRUE
>>   $hTreeView.Clear
>>   ...
>>   TreeView_Expand
>>   $bNoEvent = FALSE
>>
>> In delphi, the same thing would have reduced to set/reset the
>> TreeView.OnSelect property, i.e., exactly the only thing we wanted.
>>     
> OK. But implementing events the same way as Delphi has a cost that is higher 
> than the management of these specific case that are not very common.
>   
Perhaps this is specular to what said before. You find that this 
situation is not very common, because you don't "search" for it, while I do.
About the cost... who can say? I don't see why Delphi should have a 
higher cost, and you don't see why Gambas should have the higher one. A 
final trial is impossible, I think; but I also think this is of scarce 
importance.

> I didn't say that Delphi is not object-oriented. I just said that the concept 
> of event observer is more object-oriented. :-)
>   
I cannot catch the point. Because you use C++, and I do not, you know 
C++ better than me. Can you briefly explain to me how are events managed 
in C++? Very briefly?
>> because the global variables LAST, Key, Mouse are undefined.
>> This also means that you don't need to raise events - you can invoke
>> directly the event handler, if you want. 
>>     
> This is true for these special events that use static values only. Otherwise 
> event handlers are public methods like any other public methods, and you can 
> call them from anywhere.
>   
I will try now to explain how a true event management could be 
implemented. As far as I know, no "normal" language implements them in 
this way, but someone could citate Erlang, or Python, or other less 
procedural languages. I could be wrong, may be there exists a true 
imperative language that does. I don't know.
Let's start with an event handler. If the event handler receives all the 
parameters it needs, it is perfect, because it does not depend on 
anything outside its scope. Now, how to pass parameters to an event 
handler? It is easy to call it directly, like Delphi does. It is simply 
matter of PUSHing all the values to the stack, and then CALL a 
subroutine. But also, it is not a true event, because true events have 
to be queueable. So, if we want to "post" an event, we must construct a 
record (a struct), containing all the parameters the handler expects, 
and append that stuff somewhere. At some time later, these data are 
pushed onto the stack and the handler is called.
This is what windows does with its messages, but those messages have all 
the same image - it is up to the handler to decode them and access 
correctly the single values. This is awful - a true high level language 
should not permit this. And, in fact, Delphi does not permit this. It 
hides this awful thing behind pascal syntax. But, with this syntax, you 
can not enqueue an event. And, as far as I know, nor gambas can.

>> There
>> is also an Idle event, which is missing in gambas (apropos: how about to
>> implement it?). This event is raised when the application is idle -
>> useful for background processing.
>>     
> GTK+ has that, but not QT, so I don't think I can do that.
>   
Perhaps this event could be generated by gambas itself, at the end of 
the event loop, if it was an "empty" loop (i.e., there were no events, 
no timers to fire, no repaints...). Note that this Idle event is in some 
respect in contrast to an event-driven application... especially if the 
application uses threads. I mean - you need background processing? Then 
use a thread... but threads are complicated (and, yes, Delphi has true 
threads, just in case you wonder. And, yes, they are object - again, 
just in case... :-)).
>> Delphi is a true object/class language. Gambas is not. How about method
>> overriding, virtual methods, protected methods, default properties,
>> published properties, and the list could continue... but probably this
>> things are unknown for a visual basic programmer (fortunately you know
>> also C++. How events work in C++?).
>>     
> Maybe you should *really* read the documentation pages I told you. Especially 
> this one: http://gambasdoc.org/help/doc/object-model
>   
Well, I went there again. My compliments for the great simplicity used 
to implement such a complicated matter. This is one of the things for 
which gambas can be appreciated. But the documentation is simplified 
too: no mention of the SUPER keyword (I did a textual search). I found 
its description using the google search function inside the page.

> I admit that Keyboard and Mouse events accessing global structures is not very 
> beautiful. I did that because it was simpler for the programmer, and because 
> I never meet the need for explicitely calling a mouse or keyboard event 
> handler, unless for doing bad things. :-)
>   
Uhm... bad things... may be...
In regard to "simpler for the programmer"... again... may be...

Best salutations to everybody.