Eventi intercettabili in un'unica procedura evento della Form di appartenenza

[Picavbg]

L'oggetto di questa discussione può non apparire sufficientemente chiaro, ma vorrei gestire qualcosa del genere:
Il Click del mouse su un oggetto qualsiasi, all'interno di una Form (TextBox, ComboBox, Button, Panel, Frame,...) scatena l'evento MouseDown al momento della pressione di un pulsante del mouse. Allora, per intercettare Il click sul mouse su qualsiasi oggetto interno alla Form, piuttosto che scrivere una procedura Evento_MouseDown per ciascun oggetto della Form, verrebbe assai più comodo gestire l'evento dentro un'unica procedura Formx_MouseDown. Ho provato a scriverla, ma l'effetto ottenuto è che la procedura viene avviata solamente quando il mouse agisce su un punto vuoto della Form, se invece il click avviene su una "Label" la procedura Formx_MouseDown non viene assolutamente scedulata.
Per dirla molto brevemente: non funziona come l'evento KeyPress.
Ho cercato allora una qualche indicazione nella documentazione ufficiale di Gambas, ma non ho saputo trovare niente di facilmente gestibile, l'unica strada praticabile potrebbe essere quella di scrivere una procedura evento per ciascun oggetto della Form, compresa la Form stessa e richiamare poi una procedura Sub o Function contenente il codice occorrente, cioè:

Codice: gambas [Seleziona]

Public Sub TextBox1_MouseDown()
 MioEvento_MopuseDown
End

Public Sub Label1_MouseDown()
 MioEvento_MopuseDown
End

Public Sub Form1_MouseDown()
 MioEvento_MopuseDown
End

Private Sub MioEvento_MopuseDown()
  Message.Info("Hai fatto Click col mouse")
End

Sarebbe bello poter dire a Gambas a livello generale, magari all'interno della procedura _new della Form stessa, al Click sul mouse esegui la Form_MouseDown. 
 

[vuott]

Ho provato il tuo codice, e a me accade questo: se clicco all'interno della TextBox o della Label, viene sollevato l'evento, e m'appare il messaggio. Se clicco all'interno della pura Form, non accade niente. Ho provato a cambiare nome in "FMain" e "Form", ma ugualmente non succede niente.
Poi ho inserito nella routine del Form un semplice Print con un testo da mostrare in console, ma ugualmente cliccando sul form non succedeva niente. Eppure l'evento _MouseDown() è previsto anche per il Form ! Non capisco.  

Ad ogni modo, mi domando se non sia più semplice raggruppare tutti gli oggetti interessati in un unico Gruppo e quindi far scatenare l'evento se si clicca su un oggetto appartenente a quel Gruppo.... il vantaggio della tua soluzione quale è ?

[md9327]

In gambas, gli eventi sono associati ad un singolo gestore, che può essere identificato dal nome dell'oggetto stesso, seguito dal tipo di evento, oppure dal nome del GROUP.
Tramite GROUP è possibile unificare gli eventi in un singolo gestore generale, relativo allo stesso oggetto parent di tutto (es. una Form).
Non è però possibile unificare anche il tipo di evento, come invece succede con altri linguaggi. Per cui l'evento Click(), ad esempio, può essere gestito da un solo metodo Click(), e non può venir mischiato con un evento DblClick(). Quindi, a prescindere da chi scatena l'evento, il metodo è sempre quello, ed è gestito internamente a gambas, per cui non è possibile modificarne la logica.

Codice: [Seleziona]

PUBLIC <gruppo>_<evento>()
END

Se più oggetti vengono associati allo stesso gruppo, lo stesso evento verrà gestito dallo stesso metodo. E' ovvio che poi all'interno del metodo si dovrà capire chi ha scatenato l'evento (se necessario), e in quesot caso viene a cecio la keywork LAST che, appunto, ritorna l'oggetto che ha scatenato l'evento.

[vuott]

