[Risolto] formkeydown non rileva la combinazione tasti Shift+Tab

[petrusic]

il tuo uso del TAB mi ha spiazzato perchè non uso mai combinazioni di sistema o simili (tipo TAB o SHIFT TAB appunto) per gestire
l'input sulle mie applicazioni. TAB e SHIFT TAB hanno un loro ruolo già prestabilito e quindi usarle per altro è controproducente.

Come, come?
E' vero che non programmo più per scopi professionali. Quando cominciai a programmare, da professionista, non esistevano  i pc ed un elaboratore con 32 KB di memoria centrale, corredato di unita a dischi, unità a nastro, stampanti e lettori di schede perforate(si, c'erano anche quelli), occupava un'area di circa 40 m², ma da quando ho cominciato a   . . .   passare il tempo scrivendo programmi ad uso e consumo personale su pc, ho sempre avuto a che fare con l'inout da tastiera, ma non ho mai letto niente su come riconoscere l'input proveniente dalla tastiera non necessariamente attraverso i valori esadecimali prodotti dalla pressione di un qualsiasi tatso.

La tua esperienza mi incuriosisce. Potresti darmi uno spunto?

[DragoRosso]

Scusa, non volevo offenderti in alcun modo.
Il mio discorso era semplicemente legato al fatto della progettazione, ossia al fatto che prima di "buttare" giù codice sarebbe necessario "buttare" giù un pò di progettazione ... cioè linee guida su cosa l'applicativo dovrà fare, e poi sviscerare tutti i singoi punti a cascata. E' buona pratica, non sempre seguita: e quando io non la seguo sorgono sempre problemi e imprevisti ... e ogni volta dico "non ci cascherò più" ... ma non serve a nulla, tanto ci ricascherò comunque.

Poi è chiaro che il codice seguirà un suo percorso, ma generalmente in ambito produttivo si segue un minimo di progetto, che serve a più scopi: intanto ad inquadrare tempi, metodi, risorse e poi per fornire a chiunque prenderà in mano il progetto (o si unisca come gruppo di lavoro) una indicazione sulla via percorsa.

Comunque anche quando ho iniziato io non esistevano i PC, solo UNIX e CP/M. E a quel tempo i codici da tastiera li leggevo in hardware non come codici ma come ROW/COLUMN (essenzialmente abbinati alla connessione elettronica) visto che l'hardware riportava quelli come dati. Poi si abbinavano da tabelle il codice dei tasti e non esistevano 1000 formati di tastiera, ma meno di una decina.

