* * * *

Privacy Policy

Blog italiano

Clicca qui se vuoi andare al blog italiano su Lazarus e il pascal.

Forum ufficiale

Se non siete riusciti a reperire l'informazione che cercavate nei nostri articoli o sul nostro forum vi consiglio di visitare il
Forum ufficiale di Lazarus in lingua inglese.

Lazarus 1.0

Trascinare un file nel programma
DB concetti fondamentali e ZeosLib
Recuperare codice HTML da pagina web
Mandare mail con Lazarus
Stabilire il sistema operativo
Esempio lista in pascal
File INI
Codice di attivazione
Realizzare programmi multilingua
Lavorare con le directory
Utilizzare Unità esterne
TTreeView
TTreeview e Menu
Generare controlli RUN-TIME
LazReport, PDF ed immagini
Intercettare tasti premuti
Ampliare Lazarus
Lazarus e la crittografia
System Tray con Lazarus
UIB: Unified Interbase
Il file: questo sconosciuto
Conferma di chiusura di un applicazione
Liste e puntatori
Overload di funzioni
Funzioni a parametri variabili
Proprietà
Conversione numerica
TImage su Form e Panel
Indy gestiore server FTP lato Client
PopUpMenu sotto Pulsante (TSpeedButton)
Direttiva $macro
Toolbar
Evidenziare voci TreeView
Visualizzare un file Html esterno
StatusBar - aggirare l'errore variabile duplicata
Da DataSource a Excel
Le permutazioni
Brute force
Indy 10 - Invio email con allegati
La gestione degli errori in Lazarus
Pascal Script
Linux + Zeos + Firebird
Dataset virtuale
Overload di operatori
Lavorare con file in formato JSON con Lazarus
Zeos ... dietro le quinte (prima parte)
Disporre le finestre in un blocco unico (come Delphi)
Aspetto retrò (Cmd Line)
Lazarus 1.0
Come interfacciare periferica twain
Ubuntu - aggiornare free pascal e lazarus
fpcup: installazioni parallele di lazarus e fpc
Free Pascal e Lazarus sul Raspberry Pi
Cifratura: breve guida all'uso dell'algoritmo BlowFish con lazarus e free pascal.
Creare un server multithread
guida all'installazione di fpc trunk da subversion in linux gentoo
Indice
DB concetti fondamentali e connessioni standard
Advanced Record Syntax
DB concetti fondamentali e DBGrid
DB concetti fondamentali e TDBEdit, TDBMemo e TDBText
Advanced Record Syntax: un esempio pratico
Superclasse form base per programmi gestionali (e non)
Superclasse form base per programmi gestionali (e non) #2 - log, exception call stack, application toolbox
Superclasse form base per programmi gestionali (e non) #3 - traduzione delle form
Superclasse form base per programmi gestionali (e non) #4 - wait animation
Un dialog per la connessione al database:TfmSimpleDbConnectionDialog
Installare lazarus su mac osx sierra
immagine docker per lavorare con lazarus e free pascal
TDD o Test-Driven Development
Benvenuto! Effettua l'accesso oppure registrati.
Dicembre 10, 2024, 09:40:42 am

Inserisci il nome utente, la password e la durata della sessione.

93 Visitatori, 0 Utenti
Una form dai comportamenti predefiniti

Quando si sviluppa una applicazione destinata ad avere un certo numero di form, è bene prevedere che tutte abbiamo lo stesso comportamento. Se poi a lavorare sullo stesso progetto c'è più di uno sviluppatore allora un metodo comune di lavoro diventa obbligatorio.
Solitamente si dice che si devono definire degli standard di sviluppo.

Per ottenere questo possiamo sfruttare l'ereditarietà dell'oggetto TForm. L'esempio che segue è basato sulla mia esperienza e ovviamente non è l'unico modo possibile.

Il comportamento cercato
Nello sviluppo di un ipotetico gestionale bisogna tener conto anche dell'utente finale. Oggi si stanno diffondendo GUI in cui solitamente, tramite tasto destro del mouse e quindi click su "Properties", si accede alla maschera che permette di modificare i campi di un certo record. Nel gestionale secondo me è meglio un approccio che tenga conto dello stato della maschera. Se pensiamo ad una fattura ad esempio è chiaro che per modificarla abbiamo bisogno di una richiesta esplicita, non è ipotizzabile che con "Properties" ci si trovi già in modifica.
Per questo ho diceso di impostare un comportamento predefinito basato sullo stato della maschera (segue esempio):
Codice: [Seleziona]

Stato iniziale = browse (sola letura) <-+ <-+
 |                                      |   |
 +---> Insert --+                       |   |
 |              |                       |   |
 |              +-> Conferma Insert ----+   |
 |              |                       |   |
 |              +-> Annulla Insert    --+   |
 |                                          |
 +---> Edit   --+                           |
                |                           |
                +-> Conferma Edit ----------+
                |                           |
                +-> Annulla modifiche ------+              


Riepilogando, attualmente una maschera può assumere i seguenti stati (valori di TBaseForm_GuiMode):

