[Gambas-user] A Gambas odissey

[Doriano Blengino]

Fabien Bodard ha scritto:
>> things missing in DirView, so I wrote my MyDirView the way I wanted. It
>> was easy at first, but then I discovered that it is difficult, or at
>> least not clear, how to move the "Current" cursor. I am not sure why,
>> but it does work by setting the Selected property of an item.
>>     
I derived MyDirView from TreeView, and wrote a ME_KeyPress event to 
manage arrow keys and textual search (i.e., you start to write the name 
of the directory you want to reach, and MyDirView select that 
directory). There is a SELECT statement that catches arrow keys.
The Left key, for example, should move the Current item to its parent 
(the parent directory). After using ME.MoveParent, I need a:

  ME.item.Selected = TRUE

because otherwise nothing happens. Later in the same routine I develop 
the textual search which, after finding the correct item using MoveFirst 
and several MoveBelow, simply returns. And it works! Without setting any 
Selected property.
While I am writing I realize that in the first case I STOP the event, 
while in the second one I do not. If I STOP in the second case, it does 
not work. So, the event handler of TreeView is doing something: if I 
stop it, I need to set the Selected property, if I do not stop it, it 
perhaps does something similar. Anyway the question is: how to move the 
Current item? I mean, the item the user sees as current?

>> other, the same event must be called with four different names. I took a
>> look at the FileView control to see what has been done in there. It
>> receives Click events, and raises Click events. What inside? It does not
>> inherit from ListView or similar. Now I understand why it works, but I
>> don't like it.
>>     
> it don't have to inherit it's a composed widget..; not an extention.
>   
What is an extension? I suppose a composed widget is one built from 
several other widgets. And so? If had to write a MyFileView, I would 
inherit from ColumnView, which already have many things I need. But, 
apparently, the Gambas mind is different from mine...
>>    1: inherit a new control which does, because you must rename all its
>> events
>>     
> what about observer ?
>   
I tried that; I didn't succed. May be I missed something, because I was 
facing an unexpected problem and tried several ways, in a crescendo of 
confusion and frustration. I think, indeed, that an Observer can catch 
events that are effectively raised. If an event does not rise, no 
Observers can catch it...
>>    2: use a menu voice to do it, because a menu voice has only one
>> shortcut; if you want use more keys, no way
>>     
> ???
>   
Think: if a control does not raise a KeyPress event, how can I catch 
keys? A menu catches shortcuts, which are keys. So you put a menu voice 
(a menu item) somewhere, and it will catch a single key (I wanted to 
catch the Tab, Enter and Return). Problem is a menu only catch one key, 
but I can use three different menu voices, perhaps hidden...

>> Finally, I must say that I think, and *repeat*, I think, the event
>> management is wrong or, at least, it is not as flexible as it could be.
>> Once a control raises event, you can not make it stop.
>>     
> not true ... it's STOP EVENT
>   
Yes, but where should you write your "STOP EVENT" statement? In a event 
handler...
By doing so, you don't really keep the control from raising events; 
instead you stop them to be processed, which is different. In a message 
some time ago Benoit told me that "events are a cost, so they should be 
used only in specialized controls and not for other purposes...".
This is the reason why "events are a cost". They keep to fire, even if 
nobody (no code) is interested in them. I have seen some gambas 
distribution source code; sometimes a boolean flag is used to 
temporarily prevent an event to rise:

  public sub TreeView_Expand()
    if $bDontRaise then return
    ' process...
  end

If TreeView had a OnExpand property, which tells what subroutine to 
invoke on expanding, instead of declaring a $bDontRaise and setting it 
to true one could write

    TreeView.OnExpand=NULL

>> Once you assign a handler to an
>> event, you can no more change it.
>>     
>
> wrong : Object.attach(Object, parentclass, "handler name")
>   
Right. I was forgetting this.
>> wants to "raise" the Click event. The OnClick property is a procedural
>> type, a thing that does not exist in Gambas.
>> true ... gambas is a true oriented object language
>>     
???
Does it mean that a "true object oriented language" should not have 
procedural types?
Delphi (or Kylix, or freepascal, or C++) are true object oriented 
language, and they have procedural types.

Well. Now I am going to see that code you courtly sent to me, and then I 
will reply.
Last question: what about focus management? How can I know what control 
has the input focus?

Thank you - have a nice day.