Non è però possibile unificare anche il tipo di evento, come invece succede con altri linguaggi. Per cui l'evento Click(), ad esempio, può essere gestito da un solo metodo Click(), e non può venir mischiato con un evento DblClick(). Quindi, a prescindere da chi scatena l'evento, il metodo è sempre quello, ed è gestito internamente a gambas, per cui non è possibile modificarne la logica.

Codice: [Seleziona]

PUBLIC <gruppo>_<evento>()
END

Se più oggetti vengono associati allo stesso gruppo, lo stesso evento verrà gestito dallo stesso metodo.

Sì, bene, però mi domando ancora se la leva proposta dal nostro amico Picavbg sia più vantaggiosa.  

[md9327]

Non capisco cosa intendi vuott...

Quello che vuol fare picavbg è di scatenare un'evento al posto di un'altro, almeno così ho capito...

A parte che non ne capisco il motivo, soprattutto per il fatto che se premo un pulsante mi pare logico scatenare un click, perchè è questo che stò facendo.

Se ho potuto leggere bene tra le righe, il nostro amico vorrebbe gestire in un unico metodo tutti gli eventi scatenati da qualsiasi oggetto all'interno della stessa classe. Questo, come ho scritto, con gambas non è possibile.

Il fatto poi che non funziona l'esempio è un'altro paio di maniche. Bisogna vedere (e putroppo non ho letto l'esempio) se per caso l'area della form non sia occupata da qualche altro elemento (es. una VBox). In questo caso gli eventi li cattura quest'ultimo oggetto.

Se, come ho scritto, si unificano gli eventi in un'unico gruppo, comune a tutti gli oggetti presenti nella classe, e anche la stessa classe, allora è possibile intercettarli con un unico metodo, ovviamente per singolo tipo di evento.

[milio]

Io proporrei una classe di questo genere

Codice: gambas [Seleziona]

Event MouseDown(Obj As Object)

Private hObs As Observer[]

Public Sub _new(Parent As Window)
Dim Obs As Observer
Dim Ctrl As Control

  hObs = New Observer[]

  For Each Ctrl In Parent.Controls
    Obs = New Observer(Ctrl) As "Event"
    hObs.Add(Obs)
  Next

End

Public Sub Event_MouseDown()
  
  Raise MouseDown(Last)
  
End

In questo modo tutti gli oggetti del form che hanno un evento MouseDown vengono intercettati e inviati ad un unico evento generato dalla classe, lasciando comunque la possibilità di gestire separatamente gli eventi dei singoli oggetti del form.

Poi magari ho detto na strunz....... ata! 

[md9327]

E' sicuramente fattibile, il problema è la generazione anomala degli eventi. Tieni anche conto che alcuni eventi hanno dei parametri, e non è detto che tu riesca a simularli.

L'uso di observer, nel caso di oggetti già definiti nell'editor grafico di gambas, è sicuramente la via più indicata. Nella creazione degli oggetti basta aggiungere la stessa cosa, ovvero il nome "Event" come nell'esempio di milio, e i metodi dovranno seguire la stessa logica. Dato che è possibile definire lo stesso nome a più oggetti, il che è lo stesso effetto di GROUP nelle proprietà degli oggetti, si avrà come conseguenza un concentramento degli eventi generati dagli oggetti dello stesso gruppo, quindi gestibili da un evento unico.
Questo l'ho scritto nel post precedente, e come ho scritto non è però possibile unificare tutti i tipi di evento in un gestore eventi unico, ovvero non puoi gestire il doppio-click con lo stesso evento del click, o dell'open, o quant'altro.
Io spero di essere stato chiaro...
In altri linguaggi, come il C++ per esempio, è possibile, e di solito viene usata, usare una logica di gestione eventi con un unica funzione (o metodo), che cattura di tutto. E' sottinteso che poi all'interno della funzione, si debbano prendere le dovute precauzione per gestire in modo separato il codice abbinato alla singola operazione, che è poi legata al tipo di evento.

Diciamo che se clicco una volta un bottone, è sicuramente diverso al cliccarci due volte. Oppure anche, premere un tasto è sicuramente diverso dal rilasciarlo. Espandere una form è sicuramente diverso dal ridimensionarla o dal click del mouse nell'area della form stessa. Insomma, la differenza c'è e ci deve essere, ed è sicuramente il caso di capire bene se la strada di unire tutti gli eventi sia la strada giusta.
Se io volessi intercettare qualsiasi cosa faccia il mouse sopra un oggetto, bè, prima spiegamoci il motivo di ciò...
Mettiamo il caso di avere una dialog, che vogliamo chiudere allo scatenarsi di un qualsiasi evento... bè, forse qui potrebbe essere utile, ma perchè fare davvero una cosa così? Da pensare...

Diciamo che tutto si può fare, ma credo ci debba essere un motivo più che valido per costruire una cosa del genere, anche con Gambas, e non per cercare di risolvere una nostra lacuna circa il linguaggio, o per ovviare ad una logica errata.

Comunque, a parte tutta questa disquisizione, forse credo sia il caso che picavbg ci dia un'idea di quello che vuole fare, forse potrebbe esserci un'alytra strada più semplice, questa la vedo alquanto laboriosa e poco manutenibile...

[Picavbg]

Ciao a tutti. Siccome io non sono Gambas, posso gestire l'evento Risposta in un unico post. 
Non ho provato l'esempio di Milio, perchè dovrò prima ragionarci un pò sopra, comunque ho capito per sommi capi a cosa tende, infatti prima di aprire la discussione ho letto un pò di documentazione e credo che potrebbe fare al caso mio anche "Object.Attach", ma anche codesto occorre che sia studiato opportunamente. La possibilità di avere un gestore di eventi dentro la classe, diciamo, superiore, come  la Form è un'idea che mi è nata dall'uso del metodo KeyPress che, se inserito come evento proprio della Form è in grado di catturare l'evento ancor prima di un qualsiasi singolo oggetto della Form, come una TextBox o un Button o altro. É un meccanismo sfruttato nella logica di Gambas e funziona perfettamente; lo uso con soddisfazione nel mio programma. Analogamente potrebbe esserci un dispositivo, logico simile anche per catturare e gestire la pressione del tasto del mouse. Mi pare infatti strano che Gambas riesca a gestire l'evento KeyPress, dando priorità alla procedura Form_KeyPress, rispetto a quella dell'oggetto TextBox_KeyPress, interno alla stessa Form e non riesca a farlo per l'evento MouseDown
Stabilito il punto di partenza del mio ragionamento sul metodo gestione evento MouseDown, vengo ora a spiegare da che cosa nasce la necessità di un simile utilizzo:
Dopo avere installato la prima volta G3 (in Sabayon), circa tre mesi fa, ho scoperto che una ComboBox dichiarata "NON ReadOnly", non viene più gestita alla vecchia maniera, cioè le righe componenti la ComboBox.List risultano disordinate, nonostante abbia attivato la proprieta Sorted=TRUE; inoltre, pur avendo digitato nella CombBox.Text un parte della stringa da rintracciare nella ComboBox.List, al comando Popup, la lista, nella finestra di Popup relativa, comincia sempre dalla prima riga della lista e non da quella successiva e più prossima alla stringa digitata. Per ovviare a tali anomalie, a mio modo di vedere, ho sostituito la ComboBox incriminata con un insieme di oggetti collocati dentro un contenitore Panel. Essi sono:
--> una TextBox per la digitazione di una nuova stringa o della stringa da ricercare;
--> un ToggleButton per simulare il pulsantino posto a destra della  CombBox.Text;
--> una ListBox per simulare la finestra di Popup della ComboBox dove posso gestire il mio array di stringhe in ordine alfabetico crescente.
É logico a questo punto che dopo avere acceso la ListBox, tramite le note propietà ListBox.enabled e  ListBox.visible, sorge il problema di chiuderla. La sua chiusura può avvenire dopo la selezione di un'eventuale riga della lista e la successiva pressione deltasto "INVIO" o del successivo click sul mouse, ma anche dopo avere cliccato su un punto vuoto della Form o avere spostato il focus su un'oggetto della Form qualsiasi, come la stessa TextBox a cui ho logicamente agganciato la ListBox in questione. Ho scartato l'uso della proprietà GROUP, perchè dovrei associarvi tutti gli oggetti della Form e ciò, penso, mi renderebbe poi più difficile la gestione dei singoli oggetti; infatti, a parte la necessità di poter rintracciare l'evento MouseDown, per tutto il resto non hanno altro in comune fra loro.
Non potendo sfruttare una gestione nativa in Gambas, per quello che mi avete ampiamente sottolineato nei vostri precedenti post, dovrò applicare un metodo "manuale e personale", come quello che mi ha suggerito Milio. 
Vi farò sapere. Per ora una sola cosa è certa: sono riuscito a tenervi un pò tutti impegnati con me
 

[md9327]

Spero che il mio post precedente non ti abbia offeso, non era nei miei intenti, anzi... 

Comunque, già da quest'ultimo tuo post, capisco un pò meglio quello che intendevi inizialmente.
Devo comunque comunicarti che c'è una piccola lacunetta nei tuoi studi, ovvero:

1) gli eventi vengono attivati sull'oggetto attivo
2) se è presente un gestore di evento nella form, questo non cattura lo stesso evento scatenato da un suo oggetto figlio, a meno che, appunto, tu non l'abbia associato allo stesso gruppo
3) l'uso di group è sicuramente utile nel caso che, per evento uguale, il codice di esecuzione sia lo stesso o similare (con piccole differenze), altrimenti è sicuramente più pulito e gestibile gestire il tutto così com'è di default, ovvero: un oggetto -> un evento -> un metodo.
4) ci sono piccole differenze tra i metodi di associazione degli eventi, ovvero:
    a) attach/detach: a volte se usato in più punti per lo stesso oggetto, potrebbe dimenticarsi di scatenare eventi sui parent associati; è comunque il metodo più usato per associare gli eventi di un oggetto in più punti dell'applicazione;
    b) definizione in fase di creazione: questo sistema è perfetto per l'utilizzo all'interno di una classe, per tutti gli oggetti creati dinamicamente al suo interno;
    c) definizione a livello di editor grafico: questo è il metodo di default di gambas, dove per ogni oggetto viene agganciato un suo gruppo privato, che corrisponde al nome dell'oggetto stesso;
    d) associazione per gruppo: come detto, questa è un opzione supplementare ai punti sopra, e può essere utile in determinati casi.

