Programmazione > Progetti degli utenti
Progetto pgDesigner 2/3
md9327:
A dir la verità ci stò pensando...
Non sò se è il caso di appoggiare temporanemanete qui i sorgenti...
Vediamo se leo è disposto alla cosa, perchè comunque, a versione stabile, dovrò inserirlo su sourceforge.
Ora provo a inviargli un msg in privato, vediamo cosa ne pensa...
Tieni conto che ovviamente si tratta di sorgenti, e sarà necessario disporre dell'intero ambiente Gambas2 (2.8.2).
--- Citazione ---
Nota:
Per SQLite, ho predisposto le funzionalità per gestire sia la versione 2, che la 3, anche se non ho notato differenze sostanziali tra le due. Ho fatto i test di connessione e lettura, e funzionano, ma ancora non ho potuto eseguire quelli di scrittura; per quanto riguarda l'output su file, dovrai vedere se esce tutto in modo corretto.
Stessa cosa per MySQL, per il quale sono partito dalla versione 5.x. Dato che anche MySQL ha subito molti cambiamenti nel tempo, rispetto a PostgreSQL, studiarmi tutte le differenze delle versioni mi è sembrato alquanto oneroso; ad ogni modo, il driver è espandibile, e quindi se qualcuno, oppure ci sarà tempo, si potrà implementare successivamente.
--- Termina citazione ---
md9327:
leo ha risolto il problema, sistemando le cose nel miglior modo possibile.
Dato il problema degli aggiornamenti, posterò di volta in volta in questo thread, tutti gli aggiornamenti, e questo stesso thread servirà oltre che come repository e come punto di riferimento per lo scambio di informazioni relativamente al programma pgDesigner2.
Come già richiesto inizialmente, qualsiasi tipo di aiuto mi sarebbe indispensabile, per poter arrivare alla produzione di un prodotto finito e stabile.
E' ovvio che la cosa poi non finirà, perchè collaborando potremo ampliarlo come vogliamo.
E' anche ovvio che la disponibilità di tempo è dipendente dalle proprie attività, come anche per me, per cui non dobbiamo sottostare a scadenze particolari. Stesso discorso per il tipo di esperienza, perchè qualsiasi tipo di contributo sarà ben accetto; chi poi ha le compentenze necessarie potrà metterle a disposizione nel modo che più desidera.
L'unico obiettivo è quello di farne un programma degno di essere usato, cercando di sfruttare tutte le possibilità che ci dà Gambas.
Allo stato attuale, pgDesigner ha bisogno:
--- Codice: ---
- collaudo delle funzioni
- particolare collaudo delle funzionalità legate ai db:
PostgreSQL, MySQL e SQLite
- traduzioni
- scrittura del manuale utente (italiano e inglese)
--- Termina codice ---
a) Riguardo PostgreSQL ho abbastanza domestichezza con questo DBMS, MySQL poco meno, mentre per SQLite occorre qualcuno che abbia un pò di esperienza.
b) Al momento documentazione tecnica non ne ho, dato che per i programmi che costruisco da solo uso solo la capoccia e ho una leggera allergia ai programmi office.
c) Le funzioni sono tante, come anche le classi e gli oggetti che compongono il programma, per cui il tempo per i test si può ridurre drasticamente solo grazie alla collaborazione di più persone.
d) Per le traduzioni in inglese mi sono sempre arrangiato da solo (pure male per la verità), mentre ho avuto qualche aiuto estero durante lo sviluppo di pgDesigner1. Seguendo il vecchio pgDesigner1, si dovrebbe riuscire ad implementare: inglese, francese e spagnolo; per il cinese credo sarà un problema :-)
e) Riguardo al manuale utente, si potrebbe prendere come base quello del vecchio programma, ma ci sarà da lavorare parecchio a causa delle molte novità inserite nella nuova applicazione. Tanto per la cronaca, a parte il documento cartaceo, all'indirizzo sourceforge.net è presente la documentazione in formato web. Nel caso qualcuno ne faccia richiesta, sarò ben felice di postare anche questo nel thread (sperando che leo non mi uccida...).
Ricordo ancora che il progetto è open-source, ed è aperto a tutti, e dato che siamo in ambito Gambas, i sorgenti possono servire anche come spunto per altri progetti.
Questo progetto mi ha dato modo di conoscere molto del linguaggio, e credo che la mia esperienza potrebbe servire a qualcun'altro.
Per finire, in allegato invio il file compresso, contenente i sorgenti dell'ultimissima versione. I file che posterò da ora in avanti saranno targati come alpha, seguito da un numero di build che corrisponde alla versione che ho salvato nel mio repository, e qualsiasi riferimento dovrà essere fatto sulla base di questa numerazione.
P.S.: attualmente il file compresso occupa poco più di 1Mbyte.
Un saluto a tutti.
g.paolo:
Per quello che può valere, cerco di dare il mio piccolo contributo.
Ho provato il prg all'interno dell'IDE di Gambas ed ho riscontrato quanto esposto nello screenshot allegato.
md9327:
Qualsiasi tipo di aiuto è valido, l'ho scritto più volte nei miei post...
Comunque, tieni conto che il programma è in continua mutazione, per cui è probabile che si verifichino errori come quello che mi hai segnalato.
Il tuo contributo è essenziale, la fase di test è una cosa onerosa se fatta da una sola persona.
Dunque, dal post-it si evidenziano:
a) un piccolo errore dell'etichetta "Dimenzioni"... Ok, provvedo a modificare la traduzione. Per mantenermi sullo standard, ho impostato il programma sulla base della lingua inglese, anche dietro richieste di utenti del precedente pgDesigner, che non comprendevano le note all'interno codice; questo mi fatto decidere sulla lingua di partenza: inglese. Le traduzioni poi le faccio con l'opzione nell'ide di Gambas, o con programmi esterni, ma a volte, in velocità, si inciampa nei tasti... :-)
b) l'errore in uscita credo che molto probabilmente sia dovuto ad un errore di impostazione di un array di ritorno. In Gambas ho notato che se si crea un array, il primo valore determina il tipo di tutti gli elementi, e se questo è nullo (NULL), oppure non riesce a risolverlo, allora và in errore. A parte la probabile svista nel programma, la cosa si evita semplicemente convertendo gli item nel tipo con cui si è definito l'array, esempio:
--- Codice: ---
DIM arr AS String[]
arr = ["luigi", "franco", "giulia", ...]
--- Termina codice ---
nell'esempio la cosa non crea problemi, in quanto all'array vengono passate delle costanti fisse, ma nel caso di:
--- Codice: ---
DIM arr AS Long[]
DIM v1 AS Long
DIM v2 AS Integer = 5
arr = [v1, v2]
--- Termina codice ---
l'array può andare in errore per due motivi: 1) la variabile "v1" non è stata inizializzata, 2) la variabile "v2" è di tipo diverso. In ogni caso le variabili, prima di essere usate, devono essere inizializzate, o con valori fissi, oppure da un ritorno di una funzione; nel caso di "v2" questa, pur essendo inizializzata, è di tipo diverso ma, se prendiamo lo stesso codice e sostituiamo la creazione dell'array con:
--- Codice: ---
v1 = 9
arr = [v1, CLong(v1)]
--- Termina codice ---
a questo punto "v1" la inizializziamo con un valore, e "v2" la convertiamo nel tipo corretto, passiamo gli elementi all'array, e tutto funziona.
Un'altra nota circa gli array: se si passa ad una funzione un array nel seguente modo:
--- Codice: ---
var = CalcolaElementiArray( [] )
--- Termina codice ---
nell'esempio passiamo alla funzione un'array vuoto, ma la funzione come lo interpreterà questo array? Di che tipo è? ...
Bè, strano a dirsi, ma Gambas lo interpreta in un array stringa vuoto.
Se invece alla funzione gli passiamo un array in questo modo:
--- Codice: ---
var = CalcolaElementiArray( [1,2,3,4,5] )
--- Termina codice ---
la funzione come interpreta questo array? Un array di Integer !
Il bello e il brutto del discorso, è che se vogliamo trattare un array correttamente, dobbiamo riempirlo di elementi del tipo corretto:
--- Codice: ---
var = CalcolaElementiArray( [CLong(1),2,3,4,5] )
--- Termina codice ---
in questo modo la funzione capirà che l'array passato è di tipo Long, NON Integer.
Vabbè questa disquisizione forse dovevo scriverla direttamente nel WiKi, ma non escludo di farlo in futuro; ad ogni modo questo thread serve anche a questo...
Grazie e continua così, questo tipo di test servono !!!
md9327:
Nuovo rilascio!
Ho fatto parecchie modifiche a correzione di alcuni errori, e il rifacimento di gran parte del codice delle Form di edit degli oggetti.
Nota: Nei progetti PostgreSQL e MySQL è possibile inserire delle Relazioni, ovvero le classiche foreign-key tra due tabelle. Per creare questo tipo di oggetto, che graficamente appare come una linea tra due tabelle, occorre selezionare dal menu un nuovo oggetto Relazione, puntare con il mouse sulla prima tabella (padre) e tenere cliccato con il tasto sinistro del mouse, indi spostarsi sulla seconda tabella (figlia) e rilasciare il pulsante del mouse; durante l'operazione sarà visibile una linea retta, che rispecchia il tracciamento che si stà compiendo con il mouse. Al rilascio del pulsante, se non esistono particolari condizioni di divieto, comparirà la Form di dialogo per la modifica delle proprietà della nuova relazione (foreign-key).
Condizioni:
a) i due oggetti in relazione devono essere ovviamente due tabelle;
b) le due tabelle devono avere almeno un campo;
c) la tabella padre deve avere una chiave primaria.
Nel caso si presenti una di queste condizioni, la procedura viene abortita.
Ringrazio ancora l'amico darth14n per il suo intervento, che mi ha fatto notare qualche mia svista... :2birre:
Navigazione
[0] Indice dei post
Vai alla versione completa