valoresignificato
bfgmDisabledvalore usato per disabilitare tutti i controlli (non dovrebbe mai essere usato in casi normali)
bfgmBrowsemodalità browse: non sono ammesse modifiche
bfgmInsertmodalità inserimento
bfgmEditmodalità modifica di un record esistente
bfgmDeleteeliminazione di un record esistente
bfgmWorkInProgressesecuzione di una procedura in corso
bfgmReportInProgressstampa in corso
bfgmConfirmInsertInProgressconferma di un nuovo record in corso
bfgmConfirmEditInProgressconferma delle modifiche di un record esistente in corso
bfgmCancelInsertInProgressannullamento dell'inserimento in corso
bfgmCancelEditInProgressannullamento delle modifiche in corso


Le azioni di un utente
Riguardo all'uso dei menù o dei bottoni, è meglio non precludersi nessuna delle due strade. Per questo motivo verranno sfruttate le Azioni. Queste possono essere abbinate sia alle voci di menù che ai bottoni: impostando un comportamento automatico delle azioni, avrò, gratis, menù e bottoni abilitati o disabilitati di conseguenza.
Quindi per ogni azione che l'utente ha a disposizione, troviamo una TAction (facente parte di una action list).
Queste sono categorizzate a seconda dello stato della maschera attualmente visualizzata.

Category: Browse

azionedescrizione
acUser_Insertazione che permette l'inserimento di un nuovo record
acUser_Editazione che permette la modifica di un record esistente
acUser_Deleteazione che permette l'eliminazione di un record esistente
acUser_Refreshrichiesta di refresh
acUser_Reportazione che permette la generazione di un report



Category: Edit
azionedescrizione
acUser_Confirmrichiesta di conferma (dell'inserimento o modifica)
acUser_Cancelrichiesta di abbandono (dell'inserimento o modifica)


Category: Navigation
azionedescrizione
acUser_Firstazione che permette lo spostamento al primo record
acUser_Priorazione che permette lo spostamento al record precedente
acUser_Nextazione che permette lo spostamento al record successivo
acUser_Lastazione che permette lo spostamento all'ultimo record


Category: Stateless

azionedescrizione
acUser_Helpazione che permette la visualizzazione dell'help


Ogni operazione dell'utente sarà suddivisa in 3 sotto operazioni:
- prima di eseguire (per fare test o precaricare dati)
- esecuzione
- dopo l'esecuzione (istruzioni da eseguire a conclusione dell'operazione, es: invio mail)
Per chiarimenti andate a vedere, ad esempio, il codice del metodo DoInsert.

Come si usa?
L'utilizzo è semplicissimo, non bisogna installare nulla: (1) includere la unit uBaseForm nel progetto, (2) creare una nuova form e (3) nell'editor dei sorgenti, modificare l'ereditarietà della nuova sottoclasse da TForm a TfmBaseForm.

Anche la scrittura del codice è stata lasciata intenzionalmente semplice: si tratta di normale programmazione ad oggetti.
Ogni azione, metodo ed evento sono stati nominati in modo da rispondere ad una precisa convenzione.
Se ad esempio creiamo una form che eredita da TfmBaseForm e vogliamo ad esempio gestire l'inserimento di un nuovo record sappiamo che:
- l'azione corrispondente si chiama: acUser_Insert
- nell'evento OnEcecute dell'azione si lancia un unico metodo: DoInsert
- nel metodo DoInsert, quando presenti, vengono lanciati gli eventi:
  . OnInsertTest    : test che permette di stabilire se l'azione "Insert" è eseguibile
  . OnInsertBefore  : operazioni da eseguire prima dell 'insert vero e proprio (la gui non è ancora in Insert mode)
  . OnInsertExecute : operazioni relative all'insert
  . OnInsertAfter   : operazioni da effettuare dopo che l'insert è stato consolidato sul database

Nessuno di questi eventi è obbligatorio ma OnInsertExecute è necessariamente l'unico evento dove ci si aspetta di trovare del codice.
Quindi bisogna operare nel seguente modo:
1) definire 1 procedura di tipo TBaseForm_NotifyEvent
2) (solitamente nell'OnCreate della form) assegnare il puntatore di questa procedura all'evento

 
Progetto di esempio
Un progetto di esempio è scaricabile da subversion
Codice: [Seleziona]
svn checkout svn://svn.code.sf.net/p/lazarusiug/liug/trunk/baseform lazarusiug-liug


Oppure lo trovate in allegato sul seguente thread:
http://www.lazaruspascal.it/index.php?topic=1392.0

Il contenuto è il seguente:
TestBaseForm (.lpr e .lpi)file di progetto
umainform (.pas e .lfm)form principale
ubaseform (.pas e .lfm)form con la superclasse da cui ereditare
ubaseformtester (.pas e .lfm)sottoclasse che eredita da ubaseform


Spoero che la codifica sia sufficientemente autoesplicativa, per chiarimenti basta aprire un thread sul forum.

Share on Twitter! Digg this story! Del.icio.us Share on Facebook! Technorati Reddit StumbleUpon

Articles in « Lazarus 1.0 »

Comments *

Commenting option has been turned off for this article.

Recenti

How To

Utenti
  • Utenti in totale: 802
  • Latest: maXim.FI
Stats
  • Post in totale: 19252
  • Topic in totale: 2297
  • Online Today: 112
  • Online Ever: 900
  • (Gennaio 21, 2020, 08:17:49 pm)
Utenti Online
Users: 0
Guests: 93
Total: 93

Disclaimer:

Questo blog non rappresenta una testata giornalistica poiché viene aggiornato senza alcuna periodicità. Non può pertanto considerarsi un prodotto editoriale ai sensi della legge n. 62/2001.