Parlando di applicazioni grafiche, ogni oggetto a video ha una sua profondità. Se partiamo da una Form, il passaggio del mouse viene intercettato solo se questo passa sopra la Form, altrimenti tutto viene catturato dal Desktop. Se la Form ha un pannello al suo interno, il passaggio del mouse viene catturato dal pannello, e non dalla form, se il mouse ci passa sopra, e questo perchè il pannello è su un layer superiore, ovvero più a fronte rispetto i tuoi occhi...
Questo è il comportamento normale di DM (desktop manager) e di tutte le applicazioni che funzionano utilizzando la sua logica. E' ovvio che puoi modificarlo (tutto si può in informatica), ma seguendo certe regole, e faticando non poco. Come suggerito da milio, è possibile scatenare a prescindere tutti gli eventi che vuoi, anche in concomitanza, o in successione, allo scatenzarsi di un'altro evento. Il problema è che poi vai ad impattare nella logica di base del DM, e non è detto che il comportamento poi sia quello aspettato, o che non ci siano conseguenze inattese.

Quello che in effetti volevo anche dire nel post precedente, è che se per caso gambas3 ci fossero dei buchi, che ne condizionassero il comportamento, in particolare su alcuni oggetti, o su alcuni eventi, in modo inaspettato, non penso sia il caso di metterci una toppa, studiandoci sopra architetture arzigogolate e senza controllo, e poi magari toglierle perchè i bugs vengono risolti. Io penso che un comportyamento anomalo debba essere segnalato agli sviluppatori, cercando di risolverlo a livello di linguaggio, altrimenti qui usciamo tutti fuori di matto...