Io ho iniziato durante la scuola a sviluppare prima parti di FIRMWARE da usare nei sistemi civili CON MICROCONTROLLORI dell'epoca, poi con L'AVVENTO DEI PRIMI pc a modificare ed integrare i bios esistenti (due all'epoca per tutti i sistemi) sempre per usi civili (sportelli ATM ad esempio).
Nel contempo ho incominciato a produrre i primi programmi di gestione magazzino per le piccole attività della mia zona. In seguito mi sono dedicato in buona parte al mondo industriale (CAD / CAM ed integrazione diretta con i CNC senza operatore) Siamo tra fine anni 70 a metà anni 80.
Schede perforate (anzi nastri, perchè generlamente erano schede lunghe una decina di metri o anche più) ne ho viste sino alla nausea, anzi più che viste mi toccava fare i programmi per la loro scrittura e lettura, e per la prima volta usai seriamente l'unità NIBBLE, visto che la maggior parte delle macchine industriali lavorano a 4 bit + 1 di controllo.
A quel tempo sviluppavo sotto XENIX SCO o altri SO proprietari derivati da UNIX (dalla famosa versione SYSTEM 7) e sotto i primi DOS. Linguaggi produttivi erano l'assmebler e il C, ed il Pascal come complemento visto che a quell'epoca non era fornito di tutto il necessario per operare interamente nel mio campo di lavoro. INT08, INT10, INT13 e INT16 furono per diversi anni le funzioni più usate in assoluto.

Poi la storia è lunga ma non voglio tediare ulteriormente chi ci legge.

[petrusic]

Scusa, non volevo offenderti in alcun modo.

Io non sono offeso. La mia espressione Come, come? è stata una manifestazione di meraviglia perchè ho  capito che tu gestisci il riconoscimento dei codici prodotti dalla pressione dei vari tasti senza interrogare il Key prodotto.

Ma non mi hai detto se ho capito male o se mi puoi confidare dove potrei imparare quella tecnica, sempre che esista una guida.
Ho sempre gradito ed apprezzato i tuoi utilissimi suggerimenti.

[DragoRosso]

Io non sono offeso. La mia espressione Come, come? è stata una manifestazione di meraviglia perchè ho  capito che tu gestisci il riconoscimento dei codici prodotti dalla pressione dei vari tasti senza interrogare il Key prodotto.
Ma non mi hai detto se ho capito male o se mi puoi confidare dove potrei imparare quella tecnica, sempre che esista una guida.
Ho sempre gradito ed apprezzato i tuoi utilissimi suggerimenti.

In realtà non è che riconosco i tasti, riconosco le azioni dei tasti, ma quelle basi. Il <TAB> (ossia il tasto TAB) ad esempio muove il focus tra i vari controlli, il tasti freccia lo muove tra  le caselle di una griglia. Inoltre Delphi ha le "gesture" integrate quindi ci sono tutta una serie di azioni (il TAP ad esempio o lo ZOOM) che sono già integrate e possono scatenare già un evento.
E per tutte le altre azioni uso gli eventi tipo OnKeyDOwn o OnKeyPress come hai fatto tu.

Poi ad esempio ogni volta che entro in un controllo (OnEnter) con l'immissione attiva, visualizzo una tastiera virtuale (il tipo dipende da cosa accetta il controllo) e ogni volta che premo il tasto <INVIO> o esco dal controllo chiudo la tastiera, tutto ciò quasi in automatico con due righe di codice complessive per tutto il programma (che sempre in Delphi potrebbe essere in automatico completamente ... ma sono troppo pigro per implementarlo ...).

Non è che ci sia un manuale per ciò, è solo la necessità e l'esperienza che mi ha fatto sviluppare certe soluzioni ... che per me vanno bene ma magari per altri no.

P.S.: poi, un'altra cosa che sicuramente mi agevola è che sviluppo prevalentemente per Windows e quindi conosco anche soluzioni API dirette del sistema operativo che possono aiutare in certe situazioni.

[petrusic]

Ho capito, grazie.
A me piace molto l'idea di sfruttare la funzione IsShortCut. Ho già fatto una prova sostituendola all'evento OnKeyDown per una ComboBox ed ha funzionato perfettamente. Penso che posso mettere in pratica il metodo anche per tutte le altre caselle della Form.
Ho pensato anche come creare un ingranaggio che mi permetta di capire quale casella è attiva al momento e fare partire una routine di controllo per quella casella, proprio come se fosse la sua procedura KeyDown.
 

[DragoRosso]

Se vuoi un piccolo suggerimento, basta che nell'evento IsShortCut leggi la proprietà della Form -> ActiveControl.
Poi a seconda del controllo attivo puoi andare a rilevare il sottoelemento, come la cella di una griglia o altro.

In questo modo sai a quale componente / sottocomponente è legato l'evento stesso (cioè IsShortCut).

Codice: [Seleziona]

function TFormxxx.IsShortcut(.....
begin
   if ....
   if ActiveControl = Button1 then
     begin
         ......
     end;
   if ActiveControl = StringGrid1 then
     begin
        .......
     end;

end;

[petrusic]

@ DragoRosso
Ho seguito il tuo ultimo suggerimento ed ora sto cercando di rendere funzionale e funzionante il tutto. É per ciò  che avrei bisogno di chiarire una mia incomprensione sulle istruzioni conclusive della :

Codice: [Seleziona]

function TForm1.IsShortCut(var Msg: TLMKey): Boolean;
begin
  · · ·
  if (Msg.CharCode = VK_TAB) and (GetKeyState(VK_SHIFT) < 0) then
    begin
      writeln('Shift+Tab intercettato !!! YAHOO');
      Result := True;
    end
  else
    Result := inherited;  ** ? **    Che cosa restituisce ?
end;

Infatti, mentre riesco a comprendere       Result := True/False, entrambi  valori booleani, 
mi risulta incomprensibile        Result := inherited

Se la traduzione di    inherited  è  "ereditato" e  l'alternativa a "True" è soltanto "False", allora, in questo caso ,
scrivere Result := inherited è lo stesso che scrivere  Result := False  ??

[DragoRosso]

"Inherited" indica che deve essere chiamata la funzione originale, e viene usato quando si eseguono gli override (se vedi IsShortCut è defintia come override).

Quindi "Result" avrà come valore quello ritornato dalla funzione originale.

Quando si eseguono gli override è buona norma usare "inherited" quando non si esegue nulla nella propria funzione.

E' tipico usarlo quando si definiscono a runtime distruttori o creatori di classi o oggetti derivati.

[petrusic]

Non so perchè, ma la "function TFormX.IsShortCut " non restituisce più il char "9" del tasto |TAB| e "GetKeyState(VK_SHIFT)" NON contiene più "-1"
Ecco cosa ho trovato:

Msg.CharCode = 16
public var TLMKey.CharCode: Word
/usr/share/lazarus/4.6.0/lcl/lmessages.pp(342,5)
Description
Virtual Key constant (VK_XXX).
Package
LCLBase                                                                             
--------------------------------------------------------------------------
GetKeyState(VK_SHIFT) = <Error: calling functions not allowed at 12: "(">
const VK_SHIFT = 16
/usr/share/lazarus/4.6.0/lcl/lcltype.pp(419,3)
See also VK_LSHIFT, VK_RSHIFT
 (Source)
Package
LCLBase

Ora sono proprio nel pallone !!!

Ah, dimenticavo Ecco la parte iniziale della mia function TForm2.IsShortCut

Codice: [Seleziona]

function TForm2.IsShortCut(var Msg: TLMKey): Boolean;
var
 . . .
  codTasto: Integer;

begin
  if (Msg.CharCode = VK_TAB) AND (GetKeyState(VK_SHIFT) < 0) then   
  begin
    codTasto:= VK_TAB * (-1);      // imposto il campo codTasto in negativo per riconoscere la pressione combinata di SHIFT+TAB (Tabulazione Indietro)
  end
  else begin
    codTasto:= Msg.CharCode;
  end;
 . . .

[DragoRosso]

Scusa, ma la chiamata a "inherited" ?
Se fai l'override devi chiamare sempre la funzione originale ... la catena delle chiamate dovrebbe sempre essere rispettata.

[petrusic]

Scusa, ma la chiamata a "inherited" ?
Se fai l'override devi chiamare sempre la funzione originale ... la catena delle chiamate dovrebbe sempre essere rispettata.

Mi dispiace non avere riportato tutto il codice della function IsShortCut

Codice: [Seleziona]

function TForm2.IsShortCut(var Msg: TLMKey): Boolean;
var
  swTrovato: Boolean = False;

  i: Integer;

  codTasto: Integer;

begin
  if (Msg.CharCode = VK_TAB) AND (GetKeyState(VK_SHIFT) < 0) then   // sono stati premuti i tasti SHIFT+TAB (Cursore Indietro)
  begin
    codTasto:= VK_TAB * (-1);      // imposto il campo codTasto in negativo per riconoscere la pressione combinata di SHIFT+TAB (Tabulazione Indietro)
  end
  else begin
    codTasto:= Msg.CharCode;
  end;
  case codTasto of
    VK_RETURN:    // è stato premuto il tasto |INVIO(13)|
      begin
        AttivoPulsOK;
        if swdigCompleta then
        begin
          BpulsOk.SetFocus;
        end;
      end
    else begin
      swFineDigit:= False;
    end;
  end;
  end
  else begin
    if ActiveControl = Form2.EImportFormula then
    begin
      mioEImportFormulaKeyDown(codTasto);
    end
    else begin
      if ActiveControl = Form2.ESimbEU then
      begin
        mioESimbEUKeyDown(codTasto);
      end
      else begin
        if ActiveControl = Form2.CBvoceCtoCas then
        begin
          codTasto:= mioCBvoceCtoCasKeyDown(codTasto);
        end
        else begin
          if ActiveControl = Form2.CBvoceSotCtoCas then
          begin
            codTasto:= mioCBvoceSotCtoCasKeyDown(codTasto);
          end
          else begin
            if ActiveControl = Form2.CBBenef then
            begin
              mioCBBenefKeyDown(codTasto);
            end;
          end;
        end;
      end;
    end;
  end;
  if (Msg.CharCode = VK_TAB) AND (GetKeyState(VK_SHIFT) < 0) then
  begin
    Result:= True;
  end
  else begin
    Result:= inherited;   // "Inherited" indica che deve essere chiamata la funzione originale e viene usato quando si eseguono gli Override
  end;
end;   

Ora ho riportato tutto. Avevo omesso l'ultima parte perchè già all'avvia della funzione i valori contenuti in Msg.CharCode e in GetKeyState(VK_SHIFT) NON sono più quelli che fino a ieri erano corretti.

[DragoRosso]

Per sapere se la funzione ... funziona, metti un break point dove l'IF viene sodisfatto (sulla linea "codTasto:= VK_TAB * (-1);") .
Se non si ferma mai li, anche premendo i tasti corretti, prova ad tornare al codice originale di isShortCut (quello prima della tua modifica) e ritenata li con un breakpoint.

[petrusic]

Per sapere se la funzione ... funziona, metti un break point dove l'IF viene sodisfatto (sulla linea "codTasto:= VK_TAB * (-1);") .

Questa è una verifica già fattae ti assicuro che ora non funziona.

Se non si ferma mai li, anche premendo i tasti corretti, prova ad tornare al codice originale di isShortCut (quello prima della tua modifica) e ritenata li con un breakpoint.

S, ci avevo pensato, ma stamani non ho avuto tempo per riprovare.
Ho provato ora e  . . .  f u n z i o n a.

Quindi, ahimè, devo rivedere il mio codice, aggiunto dopo.
 
Ti faccio sapere.

[petrusic]

Ho rivisto il mio codice ed ho cercato di limitare al minimo le mie modifiche all'interno della funcion IsShortCut. Ho provato e l'intercettazione dei tasti Shift+TAB avviene regolarmente. Ecco la nuova struttura della funzione dopo la mia ultima personalizzazione:

Codice: [Seleziona]

function TForm2.IsShortCut(var Msg: TLMKey): Boolean;
var
  codTasto: Integer;

begin
  WriteLn('function TForm2.IsShortCut');
  codTasto:= Msg.CharCode;
  if (Msg.CharCode = VK_TAB) and (GetKeyState(VK_SHIFT) < 0) then
  begin
    codTasto:= VK_TAB * (-1);      // imposto il campo codTasto in negativo per riconoscere la pressione combinata di SHIFT+TAB (Tabulazione Indietro)
    ShowMessage('Shift+Tab intercettato !!! - codTasto = <' + IntToStr(codTasto)+ '>');
    ProcIsShortCut_mio(codTasto);
    Result := True;
  end
  else begin
    Result := inherited;
  end;
end;                           

Ho inserito all'interno della funzione soltanto il richiamo di una mia procedura, la ProcIsShortCut_mio. É dentro quest'ultima che ho preparato l'individuazione del Controllo Grafico attivo al momento e procedere quindi con la gestione dell'insieme di voci appartenenti ad esso:

Codice: [Seleziona]

procedure ProcIsShortCut_mio(codTasto: Integer);
begin
  case codTasto of
    VK_RETURN:    // è stato premuto il tasto |INVIO(13)|
      begin
        AttivoPulsOK;
        if swdigCompleta then
        begin
          Form2.BpulsOk.SetFocus;
        end;
      end
    else begin
      if Form2.ActiveControl = Form2.CBDescr then
      begin
        mioCBDescrKeyDown(codTasto);
      end
      else begin
        if Form2.ActiveControl = Form2.CBDescr then
        begin
          mioCBDescrKeyDown(codTasto);
        end
        else begin
          if Form2.ActiveControl = Form2.CBvoceCtoCas then
          begin
            codTasto:= mioCBvoceCtoCasKeyDown(codTasto);
          end
          else begin
            if Form2.ActiveControl = Form2.CBvoceSotCtoCas then
            begin
              codTasto:= mioCBvoceSotCtoCasKeyDown(codTasto);
            end
            else begin
              if Form2.ActiveControl = Form2.CBBenef then
              begin
                mioCBBenefKeyDown(codTasto);
              end;
            end;
          end;
        end;
      end;
    end;
     swFineDigit:= False;
  end;
end;                                                   

Ancora è tutto da verificare, però l'idea è questa. Così facendo non dovrei incorrere più in sgradite sorprese come quella vissuta ieri.

Però, prima di chiudere, voglio accertare con alcune prove pratiche il mio ragionamento. 

[DragoRosso]

Consiglio:
la funzione IsShortCut di cui fai l'override è una funzione che viene chiamata all'interno del Main Thread (è una callback del sistema operativo e viene processata tramite un preciso messaggio di Windows, CM_??? qualcosa che non ricordo in questo momento).
Essendo chiamata dal sistema operativo è consigliabile che venga eseguita e liberata il prima possibile, senza effettuare elaborazioni pesanti, come ad esempio interazione con componenti grafici.

Quindi dentro li setta tutti i "flag" che ti servono, ma non fare processi pesanti.