[Picavbg]

Spero che il mio post precedente non ti abbia offeso, non era nei miei intenti, anzi... 

Mi dispiace averti fatto intendere che io mi sia offeso. Non è assolutamente così. Come posso offendermi nei confronti di chi, chiunque egli sia, sta cercando di darmi una mano a capiere ed a risolvere. Ti sono e vi sono grato.

Io penso che un comportyamento anomalo debba essere segnalato agli sviluppatori, cercando di risolverlo a livello di linguaggio, altrimenti qui usciamo tutti fuori di matto...

Personalmente non so se quanto da me indicato per le ComboBox e relative finestre di Popup possa essere considerata un'anomalia. A me non sta bene, ma se a lamentarsi per il disagio sono solamente io allora può essere un mio problema che cercherò di affrontare e risolvere con gli strumenti messi a disposizione da Gambas e limitatamente alle mie conoscenze.
Ritornando all'impossibilità di gestire l'evento MouseDown nella classe Form, genitrice di tutti gli oggetti in essa contenuti, ho deciso di lasciare a Gambas quel che è di Gambas, per cui, piuttosto che attivare forzature di cui non posso prevedere le conseguenze, intercetterò l'evento MouseDown in ciascun oggetto della Form e l'eventuale pseudo-finestra di Popup attiva sarà chiusa attraverso il richiamo di un'unica sottoprocedura di tipo SUB, come nell'esempio riportato nel mio post d'apertura. 
Grazie a tutti. 

[md9327]

Perdona picavbg, a volte mi accorgo di essere un pò brusco, e quando me ne accorgo spero di non aver toccato nell'animo il mio interlocutore... (chiudo qui la cosa, visto che è tutto a posto).

Riguardo agli eventi, e su quanto si è discusso qui, credo ci siamo un pò persi tra tutti i discorsi.

Ritornando al dunque, tu hai riscontrato un problema con uno specifico evento, appunto MouseDown().
Presupponendo che la Form di cui fai esempio, non abbia un suo oggetto grafico interno, che occupa tutta l'area utile della form, allora è presumibile un bug.
Come ho scritto sopra, gli oggetti vengono posti e gestiti in maniera pseudo-tridimensionale come su una piramide. Quindi, mettiamo il caso di avere una sola form aperta sul desktop, tutti gli eventi che qualsiasi device grafico possa scatenare (vedi mouse, tastiera e quant'altro) vengono catturati dal DM (mettiamo il caso sia Gnome) e dirottati all'oggetto che ha in quel momento il fuoco, ovvero sia l'oggetto attivo. In questo esempio, l'unico oggetto che può essere attivo, e in cima alla piramide, è la nostra form. Gli eventi scatenati dal mouse, ad esempio, vengono direzionati verso questa form ma, attenzione, questo solo del puntatore del mouse si trova proprio perpendicolare alla zona occupata dalla form.
Ok, a questo punto la form dovrebbe catturare l'evento ed agire di conseguenza ma, attenzione, la form ha un bel pulsante che, guarda caso, occupa un posto più in alto nella piramide degli oggetti (altrimenti non sarebbe visibile, ma nascosta dalla form). Ora bisogna stabilire se il puntatore del mouse si trova sopra la form, ok, ma anche sopra al bottone? Sì? Bè, allora l'evento lo prende il bottone, e non la form, e quindi l'evento lo tratterà il gestore del pulsante (anche se in questo caso il pulsante è incluso nella stessa classe della form...).
Ok, allora tu dici: e ora che faccio? Io voglio che qualsiasi click, all'interno della form, mi faccia la stessa operazione, magari chiudere la form stessa (un esempio è quello della classica finestra di About). Ok, qui interviene il discorso GROUP.
Associando la form e il bottone allo stesso gruppo, non si fà altro che definire un gestore comune che catturferà tutti gli eventi dello stesso tipo ma, attenzione, come ho scritto in precedenza, questo può essere fatto solo per UN SOLO tipo di evento, ovvero se vogliamo gestire nello stesso metodo due o più tipi di evento, questo non è fattibile, a meno di non creare una logica alquanto articolata.
Per riassumere, assumendo che a tutti gli oggetti gli venga associato un gruppo "Event", noi avremo una serie di funzioni di cattura che saranno:
Event_Click()
Event_DblClick()
Event_Open()
Event_MouseDown()
Event_MouseUp()
ecc... per tutti i tipi di evento generati dall'insieme degli oggetti del gruppo. E' quindi da notare che le funzioni di cattura sono comunque differenziate, ma ad ogni modo ognuna catturerà lo stesso tipo di evento, sia che venga generato dalla form, sia dal pulsante descritti nell'esempio sopra.

Qualsiasi logica non risponda a quanto sopra scritto, potrebbe essere un potenziale bug, per cui da analizzare.

[vuott]

Come posso offendermi nei confronti di chi, chiunque egli sia, sta cercando di darmi una mano a capiere ed a risolvere. Ti sono e vi sono grato.

Grazie a tutti.  

 

gli oggetti vengono posti e gestiti in maniera pseudo-tridimensionale come su una piramide.  etc etc

Bella spiegazione il tuo intervento. Grazie md9327 !

[sotema]

Se ho ben compreso quello che Picavbg vorrebbe ottenere è la gestione di un determinato evento indipendentemente dall'oggetto su cui viene compiuta l'azione. mantenendo l'esempio del MouseDown() una soluzione potrebbe esse la seguente:

1. associ a tutti gli oggetti contenuti nella form lo stesso gruppo (ad esempio "miogruppo")
2 Nella classe della form scrivi la sub:

Codice: gambas [Seleziona]

Public Sub form_MouseDown()
  Message("Premuto Mouse")
End

3 ed infine inserisci la sub:

Codice: gambas [Seleziona]

Public Sub mygrp_MouseDown()
  form_MouseDown()
End

[vuott]

una soluzione potrebbe esse la seguente:

A me questa soluzione funziona: ovunque io clicchi, su oggetti posti nel form o sul form stesso, viene mostrato il messaggio.

[Picavbg]

I vostri accorati suggerimenti e ragionamenti mi commuovono tantisssimo. 
Vi ringrazio tutti, ma ho risolto a modo mio, senza disturbare la proprietà GROUP. Ho dovuto, ahimè, sbracciarmi e sfornare ben 38 procedure di tipo Oggetto_MouseDown, ma alla fine ce l'ho fatta. Conosco benissimo come funziona GROUP perchè l'ho già utilizzato nello stesso programma dentro un'altra Form. Qui, ribadisco il mio concetto: non ne vedo la necessità. Poi vorrei sapere come mai Gambas, nonostante la piramide disegnata da md9327,  intercetti la pressione di un tasto qualsiasi della tastiera scatenando l'evento KeyPress della Form prima dello stesso tipo di evento gestito nella relativa procedura dell'oggetto possessore del focus in quel momento, come per es. una TextBox. A suo tempo ho scritto le seguenti due procedure:

Codice: gambas [Seleziona]

Public Sub Form_KeyPress()
'---------------------------------------------
  QualeTasto = New CheTasto($_Tasto) ' richiamo del modulo per limitare l'input ai soli dati numerici
  Print "Evento Form_KeyPress --> tasto premuto= '" & QualeTasto.$_Como & "'"
  Select Case QualeTasto.$_Como
          Case "Invio"
            Select Case $_contrAct
                    Case "OptNuovo"
                      OptNuovo.SetFocus
                    Case "OptVecchio"
                      OptVecchio.SetFocus
                    Case "RiprMovSel"
                      GriMovv.SetFocus
            End Select
   End Select
'.....bla.....bla.....bla
End

Public Sub MovDigOk_KeyPress()
  QualeTasto = New CheTasto($_Tasto) ' richiamo del modulo per limitare l'input ai soli dati numerici
  Print "Evento MovDigOk_KeyPress --> tasto premuto= '" & QualeTasto.$_Como & "'"
  Select Case QualeTasto.$_Como
          Case "Invio"
            MovDigOk_Click()
  End Select
End

L'effetto prodotto dal suddetto codice é
1) qualsiasi tasto premuto nella tastiera scatena un evento KeyPress, ma solo in due procedure "_KeyPress" esiste un comado Print e tutte le volte che ho premuto un tasto, fino al tasto INVIO sull'oggetto grafico Button da me denominato "MovDigOk" ho ottenuto le seguenti righe di Print nella Console di Gambas:

2) Esito della gestione "Evento KeyPress":
Evento Form_KeyPress --> tasto premuto= 'p'
Evento Form_KeyPress --> tasto premuto= 'r'
Evento Form_KeyPress --> tasto premuto= 'e'
Evento Form_KeyPress --> tasto premuto= 's'
Evento Form_KeyPress --> tasto premuto= 'a'
Focus sulla TextBox 'ImpMovDig'
Evento Form_KeyPress --> tasto premuto= '6'
Focus sulla TextBox 'SegnoEU'
Evento Form_KeyPress --> tasto premuto= 'u'
Evento Form_KeyPress --> tasto premuto= 'Tab-Avanti'
Focus sul Button 'MovDigOk'
Evento Form_KeyPress --> tasto premuto= 'v'
Evento Form_KeyPress --> tasto premuto= 'i'
Evento Form_KeyPress --> tasto premuto= 'Canc-crt-prec'
Evento Form_KeyPress --> tasto premuto= 'Canc-crt-prec'
Evento Form_KeyPress --> tasto premuto= 'Canc-crt-prec'
Evento Form_KeyPress --> tasto premuto= 'e'
Evento Form_KeyPress --> tasto premuto= 's'
Evento Form_KeyPress --> tasto premuto= 'c'
Evento Form_KeyPress --> tasto premuto= 'a'
Focus sulla TextBox 'ImpMovDig'
Evento Form_KeyPress --> tasto premuto= '1'
Evento Form_KeyPress --> tasto premuto= '1'
Focus sulla TextBox 'SegnoEU'
Evento Form_KeyPress --> tasto premuto= 'u'
Evento Form_KeyPress --> tasto premuto= 'Tab-Avanti'
Evento Form_KeyPress --> tasto premuto= 'Tab-Avanti'
Evento Form_KeyPress --> tasto premuto= 'Invio'
Evento Form_KeyPress --> tasto premuto= 'Tab-Avanti'
Evento Form_KeyPress --> tasto premuto= 'Invio'
Evento MovDigOk_KeyPress --> tasto premuto= 'Invio'

Come è ben visibile dalle Print ottenute, L'evento Form_KeyPress è stato sempre scatenato, a prescindere dall'oggetto avente il Focus al momento della pressione del tasto, ma anche quando, ho premuto il tasto 'INVIO' col focus attivo sul pulsante MovDigOk, relativamente al quale ho scritto una procedura KeyPress; infatti la riga di Print è stata prodotta due volte, la prima al momento della cattura dell'evento KeyPress a livello di Form, la seconda  al momento della cattura dell'evento KeyPress a livello dell'oggetto MovDigOk, interno alla Form.
Ho voluto rimarcare la rilevazione dell'evento KeyPress da parte di Gambas, perchè riguarda sempre oggetti grafici di Gambas e viene gestito sempre dentro la classe Form che a me da l'impressione di un "supervisore facente parte".
A questo punto il ragionamento  che faccio da semplice utente non esperto di Gambas è: Il diverso comportamento di Gambas relativamente alla periferica esterna "Tastiera" e relativamente alla periferica esterna "Mouse" può essere voluto, ma bisognerebbe farsi spiegare perchè, oppure c'è un vero e proprio bug in Gambas. Se si tratta di un bug, e questo solo il mago M...erlino lo sa, andrebbe apportata la dovuta correzione. Ciò spiegherebbe meglio il mio rifiuto ad utilizzare un metodo (group), sprecato secondo me per il tipo di impiego a cui dovrei spingerlo forzatamente.
Spero di avere ancor più chiarito il mio ragionamento, poco tecnico, se vogliamo, ma rivolto sicuramente all'utente.