Un'altra cosa: MySQL non tiene conto delle clausole CHECK. Permette di inserirle per una finta compatibilità con gli altri dbms, ma è una cosa ingannevole, dato che non le rispetta.
Non ritengo MySQL un dbms secondario, anche perchè di passi in avanti ne ha fatti parecchi, ed è per la sua velocità che viene impiegato, ad esempio, nei CMS. Il motore è abbastanza semplice ma ci sono grosse differenze rispetto ad un PostgreSQL o un Oracle (con cui lavoro costantemente...).
Dato che questi due li uso in ambito lavorativo, ne conosco abbastanza i segreti (Oracle di più...), e ritengo che siano adatti più in sistemi ad alto livello, cosa che MySQL forse raggiungerà con il tempo.
Ma a parte le disquisizioni...
L'errore in fase di lettura l'ha già segnalato darth, e comunque l'ho già corretto.
Riguardo alla versione Gambas, io uso attualmente la 2.8.2 (ultima stabile), e per cui sarebbe meglio tu usassi questa, altrimenti potremmo avere delle casistiche di errore anomale, dato che alcune cose sono cambiate.
Riguardo ai nuovi tipi MySQL, nel codice sorgente del driver (file pgDriverMySQL50.class, unica versione per adesso...), all'inizio dello stesso, nel metodo "InitDataType()" sono dichiarti tutti i tipi previsti per quella versione del driver. Sono presenti un certo numero di chiamate, con relative creazioni di oggetti pgTypeItem, che definiscono ogni singolo tipo, compresa una propria descrizione. Nella classe "pgTypeItem.class", metodo costruttore "_new()", vengono definiti i parametri di costruzione, che in pratica sono:
' @parameter : String : Name (default="")
' @parameter : String : Type (default="")
' @parameter : String : Parameter (default="")
' @parameter : String : Storage (default="")
' @parameter : String : Min value (default="")
' @parameter : String : Max value (default="")
' @parameter : String : Resolution (default="")
' @parameter : String : Description (default="")
Sono tutti parametri descrittivi, sui quali non viene effettuata alcuna operazione, ma per esempio: il campo nome viene caricato nella combo di edit dei campi tabella, la descrizione viene usata come tooltip (se presente).
Se vuoi, puoi implementare questa parte di codice con i nuovi tipi, visto che li conosci bene, altrimenti sono costretto comunque a leggermi la documentazione relativa. Poi mi passi le variazioni, le controllo un attimo, e le inserisco nella prossima release.
Riguardo alla lettura del db, infatti mi baso sulla tabella "information_schema", come puoi vedere nel codice del driver, ma ho notato che alcune cose non ci sono, o per lo meno forse non sono in quella tabella, oppure devono essere calcolate in qualche modo, non sò bene ora...
Ora provo pure il file di progetto che mi hai inviato, ti faccio sapere se c'è qualcosa che non và.
Per finire: ad ogni modo, dall'ultimo rilascio, ho fatto proprio alcune modifiche al driver MySQL. Ora vedo di fare il pacchetto e di pubblicarlo appena possibile.
Se hai domande da fare, circa la logica del programma, o su cose inerenti al codice, non esitare; inoltre, se hai qualche idea sui campi da mostrare nelle form di edit, idem con patate!
Ciao e grazie!
Nuova release alpha!
Modifiche: eseguite alcune correzioni nelle form di edit degli oggetti, e nel driver per MySQL. Inoltre è stato corretto il problema segnalato da darth, relativo alla funzione di gestione dello storico progetti.
Erroneamente, nei precedenti file, la directory del progetto era stata nominata come il file *.tar.gz. Da ora in avanti, la directory assumerà il corretto nome: pgDesigner2
Nota: nella home utente viene creata la directory nascosta ".pgdesigner2", che contiene il file di configurazione del programma e il file di log. Quest'ultimo viene soprattutto utile in caso di errore, perchè riporta gli errori rilevati nel programma, in particolare quelli che provocano il crash. In questo caso può essere utile inviarmi questo file, in modo che possa identificare eventuali anomalie; finora mi è sono state inviate immagini del messaggio di errore, ma ritengo che è il caso di evitarle, perchè appesantiscono inutilmente il forum. Restano valide comunque quelle necessarie ad indicare aspetti e condizioni particolari o anomalie, come chiara descrizione di questi eventi.
Grazie a tutti!
@md9327
Il fatto che il file non è visibile non dipende da pgDesigner, dato che usa l'oggetto Dialog.OpenFile() per la selezione del file di database. Non credo neanche sia un problema di Dialog, perchè non ho mai riscontrato problemi simili. L'unica cosa mi viene in mente, è che forse hai qualche impostazione dell'ambiente Gnome che limita la visualizzazione; ma la cosa è molto strana, perchè a quanto mi risulta l'unica impostazione è la possibilità di nascondere solo i file che iniziano con il punto (file nascosti), a meno che il file non abbia qualche impostazione chmod che comunque obbliga ad un comportamento anomalo.
Impostazioni d'ambiente dici? Non ho settato nulla al di fuori delle impostazioni di default, e per quanto concerne i permessi, il file incriminato è settato su 777.
Confermo che anche in Ubuntu 8.04 il punto serve a nascondere files e cartelle, e la versione di gambas2 che uso è la 2.8.2-1ubuntu.
Confermo comunque che il problema sta proprio nella mancanza di estensione, perchè se provo a rinominarlo come "3M_immobiliare.sq3" viene visto ed aperto.
Dopo aver importato nel nuovo progetto due tabelle dal file sqlite3, ho provato a spostare le singole finestre flottanti contenenti la descrizione dei singoli campi, dalla posizione di aggancio alla sinistra della finesrta programma.
Se provo a spostare una tabella con pochi campi, la medesima si sposta agevolmente senza problemi, ma se ci provo con quella che contiene circa 50 campi ottengo il seguente errore:
unkown symbol 'MouseY' in class 'pgPanelProjectGraphic'
code: 11
class: pgActionManager
where: pgActionManager.AreaMouseMove.1747
trace: pgActionManager.AreaMouseMove.1747
trace: pgEventManager.Event_MouseMove.264
Se ti può aiutare....!
Ooops, mi correggo!
Ho scoperto che anche con le finestre con pochi campi accade l'errore suddetto, con la differenza che l'errore riporta "mouseX" anzichè "mouseY" quando la finestra dei campi tabella si avvicina ai pannelli di destra.
Proverò a vedere se c'è qualcosa che impedisce di vedere i file senza estensione... ti farò sapere...
Riguardo all'errore lo controllo, ma penso sia causato quando l'immagine supera i limiti del diagramma.
Tanto per sapere, hai per caso modificato le dimensioni di base del diagramma di progetto (menu Strumenti/Opzioni) ?
Ultima cosa, le anomalie le hai riscontrate in quest'ultimissima versione ?
Comunque, controllo il tutto e vediamo di correggere...
Bye
Ops, hai ragione tu su Dialog !
A quanto pare, se si imposta un filtro, come ad esempio:
Dialog.Filter = ["*.*", ("All files")]
la visualizzazione si limita a far vedere tutti i file, ma che abbiano comunque un'estensione (il punto + *).
Se gli metto un solo asterisco (es. "*"), fà vedere solo i file senza estensione, e così via...
Non mi ero accorto di questa anomalia, perchè in ogni caso prevedevo un estensione ai file che leggevo e creavo, ma a questo punto il discorso cambia...
Ho provato a togliere il filtro, e in effetti ora funziona, ma la cosa è alquanto strana, e molto diversa dal comportamento di tutti gli altri linguaggi.
Ad ogni modo, se digiti direttamente il nome del file, lo prende ugualmente, solo che non lo vedi in lista, ma certo che la cosa non è molto simpatica.
Comuque ho già fatto la modifica...
Sull'errore "Mouse" mi ero sbagliato, in quando è vero che si verificava all'avvicinarsi dell'oggetto al margine del diagramma, ma era causato da un'errore da me introdotto in alcune ultime modifiche del codice.
Anche questo è stato corretto, ed è presente in questa release.
Bel lavoro!
P.S.: vedi che l'aiuto serve?
Un paio di domande:
- Cosa devo mettere come Type? Va bene "G"? Considera che non è un testo, perchè per inserire ad esempio un punto la sintassi è questa:
INSERT INTO t ( p ) VALUES ( POINT(1 1) )
- Devo mettere i nuovi tipi in ordine alfabetico mischiati con gli altri, oppure li metto tutti alla fine per raggrupparli? Sono 8.
- Con Parameter ti riferisci ai parametri utilizzati per creare il campo, cioè in pratica le dimensioni?
A parte le descrizioni ho lasciato tutti gli altri campi in bianco. La documentazione non fa cenno alla memoria occupata. In effetti, a parte POINT, sono tutte collezioni di oggetti e quindi immagino non sia calcolabile. Gli altri campi (massimo, minimo, risoluzione) non sono applicabili.
----
Stavo ripensando al problema dei campi ENUM/SET. Credo che un modo pulito per risolvere la questione sia il seguente:
- Nell'evento MYSQLLength_Change fare un parsing del campo Param dell'ogetto pgTypeItem selezionato
- se contiene [(l)] il form si deve comportare come fa ora
- se non contiene nulla, MYSQLLength deve essere disabilitato
- se contiene qualcosa di simile a ciò che contiene ora ENUM: TextLabel10.Text = "Values". In questo caso, l'evento Event_KeyPress deve evitare di fare il controllo sui tasti premuti.
Tra l'altro, un parsing simile si potrebbe fare per il contenuto deel campo pgTypeItem.Type: in base al suo contenuto, alcuni checkbox possono essere disabilitati. Ad esempio, Signed non ha significato per un campo di testo.
Cosa ne dici? Se vuoi io mi offro di provare a fare quest'ultima cosa. So che è meno utile, ma è molto semplice e quindi è un modo indolore per familiarizzare con il tuo codice, se poi non ho problemi e il mio lavoro ti soddisfa, posso provare a fare anche la prima (nel modo che ho descritto o nel modo che mi dirai tu).
In genere non ho tempo da dedicare agli hobby, ma per qualche giorno posso darti una mano, se ti serve.
@md9327
Confermo che l'errore si presentava sulla versione 643 e che non ho modificato la grandezza della finestra. Vedo comunque che hai trovato l'inghippo!
Ora provo la 644
Due piccole domande:
1) non ho trovato la funzione di "browse" della singola table, non esiste o sono io imbranato?
2) non ho ancora provato il metodo per impostare le relazioni tra i campi, ma immagino che dopo aver importato le table si debbano stabilire i vari indici primari e secondari, ed allora è possibile collegare tra loro gli omonimi indici di riferimento. E' corretto?
1) non capisco cosa intendi per "browse", in pgDesigner non è implementata alcuna funzione per visualizzare i dati del database, perchè non è il suo scopo;
2) se parli di sqlite, l'implementazione delle relazioni non è attiva, perchè non trovato nessuno modo per gestirla su questo db, anzi, non mi sembra proprio che le utilizzi. Se vogliamo implementarla nel progetto, possiamo farlo a livello puramente grafico, anche se non lo ritenevo utile, solo che poi non viene utilizzato in output, durante la creazione del db.
Ad ogni modo, per attivare una relazione ha bisogno di: almeno due tabelle, almeno un campo come chiave primaria sulla tabella padre, e poi anche un mouse, una tastiera...ecc. :-) Ovviamente scherzo, ma i primi due elementi sono quelli veri ed essenziali.
Ha, la prima tabella selezionata è quella padre; inoltre, se non è presente già un campo con nome e tipologia uguale al campo chiave della tabella padre, nella tabella di destinazione vengono creati in automatico, e comunque modificabili successivamente...
For santecaserio:
- Cosa devo mettere come Type? Va bene "G"? Considera che non è un testo, perchè per inserire ad esempio un punto la sintassi è questa:
INSERT INTO t ( p ) VALUES ( POINT(1 1) )
riguardo alla classe pgTypeItem, la proprietà Type ha un significato generico che identifica grossolanamente il tipo, diciamo che per definizione ho usato: C=carattere, N=numerico, B=binario; se il valore che tratta o che restituisce è un numerico, allora puoi impostarlo a "N". Ad ogni modo, nei driver per PostgreSQLx, esiste sempre lo stesso metodo di inizializzazione, e per postgres esistono oggetti simili (se non addirittura uguali) a quelli che hai segnalato per mysql; puoi dare un'occhiata da quelle parti... Comunque, il tipo al momento è solo informativo, e non ha utilizzi pratici nel programma.
- Devo mettere i nuovi tipi in ordine alfabetico mischiati con gli altri, oppure li metto tutti alla fine per raggrupparli? Sono 8.
guarda, puoi anche mandarmeli via email, o postare direttamente qui le righe di codice, è inutile che mi invii tutto il file, anche perchè comunque dovrei anallizarne prima le differenze, visto che comunque ci lavoro in modifica. Insomma, non ci sono problemi.
- Con Parameter ti riferisci ai parametri utilizzati per creare il campo, cioè in pratica le dimensioni?
anche questo è descrittivo, se vedi quelli già presenti, danno un'idea di come deve essere impostato un determinato tipo di campo, e quali dati accetta e restituisce; quelli che ho già inserito, li ho determinati leggendo la doc ufficiale di mysql, andando ad analizzare eventuali varianti, ma anche qui nessun problema, perchè al momento l'unica cosa cosa davvero utile a gDesigner è il nome del tipo, il resto al momento è tutta descrizione, anche se gli ho dato una parvenza di ordine e classificazione...
A parte le descrizioni ho lasciato tutti gli altri campi in bianco. La documentazione non fa cenno alla memoria occupata. In effetti, a parte POINT, sono tutte collezioni di oggetti e quindi immagino non sia calcolabile. Gli altri campi (massimo, minimo, risoluzione) non sono applicabili.
perfetto, se non esisono vincoli, non è necessario evidenziarli.
Riguardo alla tua idea, al momento mi sembra buona, e non vedo problemi nell'applicarla, tranne per il fatto che allora la proprietà type deve essere utilizzata e impostata in modo vincolante e restrittivo. In realtà, il creare una classe pgTypeItem solo per gestire i nomi dei tipi, non era nei miei intenti, e nel futuro pensavo di dargli un significato più incisivo nel programma; se hai tempo, puoi certamente provare ad implementare la tua idea, poi la vediamo insieme. :ok:
Si è probabile che i tipi siano gli stessi, credo ci sia uno standard che definisce queste cose.
In MySQL comunque funziona così: GEOMETRY è una classe astratta, poi sotto c'è una gerarchia di sottoclassi. Alcune classi sono istanziabili tramite un'apposita funzione, tipo POINT(x y), altre no perchè troppo generiche. A parte GEOMETRY, mi pare che tutte quelle utilizzabili come tipi siano istanziabili, ma non tutte le classi istanziabili sono usabili come tipi, perchè magari sono troppo specifiche. In realtà una volta che inizi a usarle capisci che è tutto perfettamente logico, anche forse non sembra.
Questo per dire che è difficile schematizzarle...
Ti copio qui quello che ho fatto
ME.AddDatatype(pgTypeItem.Create("GEOMETRY", "G", "", "", "", "", "", "Generic geometric object"))
ME.AddDatatype(pgTypeItem.Create("GEOMETRYCOLLECTION", "G", "", "", "", "", "", "Collection of geometric objects"))
ME.AddDatatype(pgTypeItem.Create("LINESTRING", "G", "", "", "", "", "", "Geometric line made of segments"))
ME.AddDatatype(pgTypeItem.Create("MULTILINESTRING", "G", "", "", "", "", "", "Collection of geometric linestrings"))
ME.AddDatatype(pgTypeItem.Create("MULTIPOLYGON", "G", "", "", "", "", "", "Collection of geometric polygons"))
ME.AddDatatype(pgTypeItem.Create("MULTIPOINT", "G", "", "", "", "", "", "Collection of geometric points"))
ME.AddDatatype(pgTypeItem.Create("POINT", "G", "", "", "", "", "", "Geometric 0-dimensional object"))
ME.AddDatatype(pgTypeItem.Create("POLYGON", "G", "", "", "", "", "", "Geometric polygon"))
POINT, per esempio, come per postgresql, accetta due valori (non ricordo se int o float), e il terzo parametro di pgTypeItem può essere usato per descrivere in maniera schematica come deve essere dichiarato il tipo, magari evidenziando i dati opzionali. Ti ricordo comunque che questo al momento viene usato solo nei tooltip, a meno che la tua idea di gestirlo nelle form alla fine venga applicata. Se dai un'occhio alle altre righe, vedrai che questo terzo dato è valorizzato.
Comunque, appena posso provvedo ad integrare il pezzo che hai inviato nel programma.
Thanks! :-)
Il fatto è che da come l'avevo capita io, i parametri erano quelli che si usano nelle CREATE TABLE... tipo:
CREATE TABLE ... nome CHAR(50) ...
insomma, in questo esempio il parametro che intendevo io sarebbe 50. Se è così, no, i tipi geometrici di MySQL non hanno parametri. Ma forse ho capito male? Perchè nella tua risposta mi sembra che ti riferisci ai parametri nel momento in cui crei il singolo oggetto, cioè appunto:
INSERT INTO .. (punto) VALUES (POINT(100 100))
Se ti riferisci a QUESTI parametri li posso inserire, però l'idea che ti avevo esposto non funziona più, perchè non c'entra con il contenuto del campo MySQLLength...
No, per parametri intendo quelli che definisci durante l'impostazione del tipo:
esempio:
dove, appunto, 50 è il parametro, inteso come valore di tipo Integer, ovvero, la stringa Type conterrebbe:
tra le due parentesi obbligatorie, "n" è un valore che deve essere passato per definire la dimensione del tipo CHAR().
Tutto qui, il discorso è più semplice di quello che ho maldestramente descritto nei precedenti post.
Comunque, ripeto, se dai un'occhiata alle altri definizioni, scoprirai che in fondo si tratta solo di descrivere la sintassi che deve essere applicata a quel tipo, null'altro... Se vedi nella documentazione ufficiale, vedrai che il discorso è identico, dopo inizialmente viene discritta la sintassi, con tutte le possibili varianti, poi sotto vengono descritti tutti gli elementi, il loro significato, e il loro uso sintattico.
Per chiarire meglio il concetto, prendo una delle righe del codice come esempio:
ME.AddDatatype(pgTypeItem.Create("CHAR", "C", "[(l)]", "", "", "", "", "Fixed-length character string"))
"CHAR" è il nome del tipo (usata poi nell'edit dei campi);
"C" identifica in modo generico quali tipi tratta (C=Character)
"[(l)]" dice il formato, comprese le varianti, che deve essere usato per la scrittura del tipo: in questo caso le parentesi quadre indicano che la sintassi che racchiudono è opzionale (ovvero si può scrivere anche solo CHAR), mentre le parentesi tonde indicano che se il tipo viene dichiarato di una certa lunghezza, la dimensione deve essere inclusa tra le due parentesi tonde, infine "l" stà ad indicare che l'unico dato che può essere passato a CHAR è un numero (l=lunghezza). Ovviamente "l" è un'etichetta che ho applicato io, ma non ha molta importanza, potrebbe anche essere nominata "n".
Poi ci sono alcune stringhe vuote, che corrispondono ad altrettanti dati da passare a pgTypeItem, ma per "CHAR" non sono valorizzati.
L'ultima stringa contiene una descrizione sommaria del tipo "CHAR", ovvero che tipo di dati definisce e magari quale dimensione di memoria occupa (es, nel caso di Integer, potrebbe essere 8Bit).
Spero che ora sia riuscito a descrivere in maniera più chiara.
Riguardo "POINT", questo tipo potrebbe essere definito con due parametr, es. x e y; in questo caso il terzo valore da passare a pgTypeItem sarà:
"[(x,y)]"
oppure:
"[(x[,y])]"
nel caso sia permesso passargli solo il primo, e il secondo è opzionale...
BUILD: 645
Modifiche:
- corretti alcuni metodi nei driver MySQL e SQLite
- corrette alcuni metodi per la lettura e la creazione dei database SQLite;
- corrette alcuni metodi per la lettura e la scrittura dei file progetto per MySQL e SQLite
- alcune modifiche e correzioni nelle classi relative alle procedure di import/export
- al momento non è possibile determinare le relazioni per MySQL e SQLite
- al momento non è possibile determinare il valore per Check da database MySQL
- al momento non è possibile determinare le impostazioni di Unsigned, ZeroFill e Binary da database MySQL
- alcune modifiche nelle finestre di edit per Campi e Indici
Attenzione:
- le modifiche effettuate rendono illegibili i precedenti file progetto.
Ah, allora avevo capito... ma in fase di creazione del campo, non ci sono parametri. Un campo geometrico ha lunghezza variabile e non c'è modo di influenzare questo fattore. Tra l'altro io ne ho fatto un uso abbastanza banale e non ci capisco molto, ma se uno usa questi tipi ad alti livelli è meglio che usi Postgresql, perchè MySQL fa dei calcoli abbastanza limitati.
Purtroppo ho avuto meno tempo di quello che credevo ma non ti sto paccando, la mia proposta di codice arriverà presto!
Non c'è problema... tanto non ti pago lo stesso... :-)
Trovato un bel problemino!
SELECT specific_name
, routine_catalog
, routine_schema
, routine_name
, routine_type
, dtd_identifier
, routine_body
, routine_definition
, external_name
, external_language
, parameter_style
, is_deterministic
, sql_data_access
, sql_path
, security_type
, created
, last_altered
, sql_mode
, routine_comment
, definer
FROM information_schema.routines;
La select serve per estrarre tutte le informazioni relative ad una FUNCTION o una PROCEDURE da MySQL.
Eseguendo il comando sql da qualsiasi client per MySQL, ritorna correttamente tutti i dati, ma lo stesso comando eseguito tramite le funzioni di Gambas, con risultato ritornato in un Result object, non dà gli stessi risultati; nel particolare, il campo "routine_definition" che dovrebbe contenere la definzione sql della funzione mysql, in Gambas dà come risultato una stringa vuota, per cui in pgDesigner non è possibile gestire questo dato.
Analizzando la cosa ho notato che MySQL definisce questo campo come tipo "longtext", e Gambas come tipo String. La cosa sembrerebbe non comportare problemi, ma a quanto pare Gambas agisce in modo anomalo; la cosa strana è che anche il campo "sql_mode" è dello stesso tipo, ma non presenta lo stesso problema.
Il tipo "longtext", a quanto pare, MySQL lo usa per stringhe di testo piuttosto grandi, e potrebbe anche creare problemi di conversione se questo tipo contiene oltre la dimensione massima supportata da gambas per i suoi oggetti String; ma nei miei test, al momento non ho valori così grandi, per cui il comportamento mi pare alquanto anomalo.
Proverò a comunicare questa cosa anche al team di Gambas, ma se qualcuno ha qualche idea me lo faccia sapere.
Oltre a chiedere lumi a Benoit, ho fatto ulteriori prove e letto anche un pò di doc dal sito ufficiale.
In effetti, nella doc, negli esempi di connessione a MySQL, si consiglia (o dichiara? non ho ben capito...) di creare un modulo ad-hoc (invece di una classe? Bho?).
Nei miei test, ho infatti creato un piccolo modulo, dove ho fatto un pò di prove di connessione e utilizzo di MySQL, e le stesse query hanno funzionato come dovevano, ritornando tutti i dati che mi aspettavo, e in modo completo.
A questo punto, dopo aver letto la nota presente nella doc, ho provato testardamente a creare invece una piccola classe, derivata sempre da Connection, limitata a solo alcune funzionalità di quelle presenti in pgDesigner; a quanto pare la cosa continua a funzionare correttamente...
Il mio dubbio, che ho espresso anche nella mail a Benoit, è che ci sia un qualche problema nella classe Connection, che si presenta quando viene utilizzata come classe base per ulteriori oggetti; il problema, però, si identifica solo su un certo tipo di informazione (longtext) e solo con MySQL.
In PostgreSQL di test ne sono stati effettuati molti, e da circa due anni da quando è nato pgDesigner, senza problemi di questo tipo; in quanto a SQLite, le uniche sue limitazioni finora, sono il fatto di non essere un verso server, e di non possedere funzionalità attive per determinare in modo non arzigogolato le informazioni contenute nel file di database.
Bè, la cosa mi ha costretto a rivedere molta della logica degli oggetti che ho utilizzato in pgDesigner2, per cui toccherà lavorarci un pò su...
Quanto tempo che non scrivo qui...
Hai provato a usare SHOW CREATE FUNCTION nomefunzione / SHOW CREATE PROCEDURE nomeprocedura per ottenere la definizione SQL? Forse è una soluzione molto "sporca", ma io te lo dico, poi giudicherai tu...
Altra cosa, hai provato a cambiare i flag della connessione? (connessione compressa per esempio) Non so come funzioni in Gambas, se vuoi ti mando un esempio in Php, suppongo sia molto simile..
Invia pure, provo a vedere se mi viene qualche idea.
In realtà ho scoperto che esiste un problema con il diver MySQL di Gambas2, in quanto ora ho creato una classe che gestisce la connessione, e utilizzandola da un semplice programma di test tutto funziona, ma se la chiamo dalle funzioni di pgDesigner, ritorna tutto tranne il campo incriminato. Sembra come se esistesse un qualche problema nella gestione dinamica della memoria, per cui si perde qualcosa nel tragitto; e la cosa mi stà facendo imbestialire non poco... Questo finora è l'unico problema che mi impedisce di andare avanti, perchè mi stà facendo perdere tempo.
Ora, insieme alla riscrittura della logica di connessione, ho implementato una sorta di gestione, che mi ritorna una struttura dati da una query; in questo modo apro e chiudo la connessione ogni volta che eseguo una query, e questo mi permette di manipolare i dati senza tenere per forza aperta la connessione. L'oggetto Result resta valido solo con connessione aperta, e se viene chiusa, l'oggetto Result diventa invalido, per cui inutilizzabile...
Nonostante questa modifica, il risultato non cambia; già inserendo una PRINT del campo appena dopo la lettura, il valore che ritorna è NULL.
Il tuo suggerimento di usare quella sintassi brutale potrebbe essere valido, ma và un pò fuori della logica del programma. Sia per PostgreSQL che er SQLite, rilevo le info direttamente dal database, con query mirate. QUel tipo di sintassi potrebbe cambiare risultato nel tempo, dipendentemente dalla versione, per cui vorrei evitare di utilizzarla.
Ora che ci penso, anche l'idea della connessione flaggata, non credo risolva il problema, che penso più legato ad un problema interno Gambas. Ad ogni proverò anche questa strada.
Ho provato ad inviare un paio di mail a Benoit, ma ancora non avuto risposte...
Beh, se vuoi provare in Php si fa così:
$con = mysqli_init();
//options to set
$con->options(MYSQLI_OPT_CONNECT_TIMEOUT, TIMEOUT);
$con->options(MYSQLI_READ_DEFAULT_FILE, OPTIONS_FILE);
$con->options(MYSQLI_READ_DEFAULT_GROUP, OPTIONS_GROUP);
$con->options(MYSQLI_OPT_LOCAL_INFILE, false);
// options to set (flags)
if (USE_COMPRESSION)
$flags = MYSQLI_CLIENT_COMPRESS;
else
$flags = 0;
// connection
@$con->real_connect(HOST, USER, PASS, 'mysql', PORT, SOCK, $flags);
Spero che la sintassi sia simile in tutti i linguaggi. mysqli_init() restituisce un oggetto connection. In Php conviene usare quella funzione invece di $con = new mysqli() perchè altrimenti non puoi... ehm... non mi ricordo cosa non puoi fare, ma ci deve essere una qualche funzione o parametro che non funziona.
Un altro suggerimento veramente idiota: hai provato a cambiare l'ordine dei campi nella SELECT o a usare degli alias? Non dovrebbe cambiare nulla, ma chissà... io quando non capisco un bug provo anche le soluzioni più stupide, e ti posso testimoniare che una volta su mille funziona. :-)
Ti ringrazio per il codice, uso anche io php, ma in Gambas non esiste un parametro del genere, almeno per quanto ne sò...
Ad ogni modo, riguardo i tentativi, il problema non è farli, infatti ho capito che il problema è solo nella librery di Gambas, e solo riguardo MySQL, e molto probabilmente c'è qualcosa che crea problemi in una situazione dinamica, come ho scritto nel precedente post.
Inoltre la cosa coinvolge esclusivamente i campi di tipo "longtext", e questo mi fà pensare che proprio per la natura altamente dinamica di questo tipo di campo, possa incidere nel problema riscontrato.
In tutti i casi, gli altri campi vengono letti correttamente, ad indicare proprio che è presente qualcosa che si incasina solo con i longtext.
In postgresql, come del resto anche in Oracle e altri dbms, esistono i VARCHAR, tipi di campo a dimensione variabile, che però gambas comprende molto bene, e non ho riscontrato finora problemi nella lettura.
Riguardo ai longtext di mysql, ho notato che Gambas ne definisce una lunghezza di circa 500Kb, sia che contengano dati, sia che siano vuoti. E' probabile che la dimensione (il valore a dir la verità è un numero abbastanza anomalo, puoi provare con l'oggetto Result...) sia rispondente alla realtà, ovvero alla dimensione realmente stabilita da Mysql, ma non l'ho riscontrata nella doc ufficiale.
Questa cosa però mi fà pensare ad un'altro problema, anch'esso non riscontrabile dalla doc, ovvero qual'è la dimensione massima di un'oggetto String in Gambas. Se mettiamo il caso di avere un longtext completamente pieno, e di volerlo caricare in una String di Gambas, ci si riesce a farlo? Oppure tocca inventarsi qualche algoritmo di lettura? A quanto ne sò nell'oggetto Field di gambas, le stringhe sono contenute in un'oggetto interno di tipo String, sarà vero?
Stò pensando di analizzare il codice sorgente di Gambas, per vedere se trovo qualche problema. Il codice in C non è un problema, in quanto è il mio linguaggio primario, ma non essendoci doc a rigurdo la cosa sarà un pò dolorosa...
Speriamo di trovare qualcosa...
Ad ogni modo, in contemporanea, stò sistemando anche il codice di pgDesigner, per cui non mi sono fermato a questo problema...
Anche in MySQL c'è il VARCHAR, che non ha limiti di lunghezza (il limite è quello dettato dalla lunghezza massima delle righe, che è 65535). Strano che Gambas fissi il LONGTEXT a 500 bytes, non credo che MySQL faccia una cosa del genere...
Lo stesso bug si riscontra con i LONGBLOB?
Forse ho scritto male: sono circa 500Kbyte, ovvero mezzo mega!
Riguardo a Gambas, vede il campo NON come un blog (altrimenti c'è una classe specifica) ma come String.
In effetti, seppur longtext sia da considerare un tipo BLOB, è anche vero che contiene testo, per cui mi pare giusta la conversione.
Il bello è che nel codice sorgente, questo tipo di campi sembra essere trattato come BLOB, ma poi, non si sà perchè, Gambas restituisce un tipo 9 (String).
Ma, come ho già scritto, il problema non è la diretta conversione del campo, tanto è vero che in un semplice test sembra funzionare, bensì il comportamento anomalo in un'applicazione più complessa, e quindi di maggiori dimensioni.
Ormai le ho provate tutte, e più di verificarne il comportamento, controllando direttamente l'oggetto Result, non sò che altro provare.
Io sono convinto che il problema risieda su qualche anomalia in memoria, ma non riesco a trovare punti nel codice sorgente che mi possano aiutare ad indentificare dove...
La query è sicuramente corretta, l'oggetto si comporta come deve (test minimo), per cui il problema è in gambas. Se avessi scritto due procedure diverse, con comportamenti diversi, sicuramente sarebbe colpa di qualcosa nel mio codice, ma non è così. Gli elementi sono gli stessi, ma il corpo è diverso, per cui diversa gestione in memoria...
I longblob non mi interessano, perchè nel repository del database mysql non vengono usati da nessuna parte, e poi non sono oggetto, o fanno parte, dello scopo di pgDesigner. Se creo un progetto con questi elementi, questi vengono creati correttamente nel db, anche perchè non passo per oggetti Gambas, e uso solo il metodo Exec() dell'oggetto Database. Inoltre, anche questo tipo di dato passa per strade diverse nel codice sorgente, per cui è probabile che si comporti in egual modo; ma, ad ogni modo, non lo utilizzo perchè non esistono campi di quel tipo nelle mie query.
Mi piacerebbe che Benoit rispondesse alle mie email, ma finora nulla...
Ti ringrazio moltissimo per l'aiuto, anche se non se ne esce...! :amici:
Capisco. E' passato un po' di tempo, sei riuscito a risolvere il problema?
No, però mi sono rassicurato sul fatto che il problema non un errore nel codice di pgDesigner. Stò attendendo risposta da Benoit (o una parolaccia...)...
Ad ogni modo, nel frattempo, o fatto parecchie modifiche e molti rivoluzionamenti nel codice, cercando anche di sistemare il più possibile gli errori; dato che poi la nuova logica di connessione mi è piaciuta, questo mi ha però costretto a rivedere molte cose, ma ora mi sembra molto meglio.
Ieri sera mi sono accorto che alcune nuove modifiche hanno rallentato un pò le procedure di I/O su file, e ora stò cercando di ottimizzarle.
Non ho ancora pubblicato la nuova release di test, perchè mi sono appunto concentrato sulle molte modifiche, e non era il caso di proporre una versione se poi la sconvolgevo completamente... :-)
Tra le variazioni più importanti c'è stata pure quella di costruire una sorta di libreria, sovrascrivendo tutte le funzioni di Gambas utilizzate nel programma; questo per concentrare le variazioni in un solo punto, e anche e soprattutto per controllare meglio tutto quello che riguarda le stringhe (ASCII-UTF8) e personalizzare le funzioni ad-hoc per il programma, rendendole più specializzate.
Una volta sistemate le cose, vedrò di mettere a disposizione la nuova versione.
Ciao!!!
Nuova release alpha di pgDesigner2.
Ho fatto parecchi cambiamenti nel codice, e nelle configurazioni
In particolare, ho aggiunto ulteriori controlli sul caricamento del file di configurazione dell'applicazione e dei file di progetto, per cui è necessario eseguire alcuni passi, per ricuperare i vecchi progetti:
Progetti su file XML: aprire il file con un editor e aggiungere le seguenti informazioni nel tag principale (seconda riga, sotto la testata xml), come da esempio la riga deve apparire:
Progetti su file INI: aprire il file con un editor, cercare il tag "[pgDesigner2]" e aggiungere le seguenti informazioni sotto il tag, come da esempio la riga deve apparire:
[pgDesigner2]
Type="Project"
Version="2.0.0"
Cancellare il file di configurazione presente nella HOME directory:
# rm $HOME/.pgdesigner2/pgdesigner2.conf
FARE ATTENZIONE A NON ELIMINARE ALTRI FILE !!!
Al momento non ho ancora risolto un paio di problemi con il driver Gambas per MySQL, mentre per SQLite ho dovuto implementare una chiamata diretta al programma "sqlite3" da sistema operativo, per poter determinare in modo corretto (anche se non ancora completamente) le impostazioni dei campi di tabella.
Purtroppo per MySQL non ho ancora avuto risposte da Benoit, e per SQLite, data l'assenza di funzioni specifiche e di tabelle adatte al rilevamento della struttura dei database, ho dovuto prendere alcuni provvedimenti non proprio, a mio avviso, molto puliti. Mi sono documentato molto su SQLite, ma trovo molto complicato gestirne la struttura, in assenza di utility specifiche (al contrario di MySQL e PostgreSQL). Inoltre, la lagica con cui internamente definisce i singoli campi di una tabella, mi pare alquanto azzardata e soggetta a possibili incongruenze.
Ad ogni modo, stò facendo tutto il possibile per gestirli.
Nota: questa versione non è esente da bachi... :-)
E' possibile che alcune cose che funzionavano in un certo modo prima, ora sono cambiate; la struttura delle classi è cambiata molto, e l'ho fatto anche per rendere l'idea, a chi legge i sorgenti, di cosa si possa fare in Gambas2.
...intanto io procedo nello sviluppo...
Bye
ehi ma i bachi ci devono essere sempre sennò se le cose vanno bene la gente si annoia ad usare linux e passa a winzozz!!! :-D
Una specie come il formaggio sardo, con i bachi è più buono... :-)
Scherzi a parte, spero che anche le singole parti e alcune soluzioni che ho applicato al programma possano essere anche d'aiuto per capire Gambas.
Per il momento gli unici problemi riscontrati sono relativi ad alcuni buchetti di Gambas2, cosa che mi ha confermato Benoit.
Altra versione ALPHA!
Ho fatto svariate modifiche, e sistemato altrettante cose, anche se non si vedono a livello di uso. Una delle cose che ho fatto, è stata quella di distribuire in modo più congruo tutte le funzioni e le classi statiche, raggruppandole anche in una sorta di schema logico. Chi leggerà il codice, vedrà anche una replica delle funzioni base di Gambas, che ho adattato in classi statiche, e che ho modificato per rispondere correttamente ad alcune funzioni interne di pgDesigner. Lo scopo principale di questa cosa, è quello di concentrare il più possibile le chiamate in punti nevralgici, in modo da rendere più semplice (apparentemente) eventuali modifiche.
Ad ogni, faccio un riassunto degli aggiornamenti in questa release:
- # NEW: Aggiunta la possibilità di esportare il progetto su file CSV.
- # NEW: Aggiunta una finestra di dialogo, contenente alcune utility, tra cui: la visualizzazione della configurazione corrente, l'elenco dei progetti aperti e relative configurazioni, la codifica/decodifica usata per salvare/leggere i dati codificati dai file di progetto. Quest'ultima è utile per la correzione manuale dei dati nei file progetto.
- # UPD: La lingua di default viene ora determinata dalla impostazione di sistema, o dal parametro LANG; la finestra di selezione della lingua viene visualizzata solo se risulta impossibile determinare queste condizioni.
- # UPD: Aggiunta la lettura da database della definizione UNIQUE per gli indici in SQLite.
- # UPD: Miglioramenti nelle funzioni HTML.
- # UPD: Il modulo di lancio dell'applicazione è stato modificato. All'avvio l'applicazione viene impostata automaticamente con il linguaggio di sistema, se presente, altrimenti verrà visualizzata la finestra di configurazione. Sono previsti due tipi di parametro: "LANG=", seguito dall'identificativo di lingua (es. "it_IT.UTF-8"), con cui è possibile definire da riga di comando la lingua corrente (in caso di errore, o incongruenza, verrà impostata la lingua di default); "FILE=", seguito dal nome del file progetto (path compresa, e tutto senza spazi in mezzo), che sostituisce la precedente logica di caricamento automatico dei file di progetto (questo parametro può essere definito più volte a riga di comando, per ogni file che si desidera caricare alla partenza del programma).
- # UPD: Aggiornamento delle traduzioni. Nel tempo libero, ho cercato di procedere nelle traduzioni dei testi, nelle lingue che erano previste dalla vecchia versione, ma questa sarà sempre una cosa che necessiterà di interventi da chi conosce le lingue meglio di me e del traduttore software che stò usando... (spero che qualcuno recepisca il messaggio...)
- # UPD: Le procedure di report sono state aggiornate e migliorate (questo comprende anche il nuovo CVS).
- # UPD: Le procedure di lettura/scrittura dei file progetto sono state aggiornate e migliorate.
- # UPD: La procedura di conversione dei file progetto è stata aggiornata e corretta (...forse...).
- # UPD: A causa di alcune implementazioni nella libreria xml di Gambas (in effetti, dopo aver capito che la libreria ha dei problemi con certe strutture...), i file progetto sono stati modificati. E' opportuno, quindi, eseguire la procedura di conversione dei progetti, presente nel menù Strumenti. Pro divulgazione: la logica attuale con cui è stata costruita la libreria gb.xml, al momento non riesce a capire la chiusura dei tag, se questa viene fatta subito dopo la dichiarazione di eventuali attributi (es. ), per cui è necessario che la costruzione di file xml avvenga in questo modo: ; lo spacchettamento del tag provoca la comparsa di un item "#text", che corrisponde all'eventuale testo che compare tra l'apertura e la chiusura del tag.
- # UPD: Le funzioni di disegno degli oggetti sono state riorganizzate e migliorate. Chissà, forse un giorno gestirò tutto in OpenGL...
- # NDA: A causa della difficoltà, con SQLite, di determinare completamente la struttura dei campi di tabella, nel driver è stata utilizzata una shell al programma "sqlite" (o "sqlite3" per la versione 3). Sulla base di questa modifica, è necessario che per l'accesso ai database SQLite, sul sistema sia presente questa utility, che di norma viene installata da tutte le distribuzioni Linux.
- # NDA: A causa di un problema, di cui non si è ancora appreso il motivo, il caricamento in MySQL, delle informazioni riguardanti i campi di tabella di tipo "longtext", può essere effettuato solo tramire utente "root"; con altri utenti, il contenuto stranamente non viene caricato... In pratica, il problema che mi aveva assillato in questo periodo, non era causato da Gambas, bensì da MySQL; spero di avere un riscontro positivo ...
- # NDA: Programma compilato con la versione 2.10.2 di Gambas (ultimissima!). In realtà le modifiche delle ultime 2/3 versione, non hanno condizionato il programma, per cui credo che sia sufficiente ricompilarlo.
P.S.: attendo sempre qualche volontario che si faccia avanti per aiutarmi... :-)
Ciao!
In questa versione ci sono molte altre modifiche e implementazioni, tra cui anche un nuovo set di icone (spero siano gradite...).
Come ho detto a leo, qualche giorno fà, ho ritenuto opportuno continuare ad inserire il progetto su SourceForge.net, anche perchè questo dà modo al programma, di essere visto da più persone, anche al di fuori dell'ambito Gambas; oltre a ciò, è quanto mai necessario un maggior numero di contributi, anche dal lato traduzioni.
Comunque, continuerò comunque a pubblicare anche su questo sito le nuove versioni, contemporaneamente agli aggiornamenti su sf.net, o quasi; il "quasi" stà nel fatto che ho attivato anche il repository Subversion, che sf.net mette a disposizione per i sorgenti, e questo mi permette di avere un colloquio più idoneo con eventuali contributori.
L'invio al partecipare al progetto è sempre valido!
Ciao a tutti.
Non riesco a decomprimerlo, mi da questo errore:
:~$ tar xvfj pgDesigner2-2.0.0-alpha-659.tar.bz2
tar: Questo non sembra un archivio tar
tar: Salto alla prossima intestazione
tar: Uscita per errore ritardata dall'errore precedente
Il file è un .bz, per cui devi usare:
1) uno dei programmi di compressione, presenti nel menu del tuo desktop, che riconosce questo tipo di file
oppure
2) dare il comando "bunzip2 ", che ti estrae il tar contenuto, e poi il tar come l'hai fatto tu.
Tutto ok. Grazie
Nuova versione ALPHA.
Ciao
In questa versione ho inserito lo Zoom, ovvero la possibilità di rimpicciolire o ingrandire la visualizzazione del diagramma del progetto.
Data la possibilità di avere diagrammi di dimensioni abbastanza grandi, ho ridotto le combinazioni di zoom: 400%, 200%, 100%, 50% e 25%.
Su questa nuova funzionalità ci stò ancora lavorando, per correggere eventuali incongruenze, per cui è possibile che in alcuni casi possa non funzionare a dovere; ad ogni modo, è sempre possibile ripristinare la risoluzione al 100%, per rimettere le cose a posto (il default).
La logica usata è abbastanza complessa, dato che l'interattività (ovvero la possibilità di selezionare e muovere oggetti) resta comunque valida in tutte le risoluzioni di zoom. Per far questo ho docuto implementare un nuova classe, per la conversione delle coordinate, da virtuali a reali, e viceversa, mantenendo comunque la posizione e le dimensioni reali di ogni singolo oggetto, che poi vengono memorizzate nel file del progetto.
Nella finestra delle opzioni generali, ho inserito la possibilità di definire un fattore di zoom di default, salvato nel file di configurazione e applicato immediatamente alla partenza del programma, su ogni progetto che viene creato o aperto da un file esistente.
Ovviamente, la velocità di ridisegno del diagramma varia dipendentemente dalle dimensioni del diagramma stesso ovvero, se si seleziona uno zoom con fattore 400%, il grafico impiegherà diversi secondi prima di presentare un diagramma stabile; altresì, se si sceglie un fattore 25%, la velocità verrà enormemente incrementata ma, la leggibilità del diagramma sarà di conseguenza minore.
L'utilità di questa nuova funzionalità, è di poter vedere l'intero diagramma all'interno dell'area di scroll visibile, e poter avere una visione più generale del progetto.
La funzione di zoom è collegata al singolo display (o schema), per cui è possibile definire diversi zoom per tutti i display delo progetto, e anche tra i vari progetti aperti.
Al momento non ho previsto la memorizzazione dello stato dello zoom sui file di progetto, per cui al successivo caricamento, verranno tutti ripristinati al valore di default.
Nota: per motivi di spazio e di obsolescenza, ho eliminato tutte le precedenti versioni alpha, sollevando leo da questo ingrato compito... :-)
Ciao
Alcune correzioni, alcune introdotte nella precedente versione.
Ciao
NOTA per chi stà utilizzando il programma nella versione ALPHA !!!
Attualmente stò ristrutturando il formato dei file di progetto, riscrivendo anche le funzioni di lettura e scrittura; le modifiche apportate rendono completamente incompatibili i formati precedenti (sempre riguardo le ALPHA...). La cosa è però diversa nel caso dei progetti delle versioni pubblicate fino alla 1.2.8, per le quali avevo già creato delle procedure di conversione, anche queste adattate alla nuova struttura.
Le modifiche riguardano tutti e due i formati (INI e XML) !!!
Al momento ci stò ancora lavorando, per cui la nuova versione sarà disponibile appena testato il tutto.
Bye
- # NEW: Durante l'importazione delle informazioni dal database, è possibile
- # visualizzare il contenuto di una tabella tramite il pulsante
- # Visualizza, nell'elenco degli oggetti da importare. Per evitare di
- # caricare eccessivamente la funzione, il numero è limitato a 20 record.
- # UPD: Alcuni aggiornamenti nelle traduzioni.
- # UPD: Nella finestra delle statistiche di progetto è stato implementato
- # l'ordinamento delle colonne delle liste. L'effetto viene attivato
- # selezionando la testata della singola colonna che, alternativamente,
- # visualizza l'elenco in ordine ascendente o discendente.
- # UPD: Riscritte le funzioni di scrittura/lettura dei file progetto; la nuova
- # struttura è incompatibile con le versioni di sviluppo precedenti. Sono
- # state anche riscritte le funzioni di conversione dei progetti fino
- # alla versione pgDesigner 1.2.8.
- # UPD: Aggiornati il logo e le icone dell'applicazione.
- # BUG: Corretti alcuni errori nelle procedure di report.
- # BUG: Corretti alcuni errori nella procedura di creazione dei file
- # sql e nella finestra di dialogo per le esportazioni.
- # BUG: Corretto l'errore che si verificava cliccando con il mouse nel
- # grafico.
- # BUG: Corretto un problema nel caricamento degli oggetti da database.
- # BUG: Corretti alcuni errori minori nel disegno degli oggetti.
- # NDA: Programma compilato con la versione 2.11.1 di Gambas.
Nota: sono ancora da sistemare le funzioni di conversione dei vecchi file progetto.
Scusami ma visto che ormai il tuo progetto ha raggiunto una certa importanza non puoi crearti una pagina wiki?
Chiedevo così...
In che senso?
:eh:
In questa versione dovrei aver sistemato le procedure di conversione dei vecchi progetti pgDesigner 1.x
Ciao
Altra release...
Putroppo ho fatto qualche piccola modifica al file di configurazione e ai file di progetto. Per i primi è necessario eliminare i vecchio file di configurazione, in modo che all'avvio dell'applicazione questo venga ricreato con le corretta configurazione; per i secondi, la modifica è molto semplice, perchè è sufficiente aprire i file progetto creati con versioni alpha precedenti, e modificare un tag inserendo la stringa corretta. In tutti i casi la relazione è descritta nel ChangeLog, includo nel package.
Altre modifiche, sono state fatte relativamente alla configurazione della stampante, e delle impostazioni da configurare per le stampe. In particolare ho aggiunto tre nuove impostazioni (che comunque erano già presenti nel file di configurazione), utili per configurare la stampante a livello globale.
Come ultima cosa, ho aggiunto una nuova cartella nella finestra delle Utilità, che visualizza alcuni dati del sistema: kernel, hardware, ecc. La cosa non è sicuramente necessaria al funzionamento dell'applicazione, ma è un esempio che dimostra alcune funzionalità create con Gambas, e può essere utile a chi inizia da poco con questo linguaggio. Ho creato la classe statica pgSysInfo, che, insieme a pgSys, fornisce un pacchetto di queste utili funzioni.
Nota: al momento stò aggiornando in modo quasi costante le traduzioni in Italiano e in Inglese; il resto delle lingue previste è al momento in stato di sospensione, perchè porta via molto tempo, e non ho la possibilità e le conoscenze per poter provvedere al loro mantenimento. In questo frangente, se qualcuno ha le conoscenze adatte, e la possibilità di farlo, farebbe un piacere alla comunità tutta; è da tener conto che, allo stato attuale, l'ultima versione di pgDesigner (1.2.8) conta un numero superiore ai 1400 utenti, sparsi in giro per il mondo. In alcuni casi ho ricevuto una collaborazione a livello linguistico, ma la cosa è alquanto altalenante, per cui sarebbe gradita una forma di collaborazione continua da parte di qualcuno.
Ciao a tutti!
Solo alcune note...
Il lavoro per la nuova release procede, anche se a rilento dato che in questo periodo ho un bel pò di casini.
Attualmente stò cercando di fare pulizia ed ottimizzare il più possibile il codice, ed è un lavoro piutosto pesantuccio.
Dato il poco tempo a disposizione, spesso non aggiorno gambas-it con l'ultimissima versione, cosa che però faccio con una certa regolarità, tramite svn, su sourceforge.net, ma il mio obbiettivo, che cerco di tenere sempre valido, è quello di pubblicare anche qui le versioni che reputo valide e abbastanza funzionanti.
Non sò se qualcuno di voi ha avuto modo di provare l'applicazione, fino ad oggi non ho avuto alcun riscontro; mi piacerebbe comunque sapere se il progetto è gradito, in particolare le funzionalità e l'interfaccia.
Rivoluzionato molto il codice, e qualche modifica qua e là...
Altra versione...
Fatte altre modifiche al codice, e qualche rivoluzionamento qua e là...
Alcuni miglioramenti, e qualche aggiustatina a funzioni non proprio funzionanti al 100%.
Mi farebbe molto comodo che qualcuno mi aiuti a testare il programma; al momento è già abbastanza stabile, ma ho bisogno di avere altri pareri oltre il mio...
Bye
Altri rivoluzionamenti del codice, compresa la ricerca di un modo per velocizzare la gestione dei diagrammi, per ovviare alla incomprensibile lentezza della libreria e della classe Draw.
Inoltre ho aggiunto il supporto iniziale alla prox versione 8.4 di PostgreSQL.
Bye
pgDesigner2-alpha-build694.tar.bz2 (eliminato)
Durante il tempo in cui sono stato fuori da questo sito, ho continuato, anche se saltuariamente, lo sviluppo di pgDesigner2.
Granzie anche ad alcune collaborazioni estere nei test, sono anche riuscito a mettere a posto molte cosette, e a migliorare e aggiungerne altre.
Al momento non voglio inserite i sorgenti correnti, perchè a breve farò un nuovo rilascio, e non voglio intasare la rete con upload inutili.
Ad ogni modo, per chi volesse scaricare l'ultima versione, c'è sempre il repository di sourceforge.net.
Ricordo anche che il vecchio pgDesigner è sempre attivo, e in continuo aggiornamento, parallelamente a quello nuovo. Oggi, per l'appunto, ho rilasciato una nuova release, con correzioni di alcuni bachetti.
Bye bye...
Luigi
Segnalo l'indirizzo corretto del repository di sviluppo di pgDesigner2:
https://pgdesigner.svn.sourceforge.net/svnroot/pgdesigner/pgdesigner/branches/2.0-alpha (https://pgdesigner.svn.sourceforge.net/svnroot/pgdesigner/pgdesigner/branches/2.0-alpha)
Dato il continuo sviluppo dell'applicazione, e il poco tempo a mia disposizione, il mantenere più posizioni dove allocare i sorgenti sia alquanto oneroso. Spero che leo mi possa perdonare. :-)
Ricordo che l'indirizzo che ho segnalato può essere usato con SVN, per scaricare il blocco dei sorgenti, tramite il comando:
svn co https://pgdesigner.svn.sourceforge.net/svnroot/pgdesigner/pgdesigner/branches/2.0-alpha
basta posizionarsi prima su una directory appropriata sul proprio sistema, ed eseguire da console il comando. In alternativa esistono programmi grafici che fanno l'identica operazione (vedi kdesvn o RapidSVN).
Con l'occasione invio un grande ringraziamento a Florent Thomas (Francia), che mi stà dando una grossa mano nei test, e per i molti consigli relativi all'aspetto grafico e funzionale del programma. Inoltre sono molto felice perchè lo usa per le sue attività lavorative.
P.S.: tanto per farvi un'idea dello stato raggiunto, date un'occhiata all'immagine in allegato.
Un saluto a tutti!
Ciao amico mi piacerebbe molto aiutarti ma già io con i miei software sono in grave ritardo. Ultimamente sto rimettendo mano al mio software Diet visto che sono ingrassato! Ho sempre il problema dei grafici.
Grazie lo stesso per il pensiero! :2birre:
Purtroppo è difficile avere collaborazione, in particolare se il progetto non è stato creato in collaborazione già inizialmente. Nel tempo ho avuto qualche appoggio, ma in genere più sulle traduzioni, cosa che mi ha aiutato molto, visto che porta via molto tempo, oltre al non conoscenza delle lingue.
Ultimamente sono in contatto con un francese, che lo usa per lavoro, e mi aiuta molto nei test, mi trova i bachi, e mi fornisce anche idee utili per migliorare sia l'aspetto che le modalità di utilizzo.
Purtroppo al momento è l'unico...
Questo msg solo per aggiornare questo povero thread che ho lasciato un pò abbandonato da tempo.
Ma anche per far presente che, in ogni caso, stò portando avanti lo sviluppo di pgDesigner, nella versione 2.0.0, ma che a tutt'oggi non ho ancora reso pubblica.
Sono, comunque, a disposizione i sorgenti che periodicamente aggiorno sul repository di sourceforge.
Bye a todos :-*
grazie x l'info
Quando creo un nuovo progetto il software si blocca con un Invalid Object alla riga 1435 di CApp.Class
Mi dice che c'è un NEW insaspettato.
Parlo della versione sorgenti tar.gz....
Ho Gambas 2.21 da repo, GNOME, Debian Squeeze
EDIT Ho risolto scaricando con svn la versione in sviluppo
pgdes è un grandissimo pezzo di softw e dal suo codice possiamo solo che imparare, grazie di cuore luigi
Ragazzi,
lo sviluppo di pgDesigner2 si era rallentato di molto a causa anche delle vicissitudini di questo periodo, ma anche perchè credo che ormai sia bello che terminato (in verità non lo è e non lo sarà mai...).
Prima o poi, appena ho chiare le idee, pubblicherò ufficialmente la nuova versione...
...solo un aggiornamento...
Ciao md,
vorri usare pgdesigner2 per progettare un piccolo db Pgsql, ho però riscontrato i seguenti problemi:
1. creato un nuovo progetto in fase di creazione tabelle risulta impossibile selezionare il tipo di campo poichè il combobox corrispondente risulta non popolato. Vedi fig. tipo_campo.png
2. Tentando di salvare il file progetto ricevo l'errore Malformed URL file:///home/emanuele. vedi figura save_error.png. (questo mi succede anche con pgd 1.2.18)
Ubuntu 10.10 X86_64
Gnome / GTK
Gambas 2.22
Emanuele
Ciao sotema,
credo che le due anomalie siano causate dallo stesso problema.
Dovresti dirmi se e come sono impostate le variabili di ambiente, in particolare LANG e/o LANGUAGE. Magari se mi posti il risultato del comando "env" (da terminale), faccio qualche controllo...
Problemi di questo tipo possono dipendere sia dalle variabili di ambiente, sia dalla mancanza di tutte le librerie necessarie, di Gambas2 e affini.
In particolare, riguardo il formato dei file, che sono in pratica degli XML, dipendono dalla configurazione dell'ambiente, ovvero del sistema operativo. Problemi del genere si sono verificati proprio per questo motivo e, nonostante abbia inserito dei controlli all'interno di pgDesigner, in alcuni casi non si riesce a risolverli.
Riguardo pgDesigner2, ho ottimizzato alcune cosette riguardo questo problema, ma ci sono ancora cose che sfuggono al controllo. Alcune funzioni di Gambas2, non funzionano proprio in modo corretto e, anzi, a volte provocano proprio loro stesse dei crash.
Inoltre, fammi sapere se e quali librerie Gambas2 hai, se eventualmente ne manca qualcuna all'appello. Nel file ChangeLog, contenuto nei sorgenti di pgDesigner1/2, faccio riferimento alla versione di Gambas utilizzata, ma anche nei README elenco le librerie utilizzate. Dagli una controllata.
Tieni presente che pgDesigner1 lo stanno utilizzando in parecchi, e finora non ho avuto ritorni. pgDesigner2 lo stanno usando alcune persone, e anche qui non ho avuto ritorni negativi. Quindi, penso sia proprio un problema di configurazione.
E' ovvio che toccherà trovare il motivo... ;)
Fammi sapere...
P.S.: Alcuni amici stanno usando pgDesigner2 a livello lavorativo, e vorrei eliminare problemi del genere il più possibile, prima di pubblicare definitivamente la nuova release.
Ciao md,
purtroppo ho letto solo ora. Concordo sulla teoria dell'ambiente e/o configurazione; su una macchina virtuale KDE salvataggio e apertura progetto funzionano correttamente, mentre permane il problema del combo.
Invero ieri sera ho riscontrato un ulteriore problema. Tentando di impostare una relazione tra due tabelle, in qualunque zona della Drawingarea clicco, sia essa una delle due tabelle coinvolte, od anche una zona "vuota", pgd2 mi segnala l'errore "Impossibile selezionare la stessa tabella". Questo anche in KDE. Questa sera ti passo l'output di env, mentre per le librerie avevo già verificato in /usr/lib la presenza delle dipendenze. Lang è impostato a it_IT.UTF-8.
Ciao.
Allego output di env, Gambas 2.22.0 installato da sorgenti ed il configure ha confermato la compilazione di tutti i componenti. Una cosa che ho scordato di dirti ieri è che selezionando apri progetto il primo errore che ricevo è: Could not find mime type applicatio/octet-stream --> no mime type installed.
Se ti servono ulteriori info sono a disposione.
Ciao
Credo di aver capito il motivo...
Nelle ultime release ho modificato i sorgenti di alcune classi, che si configurano partendo da dei file appositi.
Penso che tu stia utilizzando pgDesigner2 da sorgente, per cui fai un controllino, e verifica se esistono la sottocartella "config" (alla pari di "images"). In questa cartella ci sono i file di configurazione.
Se la cartella non esiste, oppure manca qualche file, bisogna provvedere, forse non mi sono accorto del problema durante gli aggiornamenti.
Se mi fai un elenco dei file, se esistenti, sotto questa cartella, posso vedere qual'è la causa...
Tieni conto che la cartella "images" deve essere presente per visualizzare le icone, ma soprattutto deve contenere altre sottocartelle, di cui è sicuramente essenziale: "default". Queste contengono le icone, e ogni cartella rappresenta un thema. Spero che ci siano anche queste.
Mi dici come hai scaricato pgDesigner2 ?
E pure come per pgDesigner1 ?
Ciao md,
approfittando di una pausa ho installato il tutto sul portatile che uso al lavoro. Pgd2 si comporta esattamente come sul pc di casa relativamente al combo ed al salvataggio/aperura progetto. Ti riassumo i passi per punti:
1 scaricato il tar di gb2 2.22.0 da sourceforge ed installato come da prassi.
2 scaricato sorgenti pgd2 da sourceforge (rev 175)
3 Verificate anomalie.
4 scaricato pgd1 da sourceforge 1.2.18.tar.gz
5 verificata anomalia apertura/salvataggio progetto (malformed url)
Riguardo i contenuti delle cartelle config e images di pgd2, ti passo l'output di ls cosicché tu possa verificarlo. ti allego anche l'output di env del portatile.
S.O: Ubuntu 10.04 X86_64
DE: Gnome (Standard, nessuna configurazione particolare)
GTK+ 2.20.1
Ora sono impossibilitato a fare controlli.
Stasera cercherò di capire perchè a te non funzia...
Dagli estratti che mi hai inviato sembra tutto a posto, però...
Ti faccio sapere...
Ho fatto l'ignorante e mi sono scaricato da sf i sorgenti delle due versioni.
Ho ricompilato ed eseguito, e tutto funziona.
Tieni conto che sono in ambiente virtuale con Fedora 14, con gambas2 2.22 installato. Questa macchina virtuale la uso a volte proprio per questi test.
La cosa che stò analizzando è la configurazione del sistema rispetto a quanto mi hai inviato.
La mia impressione è che tu abbia qualche problema di configurazione, e anche se hai installato gambas2, sembra come mancasse qualcosa, qualche libreria del linguaggio, o anche qualche libreria su cui si basa gambas2.
Ora, se trovo qualcosa, te lo faccio sapere...
Domanda: hai le librerie KDE installate?
Tieni conto che pgDesigner si basa sulle KDE (non su le GTK).
Nelle variabili di ambiente non vedo alcun riferimento alle KDE, a meno che gli occhi non mi ingannano.
- Sei sicuro che tu abbia compilato Gambas2 e tutte (e dico tutte) le sue librerie?
- O, per caso, lo hai installato in formato package su Ubuntu?
- pgDesigner lo hai ricompilato?
Ciao md,
grazie per il supporto che mi stai dando. Ho verificato le librerie kde, ti confermo che l'installazione di Gambas2 è avvenuta da sorgenti e che il solo componente risultato disabilitato era QT/Embedder, che credo sia obsoleto, pgdesigner, scaricato da SF e compilato da menu progetto nell'ide.
Alla fine il problema era legato ai permessi di .kde settati male. Ora pgdesigner(1/2) funziona correttamente. Permane il solo problema delle relazioni che ti accennavo in uno dei post precedenti.
Selezionando dal Menu PopUP Nuovo --> Relazione --> One-To-Many, qualunque tabella clicco mi dice 'Impossibile selezionare la stessa tabella'.
Scusa per lo stupido errore, sarebbe bastato dare + attenzione al messaggio 'Dcop server not running'
Non c'è mai niente di "stupido". Non si può verificare tutto, e capire di botto qual'è il problema.
Questa cosa dei permessi non è mai accaduta, per cui la tieniamo in serbo per quando accadrà nuovamente la stessa cosa ad altri...
Ora che sono a casa, provo a vedere la storia delle relazioni...
Ok, Huston c'è un problema... ;D
In effetti c'è un errore durante la creazione della relazione, se eseguita dal menu.
Comunque, puoi sempre crearla, selezionando l'icona nella toolbar (senza specificare il tipo, tanto lo puoi modificare nei parametri successivamente), poi clicchi sulla tabella padre e, senza togliere il dito dal click, lo rilasci sulla tabella figlia. A questo punto ti si apre la form del dettaglio, e lì aggiusti i parametri della relazione.
Ora vado a correggere l'errore... :(
Grazie per la comprensione...
ok per l'alternativa delle relazioni. Ciao e buon lavoro.
Ok, ti rispondo subito... Tieni conto che su pgDesigner1 non ci stò lavorando da un pezzo, per cui alcune cose non me le ricordo immediatamente.
Il problema in realtà non è un problema, nel senso che la funzione "funziona" allo stesso modo della selezione di una comune relazione.
Quando da menu definisci una relazione particolare (es. uno-a-molti), devi procedere allo stesso modo che ti avevo descritto nel precedente post, ovvero clicchi sulla prima tabella poi, senza togliere il dito, ti trascini fino alla seconda tabella, e lì rilasci il pulsante.
Per come ho impostato la logica, la relazione deve avere già impostate le due tabelle prima di aprire il form di modifica. Alla selezione dal menu popup non importa se hai lanciato il popup su una tabella piuttosto che su un'area vuota. Devi per forza iniziare il collegamento, nella modalità che ho descritto.
Fammi sapere se hai altri problemi...
Bye
Ciao MD,
il lavoro con pgd2 prosegue, anche se a rilento, senza problemi con postgresql.
Ieri, le feste comandate mi annoiano sempre un poco..., ho avuto la malsana idea di provare a produrre lo stesso progetto con Mysql, per fornire all'eventuale utente di un progetto che ho in mente, la possibilità di scegliere il DB che preferisce.
Quindi ho avviato un nuovo progetto Mysql50 e creato la prima tabella...che non riesco a popolare con le colonne xchè cliccando sul pulsante "NUOVO" nella maschera "modifica tabella" non succede nulla, cioè non appare la maschera di editing del campo, mentre risulta possibile creare indici e triggers.
Spero di avere espresso chiaramente il problema.
Anche una curiosità: è corretto che la funzione "Esporta verso fonti esterne" non crea il Database sul server? Nella fase di creazione progetto è possibile configurare il DB, ma questo deve esistere sul Server altrimente la connessione fallisce.
Grazie
Emanuele
Ri-ciao,
come ti dicevo lo sviluppo su pgsql prosegue. Oggi avevo la necessità di impostare un campo ENUM. Quindi tramite PGD2 ho creato il tipo, chiamandolo 'comparto' al quale ho aggiunto alcuni attributi. Vedi l'allegato Tipo_Enum.png. In seguito ho creato una tabella nella quale inserire un campo che utilizza il tipo 'comparto'., ma esportando il progetto, in SQL o su DB, ottengo l'errore seguente:
[04/27/2011 20:04:47 INFO ] pgSqlExport::Creazione intestazione ...
[04/27/2011 20:04:47 INFO ] pgSqlExport::Scrittura <Tipo::comparto> ...
[04/27/2011 20:04:47 INFO ] pgSqlExport::Type mismatch: wanted Collection, got String[] instead
[04/27/2011 20:04:47 ERROR ] pgDialogExport::pgDialogExport::Errore processo!
[04/27/2011 20:04:47 ERROR ] Type mismatch: wanted Collection, got String[] instead
[04/27/2011 21:04:30 WARNING] pgPanelEditType::Method SaveBefore not found !
[04/27/2011 21:04:30 WARNING] pgPanelEditType::Method SaveAfter not found !
dove sbaglio?
Emanuele
Ad occhio credo sia un errore di programma, che devo controllare.
Se hai pazienza, cerco di risolverlo prima possibile...
Grazie per i test che stai facendo sulla nuova versione. :-*
Nessuna urgenza, il progetto è ancora in stato embrionale e non vi è nessuna deadline.
Per quanto riguarda i test ho deciso di sviluppare un DB anche in SQLITE3, in modo da comunicarti eventuali problemi. Trovo PGDesigner un pezzo unico nel panorama di progettazione DB ed un'ottima scuola; quindi ringrazio te per averlo pensato e prodotto.
Ciao
Ti ringrazio, troppo buono... :D
Ti ringrazio, troppo buono... :D
Ehi se dai anche a me la stessa cifra posso scrivere cose ancora più lodevoli.... :rotfl:
Ehi se dai anche a me la stessa cifra posso scrivere cose ancora più lodevoli.... rotfl
...venale...aspetta magari dopo che ho dato un'occhiata ai tuoi lavori possiamo pattuire un compenso! ;D
In quel caso dovrebbe darti qualcosa lui stesso... :P
Ciao Luigi,
come promesso ho fatto alcune prove con MYSQL e SQLITE. Purtroppo devo informarti che ho riscontrato problemi con entrambi i motori; ti riassumo di seguito.
MYSQL:
- Creata la prima tabella risulta impossibile impostarne le colonne perché cliccando sul pulsante nuovo non si apre la maschera di modifica colonna.
- Salvando il progetto, alla successiva apertura pgdesigner2 segnala "errore caricamento progetto" immediatamente dopo il tentativo di caricare il file
della tabella. (Vedi log allegato)
SQLITE (vale per entrambe le versioni 2 e 3)
- Creata la tabella mi risulta impossibile impostare il tipo di campo xchè il combobox Tipo non è popolato.
- Anche in questo caso salvando il progetto, alla riapertura ottengo l'errore di caricamento progetto
Nota che l'errore di caricamento si verifica solo se nel progetto esiste una tabella, anche vuota, viceversa l'apertura va a buon fine.
Ti allego immagine relativa a sqlite (combobox vuoto), file di progetto Mysql e file di log relativo a Mysql.
Allora...
dovresti fare un controllo, ovvero verificare l'esistenza dei seguenti file, nella cartella "config" di pgDesigner2:
DATABASE.COMMANDS
DATABASE.COMMENTS
DATABASE.ENGINES
DATABASE.INFO
DATABASE.LANGUAGES
DATABASE.OPERATORS
DATA.INFO
DRIVER.INFO
FIELDTYPE.INFO
GAMBAS.VERSION
HT.INFO
LANGUAGE.INFO
MIMETYPE.INFO
OBJECT.INFO
PGDESIGNER.HELP
PGDESIGNER.PARAMETERS
PGDESIGNER.VERSION
Questi file sono essenziali al programma, perchè contengono la configurazione applicativa.
Il fatto che non ti si popolano le combo, è molto probabile che sia a causa dell'assenza di questi file.
Inoltre, per sicurezza, dovresti controllare che esista la cartella "images" e, sotto di essa, almeno la cartella "default".
In questa cartella sono presenti tutte le icone e le immagini dell'applicazione. E' anche vero che dagli screen-shot che hai inviato, non penso sia necessario, comunque sono circa 144 file .png.
Fammi sapere.
eccoci;
ho verificato, i file esistono, ti allego l'output del comando ls. La cosa strana è che con Postgre funziona.
Altrettanto strano è che la funzione 'nuovo' funziona nel tab 'indici' della maschera modifica tabella.
Ok, in effetti non funziona nemmeno a me, ed è probabile che in qualche modo abbia cambiato qualcosa.
Di solito provo la parte PostgreSQL, e forse ho malauguratamente disattivato qualcosa su gli altri motori.
Ora vedo di risolvere.
Il test che ti ho fatto fare era solo per essere certi che avessi tutto l'occorrente...
Nessun problema, se vuoi che effettui altre prove sono disponibile.
In effetti le mie esigenze sono concentrate su PostgreSQL; se puoi assegna una priorità maggiore al problema del tipo Enumarate. Quando avrai risolto con SQLite e MySQL fammelo sapere che continuerò i test.
Grazie,
Emanuele
Credo di aver risolto tutti i problemi che mi hai segnalato.
1) il problema del popolamento della combo per i tipi di campo era causato da un errore di caricamento dal file di configurazione.
2) il problema dei pulsanti di gestione dei campi di tabella era causato da un'impostazione errata degli eventi di gruppo.
Per gli errori di caricamento dei file di progetto, non ho evidenziato problemi, infatti tutti i test che ho fatto prima e dopo le correzioni non hanno evidenziato anomalie. Ad ogni modo, se ti si ripresenta il problema, prova a inviarmi il file, così vedo se per caso c'è una qualche condizione che non ho previsto, o altro (insieme al log).
L'errore sull'export a me non lo dà, ma è possibile (come sopra) che non abbia previsto alcune anomalie. In questo caso dovresti descrivermi cosa in effetti fai, e che dati stai inserendo, così che possa rifarlo anche io. Fai sempre in modo che possa individuare la piattaforma che stai sando, come ad esempio il driver (PostgreSQL, MySQL o SQLite) e la versione, e eventuali altri parametri. Tutte queste cose mi sono necessarie per andare puntualmente sulla parte di codice interessata. Tieni conto che per ogni tipo di database, oltre alla singola versione dello stesso, c'è un oggetto ad-hoc, come credo tu abbia già notato, per cui l'anomalia potrebbe risiedere in un particolare punto, come anche coinvolgere un'intera struttura.
I driver per i database sono stati creati in modalità ad incastro, ovvero ogni versione ha il suo codice solo se diverso dalla versione precedente. Questo mi permette di risparmiare codice, oltre ad incapsulare le varie funzioni e metodi. L'unico problema è che Gambas non permette di incapsulare classi all'infinito, per cui sono stato costretto a suddividere il codice in blocchi di classi, obbligandomi anche a ripetere lo stesso codice su più classi.
Vabbè, a parte questa descrizione, prova a scaricarti la nuova versione dal repository (l'ho aggiornata ora), e riprovare con i test, e fammi sapere se ora gli errori sono stati risolti.
Bye
innanzitutto grazie per la velocità. Suddivido la risposta in punti per maggiore chiarezza.
1. Popolamento combo in SQLite3: risolto
2. Creazione campi in MySQL5: risolto
3. Export verso fonti esterne con PostgreSQL8.4: fallisce dopo avere creato un nuovo "TIPO", nello specifico un tipo ENUM.
Con il motore SQLite3 ho riscontrato un nuovo problema all'atto del salvataggio di un oggetto tabella, pgdesigner 2 si blocca con il messaggio: "this application has raised an unaxpected error and must be aborted."
Con il motore Mysql50 la lunghezza dei campi viene indicata senza virgola (40,0 --> 400)
Ti allego .gz contenente:
1. file progetto postgresql84 (pneusoft.pgd)
2 file di log sqlite (pgdesigner2_log_lite.txt)
3. immagine png con i campi Mysql
4. schermata errore export
5 log postgresql84 export error
Stasera vedo di analizzare questi problemi.
Ti ricordo che ora il progetto si basa su Gambas2 2.23.0, quindi prova a ricompilare e ad aggiornare le Form (vedi menu gambas).
Nell'attesa ho installato Gambas2 2.23 e provato a creare un progetto SQLite3.
Tutto sembra funzionare ma quando vado ad aprire il progetto salvato pgd2 mi segnala errore nell'apertura progetto. nel log, che ti allego unitamente al progetto, non vedo nulla di significativo.
Nota che il progetto consiste in una semplicissima tabella vuota.
Con PostgreSQL84 permane il problema del Tipo ENUM (Type mismatch: wanted Collection, got String[] instead)
A tua disposizione per ogni prova ti sia d'aiuto.
Ciao
Credo di aver eliminato anche i due errori rimasti in piedi.
1) c'erano alcuni errori, rimasti da alcune precedenti modifiche, circa le proprietà degli oggetti Type
2) c'era un valore di ritorno invertito in alcune funzioni della procedura di caricamento dei file di progetto.
La nuova versione è disponibile su sf.net.
Fammi sapere se ora è a posto.
P.S.: nel prox aggiornamento ti inserisco nell'elenco contributori, così ti impari... :P
(ovviamente dovrai darmi il tuo nome vero, se mi dai il permesso di farlo...)
Ho provato la nuova versione, ecco i risultati dei test.
1. Postgresql84: risolto l'errore sul Type. :ok:
2. Mysql50: risolto il problema di caricamento progetto e combo Field Type. :ok:
Rimane il problema del Field Length. Impostando la dimensione del campo = 80 e Decimali =0 nella maschera Modifica Tabella la colonna Len della GridView riporta 800 (vedi figura Field_len.png) laddove dovrebbe essere 80,0
3. SQLite30: purtroppo con questo motore permane un problema nella configurazione dei campi di tabella. Ti elenco i passi eseguiti:
- 1. Creo un nuovo progetto
- 2. Creo una nuova tabella
- 3. Creo un campo INTEGER autoincrementato Primary Key
- 4. Salvo la tabella
- 5. Seleziono modifica tabella
- 6. Aggiungo un campo TEXT
- 7. Salvo la tabella
a questo punto ottengo l'errore 'This application has raised an unaxpected error and must aborted' (vedi figura Errore_sqlite3).
Inserendo una interruzione alla linea 2055 della classe pgSQlite20, la funzione IsForeignKey, ed avanzando step by step nel codice, ho riscontrato che l'errore è generato dal valore NULL ritornato dalla funzione getValue in pgData.class; tale valore dovrebbe essere una ENUMERATION secondo l'istruzione FOR EACH oRelation IN table.GetValue("RelationsFrom")
Credo quindi che stia tentando di enumerare un oggetto NULLO. Potrebbe anche essere un baco di gb2, in effetti mi aspetterei l'errore Null Object, ma riconosco che la struttura di pgdesigner2 è molto complessa e certamente la mia analisi è sbagliata.
Spero di averti aiutato e non averti confuso le idee con la mia esposizione.
Circa la tua offerta di inserirmi nei contributori se lo ritieni ne sarei onorato, poiché ritengo il mio 'contributo' veramente minimo quindi senza indugio, permesso accordato. Il nome: Emanuele Sottocorno . Ma fai attenzione che quando mi assumo un compito non mi fermo finchè non lo porto a termine.... :hard:
Corretti tutti e due gli errori. Riguardo al primo, l'anomalia era presente sia su SQLite che MySQL.
Ho aggiornato il repository.
Fammi sapere
NOTA: dai un'occhiata in About... ;)
:D
Ciao Luigi,
procedendo con i test di PGDesigner2 ho riscontrato la seguente anomalia:
pgDesigner2 build 179.800
driver: PostgreSQL8.4
Funzione: Esporta Verso Fonti Esterne
Salva su Database:
Selzionando 'Tutti' nel gruppo 'Oggetti' il processo fallisce nella creazione del TIPO:
Aggiorna database ...
Scrittura <Tipo::comparto> ...
Too many arguments
Errore processo!
Too many arguments
deselezionando l'oggetto 'comparto' il processo termina correttamente.
Se, alternativamente, salvo su file sql, l'esecuzione dello stesso termina correttamente in ogni caso.
Emanuele.
AEOH!!! Me vuoi fà lavorà proprio... :D
La nuova versione è sul repository.
Fammi sapere.
Grazie
A proposito, ho aggiornato i driver PostgrSQL per caricare dal database i valori per i TYPE ENUM...
Non ho trovato ancora il modo di farlo per gli ATTRIBUTE...
Il repository e nuovamente aggiornato. Due versioni nella stessa giornata... mò basta... :D
Sono riuscito anche a caricare da db i TYPE COMPOSITE.
Nuovo aggiornamento al repository.
Bye
Per oggi niente problemi, AEOH!!! Me vuoi fà lavorà proprio...
solo un quesito.
Non ho capito come funzioni l'opzione Crea Database della funzione Esporta... ho fatto queste prove:
- lmposto il nome del db (pneusoft) nella maschera Parametri Progetto --> Configura DB, ma pgdesigner non ne tiene conto, infatti nel file SQL generato il comando CREATE DATABASE non è seguito dal nome_db
- Impostando il nome_db nei parametri di connessione ovviamente ottengo errore di database inesistente.
è possibile fare si che dal progetto venga creato il database direttamente sul server? Questo ovviamente solo alla prima esportazione.
Ora vado ad aggiornare e poi mi metto al lavoro...
Ciao
Sulla creazione del database ci sono alcuni problemi...
In teoria, solo l'utente amministratore (postgres) può creare database, e se nel progetto ti agganci al database come normale utente, non riesci a crearlo.
Al momento, le istruzioni di creazione del database, sono valide solo per l'esportazione su file (sql o report).
Devo studiare il modo di poter gestire la cosa con più utenze, a meno che il progetto non venga creato con l'utente postgres, e poi andare a dare le giuste grant all'interno del motore PostgreSQL.
Al momento, le istruzioni di creazione del database, sono valide solo per l'esportazione su file (sql o report).
OK, ma il nome del database non compare nel file (sql) generato. vedi allegato
Hai perfettamente ragione...
Il fatto è che su questo punto devo ancora lavorarci su...
e' solo un'ipotesi, fammi sapere cosa ne pensi:
considerato che pgDesigner è uno strumento di progettazione DB e non un DBMS manager, selezionando la funzione Salva su database, la maschera di connessione imposta il textbox utente con le proprietà:
- .ReadOnly = true
- .Text = "postgres"
cosicché si debba obbligatoriamente utilizzare questo, conoscendone ovviamente la password
per la textbox Nome
- .Text = 'nome_del_db_da_creare'
Il nome_del_db_da_creare potrebbe essere impostato dalla maschera Configura Progetto.
Dopodiché una volta creato il DB verranno impostati i privilegi di ciascun utente tramite psql o altro strumento.
Nel caso in cui il progettista non conosca la password di postgres, sarebbe obbligato a Esportare su File (sql) che sarà eseguito successivamente da utente con privilegi adeguati.
In realtà, come in tutti i RDBMS che si rispettino, esiste la possibilità di abilitare utenze anche con diritti amministrativi, o con abbastanza privilegi per poter fare cose a livello admin, tra queste anche la possibilità di creare nuovi database, magari assegnando una tablespace appropriata.
A questo punto, noi abbiamo due aspetti da considerare:
1) l'utente proprietario del database
2) l'utente che è proprietario degli oggetti che inserisce nel database
le due opzioni possono essere compatibili, nel senso che nessuna esclude l'altra, per cui abbiamo due possibilità:
1) l'utente che crea il database è postgres, che poi dà le opportune grant agli utenti necessari
2) l'utente crea gli oggetti su un database già pronto, con opportune grant date da postgres all'utente che li crea
Gestire due utenze, una per la creazione del db, l'altra che crea gli oggetti, diventa alquanto onerosa se gestita all'interno di pgDesigner.
Finora non ho mai visto applicazioni che mettono a disposizione questa logica.
Ho appena aggiornato il repository.
Ho sistemato altre cose, e una che mi è stata segnalata da un'utente polacco...
Scaricato e compilato.
Ho notato una piccola anomalia nel popolamento degli attributi di un Tipo Enum (sempre lui...), per ogni attributo inserito, a seguire il primo, al click del pulsante Nuovo, nella TextBox PGSQLEnumName appare il testo dell'elemento precedentemente selezionato nella GridView ( non l'ultimo inserito), mentre dovrebbe essere vuota.
In effetti questo è uno strascico dell'evento di selezione della riga nella lista.
La selezione riporta il contenuto della riga nei campi di editing.
E' ovvio che durante gli inserimenti questo può dar fastidio, ma non posso ovviare.
Comunque, il pulsante Insert aggiunge sempre, a prescindere se il dato è già presente nella lista. Il pulsante Modifica aggiorna la riga selezionata (se non vuota).
In definitiva, questa non è un'anomalia, ma solo la normale gestione dell'evento....
Rieccomi,
chiarito il discorso riguardo gli attributi, ti chiedo un chiarimento riguardo SQLite3.
questo motore dalla versione 3.6.19 ha introdotto il supporto alle foreign keys, che puoi configurare nel seguente modo:
CREATE TABLE comune(
comune_id INTEGER PRIMARY KEY AUTOINCREMENT,
comune TEXT,
provincia TEXT,
FOREIGN KEY(provincia) REFERENCES provincia(sigla)
);
EDIT
Anche per MySQL risulta impossibile creare relazioni.
I due driver, MySQL e SQLite, li ho aggiunti in questa nuova versione, anche per offrire un più ampio spettro all'utilizzo del programma.
Ho iniziato ad inserire le basi di questi due motori, ma poi mi sono fermato, perchè avevo da sistemare la logica applicativa, per cui questa parte l'ho lasciata un pò in disparte.
Di certo, la mia idea è quella di seguire in qualche modo tutte le caratteristiche di ogni singolo motore, almeno ci proverò, per cui vedrò di implementare le varie proprietà di mano in mano...
Sicuramente per SQLite, almeno da quanto estrapolato dalla documentazione, la logica relazionale l'ho lasciata disattivata, ma se tu mi confermi che invece è presente, vedrò di implementarla. Non ricordo la presenza dell'istruzione che mi hai indicato (foreign key).
In pgDesigner, la logica delle relazioni mi ha costretto a implementare codice ad-hoc, sia per le sue caratteristiche, sia perchè deve seguire un filo di astrazione, che prescinde da quanto viene poi scritto sul database. Questo per dire che, la logica delle relazioni è in qualche modo slegata dal resto (nei driver), ma ne fà anche parte (concetto astruso, ma è così...).
In pratica, se non ricordo male, basta che riattivare la logica anche per SQLite e abilitare i riferimenti interni in modo che questi vengano correttamente popolati e gestiti dall'applicazione.
Riguardo a MySQL, sempre se non ricordo male, la parte relazionale mi risulta attiva. Se non funziona forse è a causa di qualche problema che dovrò analizzare. Ma forse mi sbaglio... In effetti il mio lavoro si è concentrato più sui driver PostgreSQL che su altri, e quindi è possibile qualche errore o dimenticanza.
Detto questo, se hai qualche proposta concreta da farmi, è bene accetta, come in questo caso. Se hai la possibilità di scrivere codice, meglio... ;D
Purtroppo la documentazione è quasi inesistente, ad eccezione di alcune specifiche che ho scritto, relative ai file di progetto e alla configurazione su disco. Anche in questo, dato il poco tempo a disposizione, avrei bisogno di una mano, per non parlare delle traduzioni in altre lingue...
Il supporto alle Foreign Key in SQLite l'ho scoperto per caso, consultando la doc sul sito ufficiale.
Riproducendo il DB che sto disegnando con PG mi è nato il problema; non conoscendo il motore in oggetto mi sono collegato al sito http://www.sqlite.org/docs.html (http://www.sqlite.org/docs.html) e nelle FAQ ho trovato la risposta. Da qui la segnalazione che ti ho fatto.
Ho quindi sospeso con SQLite e avviato un nuovo progetto MySQL con le stesse finalità. La sorpresa è stata scoprire che anche con questo motore il pulsante/menu Relazioni risultava disabilitato.
In realtà il mio interesse è concentrato su PG, le prove con Lite e MY le faccio perché ritengo PGD2 un applicativo eccezionale (non è plagio) e mi fa piacere contribuire al suo successo.
Riguardo l'aiuto che posso offrirti, credo di non avere le conoscenze adatte a contribuire al codice, circa la documentazione ci ragiono e ti faccio sapere, scusami ma il tempo è veramente tiranno, le proposte verranno sicuramente proseguendo con lo sviluppo del DB.
Nel frattempo vedo se trovo qualcuno disposto a collaborare per le traduzioni; hai delle priorità riguardo le lingue?
Riguardo alle traduzioni ho visto che il francese è fermo al 7%; ho un amico che si è detto disponibile a provarci. Se non hai già altri contatti provo a mandargli il .po
Ciao
Bè, certo.
C'era un francese che ha fatto la traduzione della versione 1.x, ma a causa di impegni non ha potuto continuare.
Se il tuo amico è disponibile, certo ben volentieri!
Ho inviato il .po.
Nel frattempo sto studiando pgDesigner2 per capire se posso darti una mano col codice. Ho deciso di partire dal problema delle relazioni che risultano disabilitate con MySQL50.
Credo il problema stia nella classe pgMySQL50 alla funzione
PUBLIC FUNCTION isValidOption(type AS Integer) AS Boolean
CASE pgDataInfo.OBJ_DB_RELATION
FOR EACH oField IN oRelation.GetValue("Field2")
$Items[1] = "Fields2" e questo determina che venga ritornato un valore NULL; cosicché pgDesigner2 si blocca con l'errore "null object"
Stessa cosa per l' istruzione FOR EACH oField IN oRelation.GetValue("Field1")
alla riga 2088 della classe pgMySQL50
Dopo avere abilitato le relazioni e modificato le due righe di cui sopra devi anche modificare alla riga 2094 l'istruzione
pgHtml.HighLabel(oRelation.GetValue("Table1"), {html}) & " (" & String.Mid(f, 2) & ")" &
pgHtml.HighLabel(oRelation.GetValue("Table1").Name, {html}) & " (" & String.Mid(f, 2) & ")" &
Type mismatch: wanted String, got pgData instead
Ti allego il file compresso con le modifiche apportate per le verifiche del caso.
Scusa MD**** ho notato che ti sei collegato più volte in questi giorni ma non mi hai risposto al post precedente. Hai commenti e/o giudizi a riguardo?
Scusa, avevo fatto una passata di sfuggita, ma dato che avevo problemi sul lavoro, non ho potuto risponderti.
Riguardo alla tua segnalazione, devo controllare anche io, nel caso abbia scelto la cosa in base a qualche problema, anche se non credo.
Se è un'errore nella condizione, farò subito la modifica, altrimenti è probabile che tocca implementare le necessarie proprietà all'oggetto.
Riguardo agli altri errori, mi pare di averli corretti, ma non ho ancora messo la nuova versione nel repository...
Appena ho un attimo, faccio gli ultimi aggiustamenti e lo metto nel repo, dopodichè di avverto...
E' inutile riaffermare i miei ringraziamenti per il tuo aiuto!
Ho fatto i controlli da te suggeriti e, in effetti, c'erano gli errori che mi hai segnalato e che ho prontamente corretto.
Riguardo alla disabilitazione della gestione delle relazioni in MySQL, in effetti erano rimaste disabilitate e, dopo aver controllato l'esistenza di tutte le necessarie proprietà, ho provveduto a abilitarle.
L'unico mio dubbio, che tocca verificare, è se per caso nella versione 5.0 la gestione delle relazioni non sia gestta, e che quindi avevo disattivato giustamente la funzione. Questo, magari, se riesci ad appurarlo, eviterebbe di scrivere un'ulteriore driver...
Comunque, ora il repository è nuovamente aggiornato.
Ti ringrazio per l'ottimo lavoro di certosino. Questo significa che, alla fine, il mio codice in qualche modo si capisce... ;D
Ricordavo che il supporto alle relazioni fosse introdotto ancor prima della 5.0. Ma dato che la memoria alla nostra età (quasi 50) comincia a vacillare, mi sono andato a leggere la Reference Guide. In effetti le relazioni sono state introdotte contemporaneamente al motore InnoDB e sono pienamente supportate dalla 5.0; esistono alcune limitazioni che inducono a modificare il codice di pgDesigner.
- Entrambe le tabelle in relazione devono essere InnoDB e non possono essere temporanee.
- I campi BLOB e TEXT non possono essere impiegati in una relazione
Ho dato una lettura anche alla Ref. Guide della 5.6 e non è cambiata di una virgola.
Ed ora...scusami per la dimenticanza :hard:, ma nel post relativo alle relazioni non ti ho segnalato che la riga pgMYSQL50._sqlTable.2092 deve essere modificata da così:
s &= pgHtml.HighCommand(" CONSTRAINT FOREIGN KEY", {html}) & " (" & String.Mid(t, 2) & ")" &
s &= pgHtml.HighCommand(" CONSTRAINT FOREIGN KEY", {html}) & " " & pgHtml.HighLabel(oRelation.Name, {html}) & " (" & String.Mid(t, 2) & ")" &
A presto.
prima che tu possa odiarmi, ti segnalo un altro problema con le relazioni in MySQL:
l'evento MYSQLEvent_Click() della classe pgPanelEditRelation alla riga 397 necessita di un ME.
---> errore not an object cliccando sul bottone elimina
---> OK
Odiarti?!? Ma ti detesto proprio... ;D
Scherzi a parte, stai facendo un'ottimo lavoro e per questo ti ringrazio. Ormai sono arrivato al punto che questi particolari non li vedo, tenendo presente che, a parte qualche test diretto su MySQL, non è che abbia approfondito più di tanto, e tenendo anche presente che ho fatto nel frattempo parecchie modifiche al codice, per cui molto cose è probabile che risultino errate a causa dei vari cut&paste...
Purtroppo molte cose Gambas non le recepisce, e nella compilazione non vengono fuori.
Stasera, se riesco, faccio le modifiche che mi hai segnalato, e ti avverto quando aggiorno il repository.
Che posso dire... BRAVO!!! e... GRAZIE!!!
Fatto!!! :ok:
Ormai che siamo in ballo balliamo...
ho modificato la classe pgProject introducendo la verifica che le tabelle parte di una relazione siano entrambe di tipo InnoDB. Le modifiche le trovi alle righe da 2605 a 2609 e da 2782 a 2787 del file allegato.
Puoi verificare che sia tutto ok?
Se sei d'accordo nei prossimi giorni provo ad inserire il controllo sui campi della relazione.
A presto.
Quindi ti sei impazzito del tutto, eh?!? ;D
Stasera verifico e ti dico...
Beh si, diciamo che ci ho preso gusto... :2birre:
Ahiahiahi.... bè, peggio per te... ;D
Stò controllando le tue modifiche, però devo farti un appunto, non nel senso cattivo, ma solo per segnalarti alcune cose, visto che non ho fornito documentazione a riguardo:
1) le classi, oltre i driver e i pannelli specifici del singolo db, devono essere il più possibile slegati, nel senso che controlli puntuali a proprietà specifiche non devono essere presenti. Al più si crea un metodo specifico all'interno del driver stesso che, come forse avrai notato, contiene tutti i metodi presenti nelle altre classi analoghe, e solo il contenuto ovviamente cambia.
2) Il punto 1 è valido per tutte le proprietà, ad eccezione di alcune, in particolare quelle appunto legate agli oggetti relazione. Se dai un'occhiata ai metodi privati _createTable(), per esempio, ci sono alcuni elementi che sono comuni in tutti gli oggetti Table presenti nei driver.
A parte il codice che hai scritto, che formalmente è corretto, adesso il problema è capire dove inserire i controlli che hai indicato.
Le possibilità sono 2:
1) inserire la validazione all'interno del pannello di gestione dell'oggetto
2) creare un metodo all'interno dei driver per la validazione
In tutti e due i casi, è necessario prevedere che la validazione venga effettuata in tutti i casi:
a) creazione/modifica oggetto da pgDesigner,
b) import oggetto da fonti esterne (db, file sql, file progetto), onde evitare l'ingresso di valori non congrui.
In parole povere, questa verifica deve essere analizzata bene, onde evitare di commettere lo stesso errore che feci con la vecchia versione, ovvero includere codice di difficile controllo e manutenzione.
Ripeto, le tue modifiche sintatticamente sono ben integrate nel codice, solo che credo sia il punto meno indicato dove inserirle.
A questo punto farò un'analisi direttamente sul codice, per capire come e dove meglio inserire queste validazioni ma, ovviamente se hai qualche proposta tu, la analizziamo insieme.... :ok:
Analizzando velocemente il codice di pgDesigner2, riferito a MySQL, in effetti il codice per gli oggetti di tipo RELATION è scritto solo in parte. In realtà mancano le funzionalità per il caricamento da db e un altro bel pò di roba che, forse, avevo lasciato appesa e non più ripresa.
Ho dato anche un'occhiata alla documentazione ufficiale:
http://dev.mysql.com/doc/refman/5.0/en/create-table.html (http://dev.mysql.com/doc/refman/5.0/en/create-table.html)
http://dev.mysql.com/doc/refman/5.1/de/create-table.html (http://dev.mysql.com/doc/refman/5.1/de/create-table.html)
per le versione 5.0 e 5.1 e, in effetti, la sintassi per la creazione delle relazioni esiste, e per tutte e due le versioni e, credo, anche per le successive.
A questo punto, visto che finora avevo lavorato principalmente sulla base di PostgreSQL, dobbiamo ora dedicarci a sistemare la parte MySQL.
Adesso, sulla base di queste informazioni, dovrò analizzare cosa veramente manca e cosa modificare, per definire una volta per tutte la gestione di questo driver. Questo almeno iniziando dalla versione 5.0, che è l'unico driver per ora incluso in pgDesigner. Poi si verificheranno le varie modifiche con le versioni successive, eventualmente implementando nuovi driver (così come fatto per PostgreSQL).
Quindi, dovrò lavorare su questo ma, come per PostgreSQL, dovrò capire anche come estrarre le varie info dal db... Per cui i test credo dovremo sospenderli, fino a che non riesco a sistemare le cose.
Se hai modo di darmi una mano, ben venga. Puoi verificare come, andando a fare comparazioni con i driver di PostgreSQL...
Ripeto, le tue modifiche sintatticamente sono ben integrate nel codice, solo che credo sia il punto meno indicato dove inserirle.
Hai perfettamente ragione. Inserito lì il codice ha valore per tutti i DB, impedendo di creare relazioni in PGSQL e SQLite3
A sensazione opterei per un metodo all'interno del driver.
In realtà bastere, e bbe verificare l'esistenza della proprietà, in modo da non bloccare il tutto...
Comunque, mi sono letto la documentazione MySQL, e ho rianalizzato il codice del driver.
Sono addivenuto ad una soluzione drastica, per evitare di inserire ulteriori logiche un pò troppo dipendenti da condizioni particolai, ovvero lasciare tutto così com'è e lasciare all'utente il compito di usare o meno certe proprietà.
A livello di codice c'è tutto il necessario per gestire le relazioni per MySQL, compreso anche l'eventuale caricamento/lettura da un database esistente (la parte relazioni, visto com'è impostato MySQL, viene estratto dalle informazioni della tabella, diversamente da come fatto per PostgreSQL.
In tutti i database esistono condizioni particolari, ma non tutte possono essere gestire da un programma generalizzato come pgDesigner2, altrimenti facciamo un duplicato del motore db.
Con questo non voglio dire che non si possa fisicamente fare, solo che è necessario analizzare se ne vale la pena. Il database stesso fà già i suoi controlli sintattici e logici sui comandi sql, e non vorrei replicarne gli algoritmi anche in pgDesigner (che è già abbastanza complesso...).
Avevo anche pensato di creare un apposito metodo di validazione, ma sarebbe alquanto pesante e dipenderebbe da troppi fattori.
Che ne pensi?
Effettivamente dopo avere letto il tuo post di ieri, ho fatto alcune considerazioni:
1. L'utilizzatore di pgdesigner dovre, e bbe, sapere quello che sta facendo, anche se l'errore è sempre in agguato.
2. Eventuali violazioni delle regole sono certamente segnalate dal database.
3. pgDesigner è un applicativo ad uso professionale.
4. La conoscenza delle funzionalità ammesse ed utilizzabili è demandata all'utente.
...ma...
5. se fai una cosa falla bene...
Al punto 5 non intendo dire che pgdesigner sia fatto male, anzi, credo veramente non abbia competitori in particolare la versione 2; l'interrogativo che mi pongo è: potrebbe rappresentare una lacuna il fatto di non gestire alcuni controlli di particolare rilievo? Se esegui il controllo sulla compatibilità dei campi in relazione perché non controllare le tabelle?. Immagina la seguente situazione:
Creo un nuovo progetto
Lo popolo di tabelle
Configuro le relazioni, di cui una per errore su una tabella MyISAM e tutto sembra andare bene
Esporto il progetto su database
Ottengo una segnalazione di errore.
La prima reazione è darmi del p...a (un termine molto usato a Milano), immediatamente dopo penso ah però, c'è un baco...
Conclusione:
penso valga la pena di proseguire con i test evidenziando ciò da correggere per giungere ad una versione di rilascio e tenere in serbo per future minor releases eventuali aggiunte.
PS ho provato ad importare un db MySQL e pgd2 si blocca con un errore NULL OBJECT. Se riesco questa sera indago.
Hai perfettamente ragione, oltre al fatto che renderebbe il programma una software meragiosamente gagliardo..., ma è da supporre che mettere controlli a livello di dato sarebbe alquanto laborioso.
Fino ad oggi, avevo pensato ad una logica che si fermasse solo all'interazione tra i vari oggetti, i vari legami e, eventualmente fino alla validazione della singola informazione (es. il tipo di campo), ma non fino all'intreccio logico di queste ultime.
Il discorso, ovviamente, non è solo legato a MySQL, ma vale anche per gli altri rdbms, e alle singole versioni. La prima fatica vera è stata proprio quella di individuare le diverse caratteristiche tra versioni, fino ad arrivare alla sintassi finale. Però qui mi sono fermato, altrimenti non ne uscivo vivo, e dato che lo sviluppo lo avevo iniziato e continuato da solo, credo sia impossibile, nel poco tempo libero che uno dedica an progetto del genere, prevedere e fare tutto. Quindi, ho messo dei paletti, e questo delle interazioni tra le varie proprietà, è uno di questi.
Con questo non voglio dire che poi non si vada a fare, anzi, sicuramente si farà, ma solo dopo che l'applicazione avrà raggiunto una certa stabilità, e questa ancora non è stata raggiunta (vedi già le tue ultime segnalazioni).
Bene, visto che abbiamo comunità di vedute...andiamo avanti!
Per quanto posso farò il possibile per darti una mano anche col codice, mantenendo come priorità i test e proponendo di volta in volta una soluzione ai problemi che riscontrerò, soluzione che sarai comunque tu a valutare.
PS. pgdesigner è adesso un software gagliardo, in futuro sarà incomparabile.
PS. pgdesigner è adesso un software gagliardo, in futuro sarà incomparabile.
L'utente md9327 è stato bannato poicè si è scoperto, mediante comparazione degli IP, che aveva creato un account clone, denominato sotema, per elogiarsi da solo....peccato, il forum gambas-it perde un elemento valido ma purtroppo eccessivamente narcisista....
:rotfl:
mmmmmmh... stò ceskho tocca eliminarlo, è come una mosca, ma più fastidioso... :rotfl:
Comunque, e scherzi a parte, sotema hai detto bene, e ti ringrazio sia per le proposte future, sia per il lavoro che hai già svolto, che non è poco, credimi...
Riguardo ai test benissimo, così riusciamo a metterlo in condizione di renderlo publicabile definitivamente. Poi verrà il momento di espanderlo, sempre che non abbia sbagliato anche questa volta ad impostarne la logica. Purtroppo gambas, come ho più volte detto, ha dei limiti rispetto ad altri linguaggi più evoluti e conosciuti, ma questa è anche una sfida che ho intrapreso e continuo volentieri. Avrei potuto scriverlo in java, ma oltre ad esserci già qualche alternativa, era fin troppo scontato...
Una volta che avremo gambas 3, ci sarà da lavorare per adattare pgDesigner, e ho già visto più o meno le cose da fare rispetto alle differenze con l'attuale versione. CI sono anche dei conflitti di nomenclatura che toccherà sistemare, oltre a qualche funzione che è stata tolta, e che toccherà emulare...
Vedremo...
A parte PostgreSQL, che conosco abbastanza, su MySQL (conosco anche questo, ma non così bene) tocca verificare che tutto funzioni a dovere. Per SQLite potrebbero esserci dei problemi, a causa della struttura non molto chiara, e del reperimento delle informazioni circa gli oggetti. Per questo db ho usato un sistema che interroga direttamente (shell) l'eseguibile sqlite, ma sicuramente avrà qualche pecca...
mmmmmmh... stò ceskho tocca eliminarlo, è come una mosca, ma più fastidioso.. :rotfl:
sti giovinastri sempre sfrontati con noi vecchietti...
Ho fatto alcuni test con il driver MySQL. Mi sembra che la parte di progettazione del DB funzioni egregiamente, mentre ho riscontrato alcuni errori nella esportazione verso fonti esterne; ho quindi modificato la funzione MySQL50._sqlTable(), cercando di rispettare la sintassi riportata sulla Reference Guide, per correggere tali errori.
Rimane un unico problema: nel file sql generato bisogna inserire i seguenti comandi:
in testa
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
in coda
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
al fine di evitare l'errore "Cannot create Table..." dovuto al fatto che alcune Foreign Key referenziano tabelle non ancora create.
I suddetti comandi devono essere inoltre eseguiti nella fase di esportazione su DB.
Scusami ma proprio non ho capito dove inserirle; del resto non volevo toglierti il piacere di farlo personalmente... :-[
Ti allego la classe modificata, il progetto e il file sql contenente i comandi.
Faccio una diff per verificare le tue modifiche stasera.
Riguardo all'implementazione delle righe in testa e in fondo agli export, due domande:
1) la sintassi è valida per tutte le versioni MySQL, dalla 5.0 in poi?
2) è proprio necessaria?
La seconda comporterebbe un'idea che avevo già in mente, cioè quella di implementare una sorta di metodi PRE/POST per la creazione dell'output sql.
In effetti, al momento, non è prevista una cosa del genere, nel senso che sarebbe anche teoricamente possibile inserire istruzioni all'interno dell'oggetto DATABASE (ovviamente il primo in lista), ma è molto in teoria.
Ci devo pensare.
Ti faccio sapere a breve, forse stasera stessa, al momento non ho modo perchè sono in ufficio.
1) la sintassi è valida per tutte le versioni MySQL, dalla 5.0 in poi?
Si, comunque farò verifiche approfondite.
2) è proprio necessaria?
l'output generato dalla funzione _sqlTable crea le tabelle ordinate alfabeticamente, ciò comporta che se la tabella 'azienda' contiene delle foreign key che referenziano la tabella 'comune' il server genera l'errore 'Cannot create table ERR105', in quanto la tabella comune non esiste.
L'istruzione /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
1) la sintassi è valida per tutte le versioni MySQL, dalla 5.0 in poi?
Si, comunque farò verifiche approfondite.
OK...
2) è proprio necessaria?
l'output generato dalla funzione _sqlTable crea le tabelle ordinate alfabeticamente, ciò comporta che se la tabella 'azienda' contiene delle foreign key che referenziano la tabella 'comune' il server genera l'errore 'Cannot create table ERR105', in quanto la tabella comune non esiste.
L'istruzione /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
In effetti, dato che in MySQL la gestione delle relazioni viene effettuata direttamente dalla funzione di creazione tabelle, diversamente da PostgreSQL. Questo fà saltare la logica che avevo impiegato appunto per evitare il problema di ordinamento...
Ho verificato la sintassi, è valida anche per la versione 5.5 e 5.6.
Ho fatto le variazioni che mi hai indicato nell'allegato, ma non completamente, dato che avevo dei dubbi sull'impaginazione della sintassi, per cui ti prego di riverificare l'esportazione, sia su file sql che su db.
Riguardo alle stringhe PRE e POST creazione, ho appunto inserito due nuovi metodi nella classe pgDriver (e derivati), proprio per poter applicare comandi appositi. Questi metodi intervengono subito dopo la creazione del database, e appena prima della chiusura dell'intera struttura sql. Non ho potuto provare la cosa, ma credo che funzioni, visto che al momento è piuttosto semplice. Ad ogni modo se riesci, prova anche questa cosa.
Bel lavoro!!!
Major Tom to Ground Control, have a problem here.
Ho provato la nuova release, l'esportazione non funziona in nessun caso;
1. Su Database ritorna un errore di sintassi SQL. che risulta difficile indagare perché:
2. Su File o Video mi riporta errore di connessione al Database. ???
In effetti l'uscita della riga pgSqlExport._preSql(...)
RETURN ME.Project.Driver.ExecuteSqlArray(ME.Project.Driver.PreSql(pgDriver.SQL_CREATE))
pgConnect.ExecArray(pgLogin.Create($type, $host, $port, $name, $login, $password), arr)
Ho riprovato la release precedente e l'impaginazione mi sembra corretta. Quello che ho fatto è inserire un controllo sulla presenza di Indici, nel qual caso dopo la definizione della Primary Key deve essere inserita la virgola.
Credo di aver fatto una cavolata "ENORME"!!!
In effetti, non ho tenuto conto, tra le altre cose, che la sessione viene aperta e chiusa ad ogni output, per cui quelle funzioni PRE/POST, oltre a non funzionare, non servono proprio a nulla...
Riguardo l'errore durante l'export su file sql, è una mia svista...
Per il momento le tolgo, poi analizzerò come riattivarle in modo corretto.
Tra un pò metterò tutto sul repository.
:-\
Fatto!
Credo di avere in questo periodo la testa un pò fuori... avevo aggiornato sqlexport, inserendo altri errori. Per fortuna me ne sono accorto, anche se ho dovuto riaggiornare la revisione.
Mi fai sapere se ora funziona come prima? (Export sql e Export DB).
Grazie
OK. Ora l'esport su file/video funziona; per quanto riguarda il DB no, xchè bisogna sempre inserire i comandi per disabilitare il check delle Foreign Key.
Ad occhio mi sembra che manchi qualche virgola nell'output sql.
Domani ci do un occhio.
EDIT:
I metodi PreSql/PostSQL nella classe MySQL50 sono commentati, se li attivi l'esport su video/file funziona perfettamente, domani provo l'esport su DB.
Buona :sleepy:
Ho controllato per bene il metodo pgMySQL50 che ho modificato attenendomi alle seguenti regole del comando CREATE TABLE...
- Ogni definizione di Field deve terminare con la virgola
- La definizione della Primary Key deve essere seguita dalla virgola solo se ci sono indici nella tabella
NB Gli indici sono obbligatori su tutti i campi che costituiscono una Foreign Key - La definizione di un indice deve terminare con la virgola se:
- ci sono altri indici
- ci sono delle Foreign Key
- La definizione di una Foreign Key deve terminare con la virgola solo se ci sono altre FK
Le modifiche apportate le trovi:
pgMySSQL50._sqlTable():
- riga 2048: aggiunto carattere "," al termine del commento.
- eliminata istruzione:
IIf(oField <> data.GetValue("Fields")[data.GetValue("Fields").Count - 1], ",", "")&
pgSqlExport._openFile():
- righe 151 e 160: inserito una spazio dopo i primi due caratteri --
MySQL interpreta tutto ciò che segue "--" come commento, senza lo spazio ottieni un errore Sql Syntax Error
Con le suddette modifiche l'esportazione su Video e su File funziona perfettamente, ho eseguito l'importazione del file .sql tramite phpPgAdmin e il DB è stato popolato correttamente.
L'esportazione su Database fallisce a causa del diverso utilizzo dei metodi _preSql e _postSql.
Mentre per l'esportazione su Video o File viene eseguito il metodo _output() che scrive su video o stream il contenuto dell'array ritornato dai metodi, l'esportazione su Database apre una connessione, esegue la query con le sql dei metodi e chiude la connessione; così facendo i comandi si perdono in quanto le Server System Variable corrispondenti sono di tipo Session Scope e quindi riacquistano il valore predefinito ad ogni connessione.
Per ovviare al problema credo si debbano inserire i comandi nell'array $Data i cui item vengono eseguiti in un'unica connessione.
La buona notizia é che dalla versione 5.5 entrambe le variabili sono sia SESSION che GLOBAL.
Vedrò le tue modifiche e vedrò di applicarle al sorgente. Data la differenza nel reperimento delle info con PostgreSQL, probabile anzi sicuro, che abbia scritto qualche sciocchezza... :-\
La riattivazione dei due nuovi metodi PRE/POST, a mio avviso, funziona solo se imposto la procedura in modo da non perdere la sessione, e la cosa al momento non è attuabile... Si vedrà in seguito come definirla... L'output su file funziona perchè non soggetto a problemi di sessione ma l'ho disabilitata per una questione di forma...
Ti faccio sapere quando aggiorno il repository!!!
BEL LAVORO!!! :ok: GRAZIE!!!
Ho applicato le tue modifiche, ma ho disattivato le funzioni PRE/POST nellexport su database. Questo al momento per evitare l'errore.
Vedrò poi come fare per inserire correttamente la logica...
Repository aggiornato!
Concordo sulla disabilitazione delle funzioni pre/post su db.
Un piccolo aggiornamento sempre sulla classe pgMySQL50. La riga 2071 deve essere modificata da :
IF (NOT data.IsNull("Option")) AND IF (data.GetValue("Option") = "UNIQUE") THEN
IF (NOT oIndex.IsNull("Option")) AND IF (oIndex.GetValue("Option") = "UNIQUE") THEN
E' certamente superfluo aggiornare il repository solo per questo, puoi inserire la modifica e tenerla "al caldo" per il prossimo upload,
Il repository e nuovamente aggiornato. Due versioni nella stessa giornata... mò basta... :D
A presto...
OK!
Riga 2070 e successive... l'errore era pure nelle successive... :-\
IF (NOT oIndex.IsNull("Option")) AND IF (oIndex.GetValue("Option") = "UNIQUE") THEN
s &= pgHtml.HighCommand(" CONSTRAINT UNIQUE INDEX", {html})
ELSE
s &= pgHtml.HighCommand(" " & IIf(NOT oIndex.IsNull("Option"), oIndex.GetValue("Option"), "") & " INDEX", {html})
END IF
l'errore era pure nelle successive... :-\
...ma se non ce ne fossero io che ci sto a fare? :coder:
Analizzare il codice di pgDesigner per scovare gli errore è un ottimo esercizio!
Solo che dopo dovrò eliminarti... ;D
Poi magari scopri che non sò programmare... (ed è pure vero...) ;D
dunque...MySQL ha pubblicato la 5.6, PostgreSQL ha rilasciato la 9.1 beta...
forse posso stare tranquillo per qualche settimana... ;D
Ho notato un comportamento errato del CheckBox "Null" nella maschera Edit Field del driver MySQL; ogni qualvolta apri la maschera, questo risulta impostato a true, indipendentemente dalla impostazione salvata. Tale comportamento è determinato dal metodo pgPaneleditField._new() che alla riga 108 legge il valore impostato, ma alla riga 112 lo sovrascrive basandosi sul valore del CheckBox "Primary Key".
Di fatto:
- se il campo è una chiave primaria il "Null" sarà sempre FALSE (Corretto)
- se il campo NON è chiave primaria "Null" sarà sempre TRUE (Sbagliato)
inoltre modificherei le righe da 313 del metodo MYSQLEvent_Click() nella forma seguente
CASE .MYSQLPrimaryKey 'The enable the primarykey check then force enabled of check on null.
IF (.MYSQLPrimaryKey.Value) THEN
.MYSQLNull.Value = FALSE
.MYSQLNull.Enabled = FALSE
.MYSQLUnique.Value = TRUE
ELSE
.MYSQLNull.Enabled = TRUE
.MYSQLUnique.Value = FALSE
END IF
cose ne pensi?
Questo perchè il campo "Null" identifica appunto la possibilità di inserire valori NULL. Infatti, a seguito delle tue ultime modifiche, avevo notato un cambio di impostazione su una IIF(), ed è quindi probabile che abbiamo errato nell'interpretazione. Nella form, questo campo dipende dall'impostazione della Primary Key che, se impostata a TRUE, forza il divieto di inserire valori NULL. Io direi di ripristinare la IIF() come era prima.
Inoltre, sulla base di quanto detto, bisogna anche forzare le checkbox a seguire le impostazione della chiave primaria, ovvero:
se la Primary Key è TRUE:
1) togliere il check nel campo NULL
2) forzare il check nel campo UNIQUE
se invece la Primary Key è FALSE:
1) rendere liberi i due checkbox, permettendo l'impostazione a libertà dell'utente.
Dimmi se la logica è corretta...
P.S.: in questo momento ho aggiornato il repository, con le ultime modifiche e con l'aggiunta dei driver per le versione MySQL 5.1 -> 5.6. In questo caso è possibile selezionare il database corretto, e fare aggiornamenti di conseguenza sul db.
Dato che a volte mi rispondo da solo, ho già fatto le modifiche che ho descritto, e ho aggiornato il repository.
Fammi sapere se la cosa ora ti suona...
modifiche approvate... ;D
resta in sospeso la gestione dei metodi PRE/POST che ho visto hai lasciato disabilitati.
Per il db, sì...
Stavo però pensando che si potrebbe inserire le due funzioni per ogni comando che invio al db, credo dovrebbe funzionare in egual modo... che ne dici?
Esempio:
1) invio le stringe PRE
2) invio la stringa di creazione del singolo oggetto
3) invio le stringhe POST
in effetti lo avevo pensato, ho verificato sulla documentazione e dovrebbe funzionare.
In realtà dovrebbe funzionare anche inviando la sola stringa PRE, essendo il comando valido solo per la sessione.
1) invii le stringhe PRE
2) invii la stringa di creazione oggetto
3) chiudi la connessione.
...
1) invii le stringhe PRE
...
Intanto beccati quaest'altro grattacapo:
nel driver MySQL per il campo ENUM bisogna prevedere la possibilità di inserire l'elenco delle enumerazioni, come già per PG, e correggere la sintassi del metodo _sqlTable. Credo abbiamo due strade percorribili:
1. Intercettare il tipo "ENUM" nell'evento MYSQLEvent_Change() ed aprire una griglia pr l'inserimento della enumerazione.
2. Utilizzare il TextBox Default, magari modificando la label al volo, per inserire l'enumerazione. In questo caso si deve controllare che l'utilizzatore non inserisca le parentesi tonde, e posizionare il contenuto della textbox immediatamente dopo il nome di campo.
Create table ...
stgione ENUM("estate","inverno","autonno","primavera")...
approffitando del ponte magari provo a scrivere del codice che valuterai.
Ho aggiornato or ora il repository...
Devo avvertirti che ho stravolto un mucchio di roba...molto codice... :-[
Nelle varie cose ho corretto qualcosina, ho aggiunto qualche altra, e cambiato molto codice.
Il perchè?
1) diciamo che sono un pò pazzo, e quando le cose non mi piacciono, prendo e stravolgo tutto
2) finora sono stato preso dall'obiettivo, ma avevo tralasciato molte cose e molte caratteristiche di Gambas che ora ho cercato di implementare. Una fra le tante è l'uso intensivo della logica degli eventi, che avevo un pò preso sottogambas ;D , e non l'avevo approfondita più di tanto. Inoltre ho cercato di implementare logiche Java-like, almeno per quanto riguarda il controllo più approfondito degli oggetti. Al momento ho buttato giù una sorta di scheletro, che mi servirà per ottimizzare il codice in futuro.
3) ho cercato di pulire il codice da cose non proprio ottimali o non necessarie, che avevo continuato ad aggiungere nonostante l'esperienza fatta con la precedente versione.
Insomma, dopo tutto lo stravolgimento, il programma funziona ancora (forse meglio), ma è ancora lungi da considerarlo finito. Di idee ne ho parecchie, ma dovrò darmi alla fine un punto di stop.
Nel frattempo ho docuto mettere qualche toppa al vecchio 1.x, a seguito di qualche segnalazione. Ho comunque ricevuto anche segnalazioni per questa versione Beta, il che vuol dire che già la usano...
diciamo che sono un pò pazzo,
io toglierei un pò! ;D
Mi sembra di giocare a Monopoli, adesso che ero riuscito, almeno in parte a penetrare la logica di pgdesigner2, mi tiri fuori la carta Imprevisto e mi toccano tre giri di stop. :o Che dire...Genio e sregolatezza...
Ad una prima occhiata mi pare che tu abbia fatto un grosso lavoro di riassesto. La nuova strada, gli eventi, renderanno più fluido il programma migliorando l'apporto di modifiche in futuro.
Dalla prima prova effettuata mi pare ci sia però un problema con l'evento menu. se apri un menu popup su qualunque ogetto del database e immediatamente dopo fai click (tasto sinistro) all'esterno di esso il menu popup non si chiude, devi eseguire un secondo click per chiuderlo.
Infine una curiosità: perché costruire la MainWindow da codice e non da IDE?
Mi dispiace, ma quando mi piglia la mattana sò peggio di un dio cattivo, piglio e spiano tutto... ;D
Con pgDesigner l'ho fatto così tante volte che manco ricordo...
Comunque...
1) Il menu popup avevo notato che faceva la stessa cosa pure prima, e devo quindi trovare il perchè del problema
2) lo spostamento degli oggetti grafici, sempre se di una determinata semplicità, per avere un maggio controllo su di essi, ho preferito gestirli a codice. Se hai notato, ho anche spostato tutti i relativi eventi in pgApplication, e eliminato molti metodi ridondanti.
Tra le idee, e per eliminare gli sbagli iniziali, vorrei poter impostare i vari oggetti in modo indipendente. Ci sono alcune cose di Gambas che solo da poco ho compreso bene, e vorrei eliminare tutte le cose che sono stato costretto a fare a causa della mia ignoranza.
Comunque...
Alla fine la logica nel suo complesso non è cambiata... praticamente ho solo cambiato le posizioni e totolto alcune duplicazioni e ridondanze.
Inoltre, e l'avrai notato, ho implementato una logica che permette di controllare più nel particolare le modifiche delle varie proprietà degli oggetti. Questo mi permette anche di gestire al meglio la parte eventi.
Infine...
Mi dispiace di aver causato un pò di trambusto, ma spero che ora il programma si immetta su una strada più ottimale... lo spero...
Ha impiegato un po di tempo...ma ecco la traduzione francese. (mi ha garantito di avere fatto il meglio che poteva).
Ciao e a presto.
Ma lo sà che non prende 'n euro ? ;D
Ma stai scherzando? Magari trovassi qualcun'altro per tutto il resto che manca ancora da fare.
Ora lo inserisco nel progetto!
Thanks!!!! :-*
A proposito! Se mi dà il nome lo inserisco nell'elenco contributori... sempre se vuole...
lo sa, lo sa... è stata la prima cosa che gli ho detto.
Per quanto riguarda il nome gle ne avevo accennato a suo tempo, ora glie lo rammento.
Gian Piero "GPL" Lagori gpl@yopmail.com
Stasera lo inserisco nel "secchio" ... ;D
Ho caricato il file ed è ito bene, ma è probabile servano dei ritocchi, in quanto nella traduzione di alcune stringhe non sono stati inclusi gli "&" (es. i menu). Per il resto pare a posto...
Un ringraziamento enorme al tuo amico!!!!
Se vuoi, per non distogliere la tua attenzione dal codice, l'inserimento dei codici lo posso fare io.
Fammi sapere
Bè, l'importazione del .po l'ho fatta.
Devi attendere l'aggiornamento del repository che spero di farlo stasera...
P.S.: a parte il codice di pgDesiggner2, stò facendo esperimenti con OpenGL che, se vanno per il verso giusto, potrebbe sostituire la gestione grafica del programma... il che, oltre alla velocità, andrebbe ad arricchirne le potenzialità...
Bè, l'importazione del .po l'ho fatta.
Devi attendere l'aggiornamento del repository che spero di farlo stasera...
P.S.: a parte il codice di pgDesiggner2, stò facendo esperimenti con OpenGL che, se vanno per il verso giusto, potrebbe sostituire la gestione grafica del programma... il che, oltre alla velocità, andrebbe ad arricchirne le potenzialità...
scusa se mi 'intrometto' ma ti riferisci alla possibilità di creare una form grafica di creazione query stile access?....si lo ammetto sono stato accessizzato in passato...
In realtà ci stavo pensando, e stavo dando un'occhiata ai sorgenti di quello fornito con l'ide di Gambas.
Avevo pensato ad un progetto del genere, richiamabile anche da pgDesigner...
Il problema è che di idee ne ho, è il tempo che manca... :'(
In realtà ci stavo pensando, e stavo dando un'occhiata ai sorgenti di quello fornito con l'ide di Gambas.
Avevo pensato ad un progetto del genere, richiamabile anche da pgDesigner...
Il problema è che di idee ne ho, è il tempo che manca... :'(
io faccio la libera professione, sto girando due miei applicativi su g3, ci sto investendo del tempo, mi servono.
Che intendi dire?!?
Tanto per riavvivare questa discussione, un'anticipazione: Stò lavorando ad un motore per pgDesigner, che sfrutta le potenzialità di OpenGL.
E' un pò ostico da digerire, ma già qualcosa stò intravedendo, e predisponendo per sostituire l'attuale parte grafica con una sicuramente più performante.
Ci sono però alcune mancanze:
- gestione del testo (al momento gestire a livello di texture da immagini create prima su oggetti Image di Gambas)
- l'attuale implementazione della libreria OpenGL (sia da sola che con il supporto dell'oggetto GLArea) non mi permette di gestire più finestre (o pannelli) diversi, con rappresentazioni diverse del grafico (es. una minimappa classica). E' molto probabile che sia una mia mancanza, ma dato che le funzionalità di OpenGL sono gestite da una classe statica, è probabile che renda questa cosa impossibile.
Se qualcuno, con esperienza diretta con le OpenGL, può darmi una mano a capire le mie lacune lacunose... è il benvenuto!!! :-*
Quindi la parte di gestione delle strutture non sarà ulteriormente modificata? Significa che i miei test possono proseguire? Purtroppo sono un poco rallentato da problemi di altra natura, ma non intendo assolutamente abbandonare il progetto.
Diciamo che questi sono esperimenti che, se vanno come devono andare, potranno sostituire la sola parte grafica, ovvero il motore grafico, del programma.
La logica non verrà toccata, o perlomento si avrà qualche piccola variazione su alcuni dati che andranno a popolare i file di progetto, quali ad esempio le ccordinate grafiche dei singoli oggetti nei diagrammi. Questo sarà obbligatorio, in quanto il motore grafico applica concetti un pò diversi da quelli attuali.
Dalle mie prove, la velocità e la gestione grafica sono ovviamente superiori con l'uso di OpenGL. Un handicap, su cui dovrò studiare un pò, è la possibilità di gestire più pannelli OpenGL contemporaneamente (ad es per una minimappa, come esiste tuttora).
Al momento ho risolto in parte l'assenza di una libreria per la gestione del testo in OpenGL, usando le texture, ma la loro rappresentazione non mi soddisfa. Sicuramente toccherà impostare qualche specifico parametro, ma non l'ho ancora trovato.
Infine, data anche l'assenza di funzioni di esportazione e stampa in OpenGL, ho implementato io alcuni metodi per poterlo fare, ovviamente usando le stesse basi per la creazione degli oggetti grafici, ma passando per le funzioni base di disegno di Gambas (tanto per intenderci la classe statica Draw).
Comunque, questo studio lo stò facendo sula base di Gambas3, per ovvii motivi, e questo mi obbligherà a fare necessariamente il porting di pgDesigner2 su questa versione. La cosa non sarà immediata, ma non stravolgerà le funzionalità attuali del programma, quindi non preoccuparti... :)
Tieni conto, comunque, che l'applicazione definitiva di queste modifiche su pgDesigner non sarà a breve...
Stato corrente:
- testate le funzionalità di OpenGL (tramite ovviamente le librerie incluse in Gambas2), e diciamo che, a parte la velocità di esecuzione su cui nulla da eccepire, ho avuto qualche problema nell'implementazione in pgDesigner2. In alcuni casi le OpenGL diventano alquanto laboriose in termini di codice e, nonostante abbia in qualche modo cercato di standardizzare le funzioni sulla base del suo utilizzo in pgDesigner, mi sono fermato nei test a causa di alcune complicazioni sulla gestione di più GLarea contemporanee.
- ho provato poi ad utilizzare l'oggetto Paint (nuovo con Gambas3), e sono rimasto allibito sulla diversa risposta rispetto al veccho Draw, senza poi tener conto del maggior numero di strumenti che questa classe (e collegate) fornisce. Anche qui ho buttato giù un ambiente di testing, sulla falsa riga di quanto fatto con OpenGL, e sono giunto alla conclusione che l'utilizzo di questa opzione (Paint) sia il miglior compromesso. La velocità grafica è tutta un'altra cosa rispetto a Draw, e l'utilizzo è molto semplice, ma anche molto più dinamico.
Adesso dovrò analizzare l'impatto delle modifiche su pgDesigner2, tenendo presente che questo comporta necessariamente il passaggio su Gambas3.
Nota: i due ambienti di test (con OpenGL e Paint) sono a disposizione come studio se qualcuno lo desidera.
Bye
Su sourceforge?
Hai un link?
No, le prove le ho fatte con progetti locali. Dato che erano solo degli studi, non ho ritenuto opportuno metterli su sf.
Magari stasera, faccio un paio di tar, e li metto in questa discussione...
Non entro spessissimo e rileggo il tuo post sulla nuova versione di pgdesigner, se ti serve aiuto (nei miei limiti) chiedimi...
In questi giorni, nel tempo libero disponibile, stò cercando di convertire pgDesigner su Gambas3.
Mi stà facendo abbastanza impazzire, in quanto le cose cambiate sono molte, e certe cose non esistono pure più, per cui mi devo inventare alternative valide.
Tutto questo per poter accedere alle migliori funzionalità della nuova versione che, come ho scritto nelle precedenti, mi sarebbero molto di aiuto.
Ti ringrazio per l'offerta ma, dato che nel repository sourceforge c'è già la versione 2 di pgDesigner, e non voglio sporcarla con le procedure di conversione finchè non vedo che và tutto, non ho modo di farti entrare per contribuire allo sviluppo.
Pensavo fosse qualcosa di più semplice e, nonostante sia stata migliorata la procedura di conversione dei progetti in Gambas3, il 90% tocca gestirlo a mano, tenendo presente che molti concetti sono cambiati, e quindi tocca rivedere alcune logiche.
C...avolo (mi autocensuro...)!!!???!!! :evil: >:( (e altri smile a scelta...)
Stò impazzendo, la conversione è a dir poco un "riscrivere" tutta l'applicazione. Le logiche sono cambiate completamente, l'interpretazione dei parametri è completamente diversa e segue una dinamica tutta particolare (stò parlando della versione da repository presa due giorni fà). Le variabili su oggetti si comportano in maniera anomala, diversa da come era intesa prima con la versione 2, insomma, faccio prima a rifare tutto pgDesigner2 (cosa per altro che stò già iniziando...).
Resoconto: mettere mano a quanto fatto finora credo sia ormai una cosa altamente negativa (non funge nulla...), per cui in questo momento ho deciso che la versione pgDesigner2 si fermerà all'ultima release di Gambas2, e di conseguenza parto a fare la pgDesigner3 su Gambas3.
Intendiamoci, a parte qualche logichetta che non capisco perchè è stata stravolta, tutto il pacchetto Gambas3 è notevolmente cambiato, e in meglio.
A questo punto, visto anche l'approssimarsi del rilascio definitivo, mi metterò a lavorare solo sulla 3.
Dopo aver tentato di intraprendere la strada della conversione pgDesigner2 (ancora in fase BETA) in Gambas3, e di aver fatto prove con le librerie OpenGL, alla fine sono giunto alla conclusione che forse è il caso di studiare la cosa partendo nuovamente da zero, o quasi.
Dopo aver costruito un ambiente di test, ho iniziato a costruire la versione pgDesigner3 che, oltre al numero ad indicare il passaggio a Gambas3, mi permette di riscrivere un codice più pulito e funzionalmente più fluido. Le nuove caratteristiche della nuova versione di Gambas3 (che spero esca a breve) alla fine mi permettono di scrivere un qualcosa di meglio. E' ovvio che gli errori fatti nel passato, le incomprensioni con alcuni aspetti del linguaggio, e l'esperienza acquisita mi saranno molto utili per questa nuova versione.
Per l'appunto, nelle fasi di test con l'ambiente di prova, ho appurato molti aspetti graditi, in particolare per l'aspetto grafico (vedi Paint).
A seguito di questo, ho potuto costruire una libreria di base che ho già agganciato alla struttura iniziale dell'applicazione, che è già in lavorazione e inizia pure a funzionare alla grande (il che non è poco...).
Ho prestato molta cura nella gestione degli oggetti, e in particolare nell'intercettazione degli eventi (nativi e costruiti), che mi permette di avere un maggiore controllo sullo stato applicativo. Questo e altro sono stati aspetti non molto approfonditi da me nel passato, e ad ogni modo non erano poi così ben impostati nelle versioni precedenti di Gambas. Adesso pare che la cosa funzioni a dovere, per cui lo studio ha avuto il successo sperato.
Al momento sono nella fase di creazione della base del progetto, ovvero l'applicazione, a cui ho già agganciato la parte grafica (la libreria di cui sopra...). La cosa stà già funzionando, ma occorrerà un pò di tempo e studio per implementarla in modo completo e pulito. La parte di gestione dei database non è ancora stata aggiunta, in quanto devo ricostruire una libreria più dinamica di quelle precedenti, tenendo presente che vorrei fare in modo che sia il più possibile scalabile verso più rdbms. Già con pgDesigner2 avevo aggiunto la possibilità di gestire i tre db più noti soto Linux, ovvero PostgreSQL, MySQL e SQLite, ma l'idea sarebbe quella di poter in futuro espandere questa possibilità, magari integrando motori tipo Oracle o ODBC.
Ad ogni modo, ho aggiunto queste note nel forum sperando che qualcuno possa aiutarmi in qualche modo, magari anche con suggerimenti vaqri. Già l'amico sotema ha avuto modo di aiutarmi nei test negli ultimi periodi, che mi ha permesso di migliorare alcune cose di pgDesigner2 ma, visto l'esito dei miei tentativi di porting, ho deciso di riscrivere tutto ex-novo, ovviamente servendomi della base di codice già fatta, e delle logiche.
Se qualcuno ha possibilità, i sorgenti sono disponibili su sorceforge, e può utilizzare il seguente comando per scaricarseli sul proprio computer:
svn checkout https://pgdesigner.svn.sourceforge.net/svnroot/pgdesigner/pgdesigner/branches/3.0-alpha pgDesigner3
Nel caso a qualcuno interessi, è possibile anche scaricarsi il mio fallito tentativo di porting:
svn checkout https://pgdesigner.svn.sourceforge.net/svnroot/pgdesigner/pgdesigner/branches/2.0-G3 pgDesigner2-G3
Inoltre, ricordo che è sempre presente anche la versione BETA di pgDesigner2:
svn checkout https://pgdesigner.svn.sourceforge.net/svnroot/pgdesigner/pgdesigner/branches/2.0
Bye
Detto, fatto.
Aspettavo questo evento. Ho scaricato ora la versione 3. Da domani ci guardo
Buon lavoro
Meraviglioso!!! :D
Come ho scritto nella precedente, per ora è in costruzione solo la parte interfaccia grafica, per cui nessuna funzionalità db...
Per quella ci devo studiare sopra, perchè come l'avevo impostata era di difficile manutenzione e implementazione.
Un paio di note per l'utilizzo:
1) creando un progetto, si apre una tab, in cui sulla destra è presente come nelle precedenti versioni un navigatore. Solo alcune funzione sono già attive, tra cui lo zoom e la creazione di alcuni oggetti. Ho abilitato il drag&drop, che è fattibile per tutti tranne che per le relazioni. Per creare una relazione basta cliccare sul relativo pulsante e poi premere il destro del mouse sul primo oggetto di tipo tabella presente nella canvas, dopodiche tenere premuto il destro fino alla seconda tabella. Se, per caso, gli oggetti puntati non corrispondono a tabelle avrai un messaggio di errore e l'esecuzione della relazione viene abortito.
2) il tab principale, ovvero quello dei progetti, ha un suo menu popup (tasto destro), come anche il tab relativo ai canvas. Ogni progetto ha un suo conteiner, come anche ogni canvas. A differenza delle precedenti versioni, ho adottato un sistema separato perchè più gestibile e perchè ogni classe fà per se, lasciando all'application di gestire i soli eventi comuni a tutti e quelli di gestione della main form.
3) Dipedentemente dal tipo di oggetto che viene creato, è possibile effettura anche ridimensionamenti direttamente sulla canvas. Se abilitato, il puntatore del mouse cambierà aspetto in corrispondenza dei bordi dell'oggetto. Dato che il bordo considera un solo pixel di margine, il puntamento potrebbe risultare un pò difficoltoso.
4) Le relazioni si possono effettuare in diverse modalità grafiche. Al momento ho abilitato la modalità multilinea verticale. Tieni conto che ho anche creato la possibilità di modificare graficamente (con il mouse) i segmenti della linea. Posizionando il mouse sopra le varie rotture, si visualizzerà un pallino. Cliccandoci sopra si potrà trascinare lo spigolo in modo da adattarlo ai propri desideri. E' ovvio che se viene spostato uno degli oggetti in relazione, la linea riprenderà la forma di default.
La velocità con cui Paint disegna è veramente notevole. E' quasi paragonabile a OpenGL (quasi...), e utilizza algoritmi di disegno lontani anni luce dal vecchio Draw. Questo almeno da quanto verificato finora. Devo però dire che Gambas3 occupa parecchia memoria in fase di esecuzione e ho notato che in ambiente IDE, a volte conviene chiudere tutto e riaprire l'ambiente perchè il sistema tende a rallentamenti che rendono Gambas3 praticamente inutilizzabile. Ho 8Gbyte di ram e un QuadCore, per cui la cosa un pò mi spaventa, ma spero che l'eseguibile finale non sia affetto da questo tipo di problemi.
Ho fatto le prime prove e come è giusto aspettarsi in questo stadio ho riscontrato alcuni problemi.
1. in pgActionManager configuri le azioni di Menu e Pulsanti passando i parametri alla SUB _action(...); purtroppo in gambas3 il parametro
text viene visualizzato nei pulsanti, cosa che non succedeva con gambas2. Credo tu debba utilizzare due metodi separati, uno per i Menu
ed uno per i pulsanti. Questo vale sia per il toolbox che per i pulsanti di menu.
2. Creata la prima tabella non ho capito come popolarne i campi.
Quello delle azioni è un problema che ho già visto, ma al momento ho tralasciato, quindi lo vediamo più tardi...
Riguardo le tabelle, come ti avevo accennato, ma forse non ero stato chiaro, non c'è ancora una gestione vera. In realtà ci sono già le funzioni per poter gestire i campi, ma non le ancora attivate.
Se provi a eseguire la form di test, sotto graphic, vedrai che ho creato un mucchio di funzioni ad-hoc, tra cui pure quelle per le tabelle. Inoltre ce ne sono molte altre per le linee, di relazione e non, con varie particolarità.
La finestra di test fà vedere parecchie delle caratteristiche della libreria, ma non tutte, solo quelle più evidenti. Se poi dai un'occhiata al codice dell'oggetto PgCanvas, potrai fartene un'idea. La cosa bella è che il tutto è espandibile, dato che ogni oggetto viene definito di aposite classi indipendenti dalla canvas. Alcune, come ad esempio le linee e le relazioni, derivano da oggetti comuni.
OK,
mi aveva tratto in inganno il discorso circa le relazioni.
Ho dato un'occhiata al codice, constatando che utilizzi classi e metodi specializzati per le singole azioni. La struttura mi appare più lineare ed ordinata rispetto alla versione 2 e capisco cosa intendi quando parli di espandibilità. La velocità con cui gli oggetti vengono disegnati è notevolmente superiore.
Gli oggetti vengono disegnati ogni volta con una dimensione diversa, mi chiedo se è voluto; magari mi guardo il codice...
Accade solo nella form di test.
Ho notato anche che fai ampio uso dei metodi speciali e mi è tornato alla memoria un messaggio di alcuni mesi orsono nella Mailing List.
Il messaggio riguardava l'utilizzo del metodo _unknown con le Proprietà. Per brevità ti cito solo la soluzione finale introdotta da Benoìt:
Here is the solution I propose:
A new special method, named "_property" must be implemented if you want to
handle unknown properties.
This function takes no argument, and must return a boolean. The name of the
unknown symbol is stored in Param.Name, and the function must return if the
symbol is actually a property or not (i.e. a method).
If _property is not implemented, all unknown symbols are methods.
Confesso che i metodi speciali, e non solo quelli, sono un argomento parecchio oscuro per me, non so se tutto ciò potrebbe rappresentare un problema latente con il tuo codice
Public Sub _unknown(...) As Variant
If (Param.Count = 0) Then
Me.RaiseUnknownProperty(Param.Name)
Else
Me.RaiseUnknownMethod(Param.Name)
Endif
Return Null
End
A presto
Riguardo alle dimensioni, la gestione è stata implementata volutamente nella form di test che, se vai a vedere il codice, utilizza un random per generare sia le dimensioni, che la posizione iniziale e il font. Mi è servito per verificare il comportamento delle funzioni di ridimensionamento e gestione degli oggetti grafici, in particolare le form, che devo contenere poi svariate righe (i campi).
Per quanto riguarda i metodi nascosti li ho utilizzati già dalle prime versioni di Gambas2. In verità ne ho utilizzati solo alcuni, in quanto mi riportavano alle logiche implementate in altri linguaggi, ovvero quelle riguardanti i metodi di costruzione e distruzione di un oggetto.
In gambas è stato implementato un sistema che permette di catturare eventuali chiamate errate, e qui torna utile il metodo _unknown. Tempo fà l'avevo studiato un pochino, ma con la versione Gambas3 ho voluto approfondire, e poi l'ho applicato. In realtà credo non sia ancora veramente completo, per cui, come hai ben notato, ho dovuto scrivere due righe di codice per capire se l'errore riguarda un metodo o una proprietà. Come si nota dal codice che hai postato, faccio una verifica se ci sono parametri, se questo è vero vuol dire che è una chiamata ad un metodo, altrimenti è una call ad una proprietà. E' possibile che vi siano alcune eccezioni a questo, ma la cosa a poca importante per ora, perchè mi serve solo per catturare l'anomalia e, eventualmente, loggarla da qualche parte.
La cosa, ovvero la cattura di chiamate errate, sarebbe utile solo in caso di costruzione dinamica di oggetti, ma dato che in Gambas3 hanno modificato qualcosa nelle fasi di compilazione, spesso e volentieri il compiler non si accorge di eventuali riferimenti errati, se questi si riferiscono a metodi contenuti in altre classi. Non sò se questo verrà risolto, ad ogni modo ho utilizzato questo metodo per scongiurare eventuali anomalie.
Se dai un'occhiata più a fondo nel codice, noterai pure altre implementazioni, che ho migliorato e specializzato rispetto a prima. Gambas non ha mai avuto una vera gestione degli errori, e il controllo viene fatto in modo nativo, non permettendo di trattare in maniera più dinamica la cosa, ad esempio catturando gli errori e loggarli da qualche parte. Dopo l'esperienza fatta in precedenza, ho voluto approfondire la cosa, cercando di integrare una logica che mi permettesse di gestire gli errori applicativi con specifiche classi, indi per cui loggarli su un file e/o messaggiarli a video. Credo di esserci riuscito in qualche modo, e pure in modo pulito. Riguardo poi al log, ne ho fatto una classe specializzata, e pure credo funzionale, e utilizzabile in qualsiasi altra applicazione.
Insomma, l'idea è quella di fare una cosa pulita e dinamica, anche a costo di metterci più tempo, e che possa essere presa e utilizzata per altri programmi, magari solo estrapolando determinate funzionalità (es. appunto il logging di cui sopra).
Ti ringrazio per i tuoi appunti, perchè mi servono per capire se stò andando per la giusta strada. Eventuali idee, o spunti, o pezzi di codice, che potrebbero venirti in mente, fammelo sapere! Oltre ovviamente a eventuali stupidaggini trovate nel programma... ;D
NOTE: Ti faccio presente che aggiorno il repository quasi ogni giorno, perchè stò lavorando al progetto nei frammenti di spazio che ho a disposizione. Questo anche perchè ho agganciato il progetto direttamente al repository di sourceforge, anzichè collegarlo al mio server svn. In definitiva ho applicato in modo inverso la logica che ho utilizzato finora per i miei progetti. Questo mi permette di lavorarci sia a casa che sul lavoro quando ho un pochino di tempo.
Ciao md9327,
dopo parecchio tempo ho ripreso in mano il codice di pgDesigner3. La versione scaricata oggi è la 468.
L'esecuzione si blocca alla splash form, credo poichè in pgApplication alla linea 171 è scritto:
With splashDialog = New PgDialogSplash As "DialogSplash"
così facendo l'evento timer non si scatena mai. Dovresti gestire l'evento DialogSplash_Timer oppure, visto che la sola funzione dello splash screen è la segnalazione di avvio applicazione, eliminare il gestore eventi dalla linea 171
Sempre in pgApplication alla linea 111 crei il percorso per i dati temporanei; se il tuo intento è quello di creare il direttorio "temp" all'interno di ".pgDesigner3" l'istruzione dovrebbe essere:
PgFile.CreatePath(File.Dir($configPath &/ "temp/"))
altrimenti la cartella non viene creata.
In pgFile modificherei la funzione CreatePath alla linea 17 in:
Dim list As String[] = Split(path, "/", "", True)
in questo modo eviti di avere un valore nullo in list[0]
Ho notato che ogniqualvolta attivi un'azione dal menu o dalla MainBar al termine della esecuzione si scatena l'evento Unknown Method Action_Activate. E' probabile che ciò sia dovuto alla gestione delle action di Gambas. Indagando sulla cosa ho scoperto però un problema nella gestione dei metodi _unknown() che utilizzi per registrare nel log l'evento; nelle sub ***_UnknownMethodEvent({method} As String) utilizzi la seguente istruzione:
$logManager.Write(PgLogMessage.Error(Object.Type(Last), "Unknown Method <" & {method} & ">"))
Potersti sostituire la riga con:
$logManager.Write(PgLogMessage.Error(Object.Type(Last), "Unknown Method: <b>" & {method} & "</b>"))
$logManager.Write(PgLogMessage.Error(Object.Type(Last), "Unknown Method: <i>" & {method} & "</i>"))
Lo stesso dicasi per le sub ***_UnknownPropertyEvent({property} As String)
Infine una curiosità, perchè non utilizzare una sub unica di gestione tipo:
Static Private Sub _unknownMethodEvent({method} as string)
$logManager.Write(PgLogMessage.Error(Object.Type(Last), "Unknown Method: <i>" & {method} & "</i>"))
End
In PgApplication._init() hai inserito la gestione degli errori per registrare l'evento nel log e terminare l'applicazione. In realtà a fronte di un errore in questa fase l'applicazione prosegue l'esecuzione del metodo Run chiamato da PgDesigner.Main() scatenando un errore di "Null Object alla riga 581 $timerLogging.Start() e si blocca senza terminare correttamente.
Potresti ovviare impostando una Variabile globale boolean (ad esempio $onError) da settare a true nella Catch, e utilizzarla nella Run all'interno di una struttura IF ... ENDIF
...
Static Private $onError As Boolean
...
...
Static Public Sub _init()
...
Catch
$onError = true
...
e quindi...
Static Public Sub Run()
If (Not $onError) Then
$logManager.Write(PgLogMessage.Info(Me, "Start Application"))
$timerLogging.Start()
If ($configManager.Get(PgConfigManager.CFG_AUTOSAVINGENABLE)) Then
$timerSaving.Start()
Endif
If ($configManager.Get(PgConfigManager.CFG_ANIMATIONENABLE)) Then
$timerAnimation.Start()
Endif
PgApplication.MainWindow.Show()
Endif
End
Nei ritagli di tempo, cerco di mettere mano al codice, ma spesso non ho la testa per farlo e quindi abbandono dopo poco.
Comunque, ho letto i tuoi appunti e anche seguito i tuoi consigli, quindi ti rispondo per punti sui due ultimi messaggi, partendo dal più vecchio:
1) hai ragione sullo splash, e ho corretto il problema. In effetti volevo trasferire il controllo della dialog nell'application, ma poi ci ho ripensato, e ho lasciato la cosa a metà... Devo ancora trasferire le variazioni sul repository...
2) anche sulla directory temporanea c'era l'errore che ho corretto come da tuo suggerimento, e ora funziona.
3) ho modificato anche i messaggi di log, relativi a property e method, mettendo in bold il nome della variabile.
4) riguardo alla creazione dei messaggi (3), ho ritenuto inserirli nell'application, in quanto stò cercando di isolare il più possibile gli oggetti tra loro, e gestire il tutto nella classe Application. In realtà, questo sarà valido in base al layer su cui si trova l'oggetto. Per esempio, la parte grafica sarà gestita dal pannello del progetto, tramite gli eventi, e le funzioni del pannello saranno gestire dall'oggetto PgProject. E' ovvio che, il comportamento degli oggetti Project saranno invece gestiti globalmente da Application, e sempre tramite eventi.
5) in effetti, in caso di errore, la Main non si accorge del problema, e manda in esecuzione Run(). Come da tuo suggerimento ho provveduto ad inserire una variabile privata static in Application, che controlla eventuali crash nell'Init, bloccando le fasi operative dell'oggetto. Il metodo Close() intercetta questa variabile e, se false, esegue tutte le procedure di chiusura normali o, se false, evita di farle. Ovviamente blocca i timer. Nel metodo Run fà la stessa cosa.
Ti ringrazio per l'aiuto che, come vedi, mi è di essenziale.
Al momento stò lavorando sulla costruzione dei driver di database, e i relativi oggetti, senza ancora integrarli con la parte grafica. Stò cercando di evitare l'eccessiva inherenza delle classi che, come avrai notato nella versione 1 e 2, stava un pò andando fuori controllo. Purtroppo, ma anche per fortuna, i database si evolvono, e escono sempre release nuove. Il problema è stargli dietro, ma senza esagerare. I limiti di Gambas sull'integrazione delle classi, mi porta a fare cose un pò fuori regola, causando un problema nella gestibilità e manutenibilità degli oggetti.
Ad ogni modo, la versione 3 ha parecchie belle cosette, e con questo progetto stò cercando di capirle e integrarle. Vediamo se riesco completamente nell'intento.
Perdona il ritardo
ma ti pare. Anche per me questo è un periodo critico, e poi mica hai una data di consegna per pgDesigner...
Sono contento di poterti aiutare.
Al momento sto studiando il codice e mi limito a testare le funzioni implementate alla ricerca di eventuali errori. La logica degli eventi che stai utilizzando mi risulta un poco difficile da seguire, con tutti quegli Osservatori che ci sono. A volte mi perdo.
Comunque ogni qualvolta riscontro un problema te lo segnalo, in modo che tu possa correggerlo al prossimo aggiornamento, o inserirlo in una lista todo.
Nella procedura PgApplication.OpenDialogConfig è presente un errore nelle istruzioni:
IF(dlg.ISModified ...) then
Essendo parecchie le correzioni allego la sola procedura già modificata.
Sempre in OpenDialogConfig, alla linea 1625 salvi la configurazione della lingua, richiamando la procedura PgLanguageManager.FindDescription(...) che non essendo Static genera errore. In effetti nessuna delle procedure in PgLanguage è definita Static.
Ho anche notato che alla creazione di un nuovo progetto questo non viene inserito nell'array $project di PgProjectManager, è una scelta voluta?
Per oggi basta.
:coder:
Stasera vedo gli errori nella dialog e la lingua.
Riguardo i progetti, al momento è in piedi un abbozzo che mi serve solo per testare la parte grafica. Infatti, non creo alcun progetto, nè oggetti database, oltre al fatto che ho anche disabilitato le relative voci nel menu e nella toolbar.
Rev 473
PgApplication.OpenDialogConfig()
la linea 1555 devi modificarla da:
$configManager.Set(PgConfigManager.CFG_LANGUAGE, PgLanguageManager.FindDescription(Str(dlg.GetValue(PgConfigManager.CFG_LANGUAGE))).Code)
$configManager.Set(PgConfigManager.CFG_LANGUAGE, $languageManager.FindDescription(Str(dlg.GetValue(PgConfigManager.CFG_LANGUAGE))).Code)
Era un refuso, in quanto avevo iniziato a pensare PgLangaugeManager come classe statica, poi ci ho ripensato.
Nell'ultima versione aggiornata ieri, noterai che ho riscritto la gestione dei log e degli errori. Ora PgLogManager e PgErrorManager sono statiche, a cui aggancio delle classi handler apposite.
Diciamo che stò prendendo spunto dalla logica delle classi Java, in particolare ho tradotto in parte il pacchetto Log4J, che è il più utilizzato con questo linguaggio, ed è abbastanza dinamico.
Per gli errori, la cosa che manca a mio avviso in Gambas, è la possibilità di derivare classi personalizzate dalla Error. Così com'è impostata, oltre che statica, è molto limitante.
Ciao, ufficialmente finito il periodo di letargo, eccomi di nuovo a spulciare il codice di pgDesigner3 che ho notato hai sviluppato principalmente nelle funzioni dei driver.
Prima dell'inverno ci siamo lasciati con una nota sulla gestione della lingua e mi sembra più che giusto ripartire da lì.
Nella fase di inizializzazione della lingua in pgLanguageManager._new() popoli l'array $languages con le specifiche Nome, Codice e Descrizione. Ebbene il parametro Codice deve contenere anche il set ".utf8", altrimenti la traduzione non viene caricata. Stessa condizione sussiste in PgLanguageManager.Initialize() dove aggiungi a $languages le ulteriori traduzioni.
Buon lavoro.
Se non vado errato (non ora il codice sottomano, vado a memoria), il secondo parametro lo estraggo dalla lingua di sistema.
Questo anche perchè non vorrei censire tutte le estensioni di lingua all'interno del programma.
Ad ogni modo, tieni conto che molte delle funzioni che sembrano già attive, in realtà saranno soggette in futuro ad un vaglio più accurato.
E' un piacere per me che tu ti sia svegliato dal letargo... era ora!!! :evil:
Ehehhe, scherzo ovviamente. :-*
Comunque, è vero che stò lavorando esclusivamente sui diver, il che è di per sè alquanto oneroso. Il fatto è che in questo periodo ho veramente pochissimo spazio libero, sia a causa del lavoro, ma in particolare perchè stò cambiando casa (vendat/acquisto/documenti/notai/etc.etc...). Quindi, la testa non è proprio libera da pensieri, e stò pensando di stoppare temporaneamente lo sviluppo, altrimenti mi ricoverano... A volte mi ci metto per svagarmi, ma poi non è quello che avviene... :-\
Ti capisco perfettamente, anch'io sono alla ricerca di una nuova casa e già il tempo dedicato alle visite è notevole; senza parlare delle proposte indecenti di certi pseudo immobiliaristi. In ogni caso, nel poco tempo libero che mi rimane proverò a scorrere il codice. Se trovo altre situazioni anomale te lo comunico.
in attesa di tempi migliori... :(
stò pensando di stoppare temporaneamente lo sviluppo, altrimenti mi ricoverano
allo scopo di evitarti l'esaurimento, mantenendo però l'allenamento, ;D ti sottopongo due anomalie riscontrate nelle ultime prove.
- PgConfigItem.Encode()
nelle righe di verifica dei valori numerici usi la funzione IsDigit(Value), questa potrebbe darti problemi se passi come
parametro un numero negativo. Non sarebbe meglio usare IsNumber()?
- PgApplication.AddProject()
la riga:
With projectPanel = New PgProjectPanel($mainPanel.GetTab(index), w, h) As "ProjectPanel"
dovrebbe essere, credo,
With projectPanel = New PgProjectPanel($mainPanel.SetTabIndex(index), w, h) As "ProjectPanel"
inoltre l'errore UnknowMethod generato poichè il metodo GetTab non esiste nella classe PgMainPanel
non viene registrato nel log poichè nella sub PgLogFileWriter.Write() esegui il controllo:
If (messageEvent.Level.IsGreater(Me.MaxLevel)) Then
dove ME.MaxLevel="Info" mentre messageEvent.Level= "Error"
non so se la cosa è intenzionale in questa fase.
Perdona il ritardo, ma come ti avevo accennato, in questo periodo sono alquanto preso da cose più importanti, per cui ho ancora meno tempo per dedicarmi al progetto.
Ad ogni modo, ti sono grato per le note e i suggerimenti, che vedrò di applicare quanto prima.
Ho messo appunto un remember sull'item di questa discussione, in modo da tenerlo sempre presente per la prox volta che mi metterò a fare modifiche.
Ogni tanto cerco di scrivere qualcosa, e lo puoi notare dagli aggiornamenti sul repository, ma è alquanto dura. Per farlo devo concentrarmi ovviamente sul problema, e se ho poco tempo, la cosa mi resta alquanto difficile, per cui spesso lascio perdere e rimando alla prox.
stò pensando di stoppare temporaneamente lo sviluppo, altrimenti mi ricoverano
allo scopo di evitarti l'esaurimento, mantenendo però l'allenamento, ;D ti sottopongo due anomalie riscontrate nelle ultime prove.
- PgConfigItem.Encode()
nelle righe di verifica dei valori numerici usi la funzione IsDigit(Value), questa potrebbe darti problemi se passi come
parametro un numero negativo. Non sarebbe meglio usare IsNumber()?
- PgApplication.AddProject()
la riga:
With projectPanel = New PgProjectPanel($mainPanel.GetTab(index), w, h) As "ProjectPanel"
dovrebbe essere, credo,
With projectPanel = New PgProjectPanel($mainPanel.SetTabIndex(index), w, h) As "ProjectPanel"
inoltre l'errore UnknowMethod generato poichè il metodo GetTab non esiste nella classe PgMainPanel
non viene registrato nel log poichè nella sub PgLogFileWriter.Write() esegui il controllo:
If (messageEvent.Level.IsGreater(Me.MaxLevel)) Then
dove ME.MaxLevel="Info" mentre messageEvent.Level= "Error"
non so se la cosa è intenzionale in questa fase.
Ho effettuato subito un controllo, e ho verificato che:
1) i controlli in Encode erano in effetti un pò vaghi e non proprio corretti. Le funzioni che mette a disposizione Gambas non sono tutte adatte, e alcune non sono neppure presenti, nonostante siano menzionate nella documentazione. Ad ogni modo ho riscritto il metodo, e mi sono basato sulla gestione degli errori, in modo da far lavorare Gambas al posto mio.
2) il metodo GetTab in effetti non esiste, anzi esisteva ma è stato sostituito dalla funzione GetTabPanel, più indicativa. Ho corretto il problema.
3) La gestione del log presentava un errore, che stavo appunto correggendo. Se vuoi un log più dettagliato, basta impostarlo nella finestra delle impostazioni, oppure modificare la voce DEBUG nel file di configurazione, inserendo la stringa "ALL" o "TRACE". I livelli ammessi sono:
OFF, FATAL, ERROR, WARNING, INFO, DEBUG, TRACE, ALL. Per default è impostato su INFO.
Ciao md9327,
ho visto le modifiche e dato una occhiata alla gestione del log, bel lavoraccio...
Bisogna riconoscerti uno sforzo non indifferente nella scrittura di questa nuova versione di pgd.
A proposito di log ho notato che gli eventi relativi a:
-MainMenuBar
-MainPanel
-MainStatusBar
-MainWindow
vengono scatenati due volte, a causa delle dichiarazioni di osservatori alle righe da 265 a 268. Infatti nelle righe precedenti laddove istanzi gli oggetti associ già lo stesso osservatore. Puoi verificarlo nel file di log, dove trovi le voci ripetute degli eventi "Unknown method Action_Activate".
With $mainPanel = New PgMainPanel As "MainPanel"
...
...
hObs = New Observer($mainPanel) As "MainPanel"
Scusami se ti segnalo le anomalie che riscontro in modo un poco disordinato, ma approfitto del tempo libero e purtroppo questo è una risorsa in esaurimento... :'(
...
Stai scherzando?!?
Mi sei di immenso aiuto, dato il periodo e il lavoro da fare...
Comunque, quei messaggi li avevo notati anche io, ma non riesco a capire come vengono scatenati. Ho seguito il processo con il debug, ma non vedo il motivo di ciò... boh?
Sulla gestione dei log e degli errori ci stò studiando parecchio, anche a causa della poca libertà di movimento che mi lascia Gambas, specialmente per gli errori. La classe Error è statica e non può venir subclassata con classi più specializzate, a differenza di linguaggi più evoluti. Per intercettare gli errori devo usare forzatamente il TRY...CATCH, e usare una classe statica per salvare lo stato di Error. Devo utilizzare una classe statica in quanto deve essere già attiva all'avvio del programma, altrimenti non cattura i dati di Error, che verrebbero altrimenti resettati alla chiamata di un metodo.
Per il log credo di aver creato una libreria decente, e utilizzabile in modo generallizzato con altri programmi. L'idea è derivata da alcune classi componenti la libreria j4log di Java, da cui ho estratto un condensato ad-hoc per Gambas. Sicuramente potrebbe essere espansa, e infatti le classi che ho creato possono venir specializzate.
Riguardo i messaggi di Unknown Method presumo siano scatenati da Gambas stesso, che associa il metodo Activate in modo automatico ad ogni Action. Mancando una routine Action_Activate in pgd viene scatenato l'evento Unknown.
Ad ogni modo ritengo sia un problema marginale.
E' quello che pensavo anche io.
Il problema è che non sò come lokkarlo temporaneamente (in fase di avvio), in alternativa mi vedo costretto a creare un metodo vuoto inutile...
La cosa anche strana è che viene segnalato due volte. Le action che creo sono svariate, per cui mi aspetterei due siatuazioni, ovvero un solo messaggio oppure uno per ogni action dichiarata...
La cosa anche strana è che viene segnalato due volte.
Questo è sicuramente dovuto al doppio osservatore; ho provato a commentarne uno e l'evento si scatena una sola volta.
A presto.
edit...
per maggiore chiarezza:
prova a commentare la linea 265 nella pgapplication.init(). (rev 494)
PS già che ci sei modifica il formato di Timestamp da "mm/dd/yyyy hh:mm:ss" in "mm/dd/yyyy hh:nn:ss"
in questo modo nella stringa otterrai i minuti invece del mese; le classi interessate sono:
- PgLogHtmlFormat riga 26
- PgLogTextFormat riga 28
Vedrò per gli eventi...
Riguardo al formato data, reminiscenze di altri linguaggi... ;D
Correggo!
Grazie e continua così... :ok:
riguardo gli eventi, considerando l'automatismo con cui Gambas scatena l'evento Activate per le Action, potresti utilizzare la funzione Action_Activate nel seguente modo:
Public Function Action_Activate(sKey As String) As Boolean
Raise ActionEvent(sKey)
End
sostituendola alla sub
Public Sub MenuButton_Click()
Raise ActionEvent(Last.Action)
End
PS: ricordati l'ora, nella rev. 496 è ancora errata.
...modifica il formato di Timestamp da "mm/dd/yyyy hh:mm:ss" in "mm/dd/yyyy hh:nn:ss"
Si, grazie, vedo di appuntarmelo a fuoco da qualche parte... :D
Purtroppo ho la capa fuori posto, sono in fase di spostamento di casa, e ho un sacco di lavori da fare, per cui il computer ormai l'ho perso di vista. Negli spazi di tempo sul lavoro, riesco a leggere le mail e magari anche il forum (come ora), ma null'altro...
Indi per cui, i tuoi appunti e suggerimenti li annoto, e li applico appena finisco il tormento e riprendo la vita normale (per così dire...).
Ovviamente, se trovi altre cose, scrivi pure, così aggiungiamo alla lista...
:2birre:
:ok:
Ciao,
se vuoi una mano io tra breve incomincio un progetto nuovo e sono disponibile ad usare pgDesigner 3 per definire la struttura del db. Al momento sviluppo su Natty ma il progetto, a regime, girerà sul pangolino!
Fammi sapere e ciao
Pierpaolo
P.S.: la versione prescelta di PostgreSQL è la 9.1 con i db di lavoro su unità TrueCrypt con chiave su chiavette USB
COme accennato nella mia precedente, sono attualmente occupato in ben altre faccende e, oltretutto ho pure il pc smontato, per cui ho dovuto abbandonare temporaneamente lo sviluppo.
Ti ringrazio per l'aiuto che CERTAMENTE è benvenuto!!!
Devo però avvertirti che attualmente non è ancora operativo, per cui non è possibile progettare qualcosa, anche perchè non ha ancora la parte accesso al db, produzione di file e via dicendo. Il tutto è in fase di sviluppo e trasformazione dalla precedente versione, ma tutti i pezzi sono ancora indipendenti.
Ad ogni modo, non c'è bisogno di accettazione, ora come ora qualsiasi aiuto è ben accetto!
Spero solo di rimettermi all'opera il prima possibile...
Grazie! :2birre:
Ciao md9327,
anche se a rilento continuo i miei test su pgdesigner3.
Ho una bruttissima notizia da darti >:( :'(
In questa versione fai ampio uso della cartella .hidden per le icone, i file di configurazione ed altro; ebbene se crei un eseguibile del progetto quella cartella non viene salvata nel file e conseguentemente l'esecuzione si blocca senza che la causa venga segnalata all'utente. Semplicemente non funziona!!! :skull:
Non ho provato creando un pacchetto (deb o rpm)
Esiste anche un secondo problema, anch'esso non indifferente, con la gestione dei menu.
Se ho compreso bene la funzionalità di AppMenu, la famigerata funzione che ruba i menu alle finestre nelle ultime versioni di Ubuntu/Unity, con il metodo implementato in pgdesigner3 essi scompariranno inevitabilmente quando esegui l'applicazione standalone (non dall'IDE). Se riesco nei prossimi giorni faccio delle prove e ti aggiorno.
Ciao SOtema!!!
Ho appena ripristinato parte del sistema e della rete, ma ho ancora parecchie cose da fare, e non solo sul pc... :'(
Per cui, prima di rimettermi all'opera, parresà un pò di tempo.
Riguardo ai due punti che hai segnalato, la cosa mi lascia alquanto basito... :o
1) la cartella .hidden, fino a poco tempo fà, veniva inclusa nel progetto, come anche tutto il resto si trovi sotto la cartella principale. Se questo non è più vero, diventa un problema... Se è vero, che si blocchi mi pare normale, perchè non previsto un controllo in tal senso...
2) il problema con unity è noto. Probabilmente si dovrà procedere in qualche modo per visualizzare i menu. Una cosa: spariscono i menu o solo le icone?
spariscono i menu o solo le icone?
in realtà non sparisce nulla; la mia era una supposizione, ma non avevo notato che eseguendo l'applicazione dall'IDE, i menu vengono duplicati sulla barra di unity. Questo comportamento è normale e sta a significare che i menu vengono catturati correttamente.
Circa la cartella .hidden, ho fatto una prova. Ho copiato l'intero contenuto in una cartella "hidden" all'interno della "data", correggendo di conseguenza i puntatori in pgdesigner, che ora si avvia correttamente. Nella versione originale, con i file nella ".hidden" il programma si blocca alla linea PgApplication._init.138 laddove esegui il controllo su checkFileList. Vedi log allegato
Riguardo alla cartella .hidden, vedrò di analizzare la cosa appena possibile.
Ho scaricato il log, ma non riesco a leggerlo... ??? Sembra codificato in manieria binaria...
la parte interessante:
04/07/2012 21:04:45 [INFO ] Start Application initialization...
04/07/2012 21:04:45 [ERROR ] > Missing base files
04/07/2012 21:04:45 [ERROR ] End Application [exit=1]
Il messaggio è certamente relativo ad un problema con i file del sistema pgDesigner.
Come detto, devo testare e verificare il problema...
Ciao sfaticato... ;D
So che sei in altre faccende affaccendato, ma segnati pure questa nella TODO!
Da qualche versione in GB3 è stato implementato un nuovo componente gb.xml scritto completamente in gambas, che si affianca al vecchio, basato su libxml, rinominato per l'appunto in gb.libxml. Ebbene, gb.xml è tuttora in stato di test ed ovviamente ha qualche problemino. Inoltre mi pare sia un pochino cambiata la logica, non ci ho guardato a fondo; ad ogni modo, pgdesigner3 all'avvio seleziona il componente gb.xml (dal nome) e questo causa un errore di NOT AN OBJECT alla linea.
PgXmlDocument.Load.79 (Select Case oXml.Node.Type)
Per garantire il funzionamento di pgdesigner3 devi selezionare nelle proprietà progetto il componente gb.libxml
Alla prossima.
Non sò se ringraziarti della bella notizia... Scherzo!!!
Si può dire "che bolas" qui sul forum? Bè, lo dico lo stesso, tanto poi il "carnefice" ceskho mi banna in automatico...
A dire la verità non ho ancora preso la normale vita, oltre al fatto che ho dovuto necessariamente aggiornare il mio serverino da Fedora14 a 16, la qual cosa ha creato un altro mucchio di casini enormi, che mi hanno costretto a ripartire da zero, riformattando il tutto (avevo comunque il "santo" backup) e riconfigurare il configurabile... Il passaggio è stato fatto al 95%, ma i nuovi camnbiamenti alla parte grafica della distro non è che mi piacciano granchè...
Comunque...
Purtroppo ho ancora parecchie cosette da fare, oltre al lavoro e la vita quotidiana, e quindi non ho ancora la testa per rimettermi all'opera con pgDesigner. Non ho neppure messo in elenco le cose da fare, in particolare quelle che mi hai segnalato. Ad ogni modo le note sono qui nel thread, e qui le troverò quando riuscirò a rientrare nel progetto.
Comunque ci sono parecchie cose che mi hai fatto notare che non mi sono piaciute, nel senso di introduzione da parte di Gambas3 di alcune variazioni, alcune volte sottili, che scombinano un pò l'architettura mentale che mi ero fatto sul progetto. Dovrò rivedere parecchie cosette...
Per il momento seguo il forum (e rispondo anche...) dal portatile in ufficio... :-\
Comunque ci sono parecchie cose che mi hai fatto notare che non mi sono piaciute
Concordo, poco prima del rilascio stabile sembra che Benoit si sia fatto prendere la mano. Cosa quantomeno criticabile. Ad ogni modo ritengo che la logica implementata in pgd3 sia, tra le varie versioni, quella maggiormente fluida e manuteniibile. Quando rimettera mano al progetto forse i cambiamenti saranno finiti...Spero
Ho provato ad installare sia G2 che G3 su Fedora 16 ma le due versioni non possono coesistere se installate tramite pacchetti.
Ad ogni modo Fedora è rimasta alla 2.23.1 e alla 3.0.0.
Ho provato a compilare da sorgenti ma si compila solo la G2, mentre la G3 non và a buon fine, e non a causa di mancanza di librerie.
Per ovviare a questi problemi ho provveduto a installare alternativamente Gambas dai repository per risolvere tutte le dipendenze, cancellandoli subito dopo, ma la compilazione di G3 và sempre male.
Quindi, per il momento, mantengo la sola G3 installata da rpm, e mi baserò su quella per lo sviluppo, salvo aggiornamenti futuri.
A parte i problemi che mi hai segnalato, quando riprenderò lo sviluppo, ho idea di migliorare la parte grafica, oltre ovviamente a terminare la parte db driver. Devo riuscire a virtualizzare il più possibile, così da creare librerie riutilizzabili anche per altre cose. L'uso massivo degli eventi è stata proprio l'idea iniziale per poter raggiungere questo scopo.
Quindi, per il momento, mantengo la sola G3 installata da rpm, e mi baserò su quella per lo sviluppo, salvo aggiornamenti futuri
Anche xchè a mio parere è + stabile della 3.1!
Ho iniziato a riprendere il lavoro sul progetto... (qualcosina...)
Per il momento ho verificato il discorso .hidden, e confermo l'anomalia. Ho già trasferito le cartelle che erano stto .hidden nella home del progetto, e così funzia.
Ora vedo di ritornare a leggere i precedenti post, per riprendere i discorsi lasciati in sospeso.
forza md che l'esercizio mantiene giovani... ;D
forza md che l'esercizio mantiene giovani... ;D
non farmi parlare... :evil: >:(
Ciao sfaticato... ;D
So che sei in altre faccende affaccendato, ma segnati pure questa nella TODO!
Da qualche versione in GB3 è stato implementato un nuovo componente gb.xml scritto completamente in gambas, che si affianca al vecchio, basato su libxml, rinominato per l'appunto in gb.libxml. Ebbene, gb.xml è tuttora in stato di test ed ovviamente ha qualche problemino. Inoltre mi pare sia un pochino cambiata la logica, non ci ho guardato a fondo; ad ogni modo, pgdesigner3 all'avvio seleziona il componente gb.xml (dal nome) e questo causa un errore di NOT AN OBJECT alla linea.
PgXmlDocument.Load.79 (Select Case oXml.Node.Type)
Per garantire il funzionamento di pgdesigner3 devi selezionare nelle proprietà progetto il componente gb.libxml
Alla prossima.
Non vedo la gb.libxml, ma ad ogni modo la gb.xml c'è e funziona... :-\
riguardo gli eventi, considerando l'automatismo con cui Gambas scatena l'evento Activate per le Action, potresti utilizzare la funzione Action_Activate nel seguente modo:
Public Function Action_Activate(sKey As String) As Boolean
Raise ActionEvent(sKey)
End
sostituendola alla sub
Public Sub MenuButton_Click()
Raise ActionEvent(Last.Action)
End
PS: ricordati l'ora, nella rev. 496 è ancora errata.
...modifica il formato di Timestamp da "mm/dd/yyyy hh:mm:ss" in "mm/dd/yyyy hh:nn:ss"
Ho corretto il formato data!
Riguardo agli eventi non ho ben capito cosa intendevi in questo post... :-\
Rispondo in due tempi per maggiore chiarezza.
Non vedo la gb.libxml, ma ad ogni modo la gb.xml c'è e funziona... :-\
xchè stai lavorando sulla 3.0 da repo. La libreria che usi in pgdesigner è stata convertita in gb.libxml dalla rev. 3.1 allorchè è stata introdotto il componente gb.xml scritto in Gambas. Purtroppo quando aggiornerai da svn, riscontrerai certamente il problema:
dal changelog:
------------------------------------------------------------------------
r4640 | gambas | 2012-04-20 03:01:48 +0200 (ven, 20 apr 2012) | 9 lines
[GB.LIBXML]
* NEW: Rename the gb.xml component as gb.libxml.
[GB.LIBXML.XSLT]
* NEW: Rename the gb.xml.xslt component as gb.libxml.xslt
[GB.LIBXML.RPC]
...
------------------------------------------------------------------------
r4644 | prokopy | 2012-04-21 00:57:18 +0200 (sab, 21 apr 2012) | 2 lines
[GB.XML]
* NEW: New XML manipulation component
* NEW: Rename the gb.xml.rpc component as gb.libxml.rpc
Riguardo agli eventi non ho ben capito cosa intendevi in questo post... :-\
ricordi che al click su una voce di Menu si registrava nel log il messaggio "UnknownMethod 'ActionActivate'"?.
Probabilmente G3 associa in automatico l'evento Action_Activate a tutte le azioni. Di conseguenza al solo scopo di ovviare alla registrazione nel log ti consigliavo di inserire la funzione Action_activate(skey as string) dove semplicemente fai scatenare l'evento corrispondente. In pratica sostituire la sub:
Public Sub MenuButton_Click()
Raise ActionEvent(Last.Action)
End
con la gestione delle actions:
Public Function Action_Activate(sKey As String) As Boolean
Raise ActionEvent(sKey)
End
Ciao md9327,
ho visto le modifiche e dato una occhiata alla gestione del log, bel lavoraccio...
Bisogna riconoscerti uno sforzo non indifferente nella scrittura di questa nuova versione di pgd.
A proposito di log ho notato che gli eventi relativi a:
-MainMenuBar
-MainPanel
-MainStatusBar
-MainWindow
vengono scatenati due volte, a causa delle dichiarazioni di osservatori alle righe da 265 a 268. Infatti nelle righe precedenti laddove istanzi gli oggetti associ già lo stesso osservatore. Puoi verificarlo nel file di log, dove trovi le voci ripetute degli eventi "Unknown method Action_Activate".
With $mainPanel = New PgMainPanel As "MainPanel"
...
...
hObs = New Observer($mainPanel) As "MainPanel"
Scusami se ti segnalo le anomalie che riscontro in modo un poco disordinato, ma approfitto del tempo libero e purtroppo questo è una risorsa in esaurimento... :'(
...
Ho trasformato i messaggi in warning. Per il momento lascio le cose come stanno, in previsione di analisi più approfondite in futuro...
Riguardo agli eventi non ho ben capito cosa intendevi in questo post... :-\
ricordi che al click su una voce di Menu si registrava nel log il messaggio "UnknownMethod 'ActionActivate'"?.
Probabilmente G3 associa in automatico l'evento Action_Activate a tutte le azioni. Di conseguenza al solo scopo di ovviare alla registrazione nel log ti consigliavo di inserire la funzione Action_activate(skey as string) dove semplicemente fai scatenare l'evento corrispondente. In pratica sostituire la sub:
Public Sub MenuButton_Click()
Raise ActionEvent(Last.Action)
End
con la gestione delle actions:
Public Function Action_Activate(sKey As String) As Boolean
Raise ActionEvent(sKey)
End
Sì, ricordo, e ho inviato a tal proposito il post precedente a questo. Devo però analizzare la cosa. Gli eventi sono tutti collegati alle rispettive classi, e controllare quelli di Action mi porta fuori strada. In teoria l'evento Activate viene scatenato a prescindere, e dato che non trova un metodo adatto, và negli eventi sconosciuti e attiva il metodo _unknown(). La cosa è alquanto anomala, in quanto uno non è obbligato a gestire tutti quanti gli eventi. Ad ogni modo i messaggi, a questo punto, li lascio come sono, ma come warning. Magari poi analizziamo come ovviarli. Ho fatto una modifica nei metodi in Application che intercettano gli eventi, che richiamano un unico metodo privato, in cui ho messo una condizione proprio dull'Activate. La cosa non mi piace molto, e forse la toglierò a breve...
Carissimo sotema,
stavo riepilogando un pò i sorgenti e lo stato in cui l'avevo lasciati, e mi sono accorto che manca una cosa:
IL TUO NOME!!! :D
Se ti và, e se mi dai il tuo nome, lo inserisco nei contributori del progetto, che mi pare pure giusto... :D
In alternativa, se mi dai il consenso, magari metto solo il nick di qui del forum, ma mi pare un pò bruttino...
Fammi sapere, anche in privato o via email!
Ciao!!!
Ciao md9327.
pgDesigner3 rev. 515:
nelle seguenti classi (driver object):
PgDataDatabase
PgDataDomain
PgDataFunction
PgDataSchema
PgDataSequence
PgDataTable
PgDataTableIndex
PgDataTablespace
PgDataTrigger
PgDataType
PgDataView
dovresti eliminare l'istruzione CREATE PRIVATE. altrimenti le suddette non possono essere istanziate.
Sì, lo sò, sono rimaste così in quanto avevo pensato di derivarne altre a seconda del driver.
Per il momento non vengono ancora utilizzate, mentre lo sono quelli only-graphix (Area, Image,...)
ok, attento però che selezionando Create Object ---> Create Table dal Menu PopUp del Progetto, vai ad istanziare la PgDataTable, con conseguente errore.
Rev. 521:
la riga 268 di PgDbConnect.Test credo debba essere:
Ok, ho disabilitato temporaneamente gli item relativi nei menu.
Ho corretto anche la funzione Test...
Thanks!!! :ok:
Speravi mi fossi scordato di te? Sbagliavi!!!
In effetti sono un poco incasinato ma...
Rev 543 nella classe PgDataObjectType tra le dichiarazioni manca la dichiarazione della costante Schema.
Ho notato anche un pesante degrado della velocità di avvio generato dalla funzione PgMime.Load che impiega un tempo molto lungo a caricare il file delle definizioni dei Mime Type. Ciò è vero se utilizzi il componente gb.xml; provando a selezionare il vecchio gb.libxml la velocità di elaborazione del documento aumenta notevolmente.
Ora non posso proprio ma domani provo a segnalarlo sul thread in cui ha partecipato Adrien.
;D
Stò inserendo anche Schema. L'avevo tralasciato perchè stavo pensando a come gestirlo...
Riguardo a gb.xml l'avevo notato anche io. Ho fatto fare allo sviluppatore molte correzioni, perchè non andava proprio.
Ora glielo segnalo nella discussione, sperando la legga...
Credo comunque che la differenza è appunto il numero di oggetti che ha questa nuova libreria, e forse l'aggancio con quella esterna.
Comunque, allo stato attuale, pgDesigner3 funzia con tutte e due, quindi possiamo scegliere.
Probabilmente, adesso modifico il progetto e ripristino la vecchia gb.libxml.
Probabilmente, adesso modifico il progetto e ripristino la vecchia gb.libxml.
Potresti mantenere le due librerie insieme, magari utilizzando gb.libxml come ufficiale e testare le modifiche con gb.xml per segnalare eventuali problemi. Sarebbe un grosso contributo allo sviluppo, che ne dici?
:-\
In effetti è quello che stò facendo... :D
Ciao md9327,
ieri ho aggiornato Gambas (rev. 4959) e pgdesigner (rev 553), lancio pgdesigner e :evil: >:(, si blocca con l'errore initialize error!
Dapprima penso che tu abbia modificato qualcosa nella _init, e quindi eseguo il debug step by step; sorpresa...
alla linea 21 della classe PgLogHandler_New() l'istruzione:
genera l'errore: wanted pgfifo got integer instead
provo a sostituire l'istruzione con:
$fifo = new PgFifo(limit)
rilancio e listruzione viene eseguita correttamente.
Proseguendo arrivo alla linea 77 della classe PgXmlDocument_new(), dove l'istruzione:
$root = PgXmlElement("root")
genera l'errore: wanted pgxmlelement got string instead.
sostituisco l'istruzione con
$root = new PgXmlElement("root")
e tutto procede liscio...
Alla luce delle prove fatte credo si possa asserire che se istanzi una classe passando un parametro opzionale il metodo _call() fallisce. se riesco in serata indagherò più approfonditamente quello che appare come un bug introdotto dagli ultimi aggiornamenti.
Se hai tempo dacci un occhio e fammi sapere...
scoperto l'inghippo: la funzione _init deve essere definita STATIC!!! (come del resto evidenziato nel wiki)
;D
In PgDesigner ci sono parecchi metodi _call(...) che sono dinamici. Buon lavoro
Mi sono scappati?!? >:( :evil:
Mannaggia 'a pupattola... Mò me devo mette pure a cercà... ;D
Però è strano, ieri sera ho lanciato l'applicazione più volte senza probelmi... :-\
lo so, il problema è nato dopo l'ultimo aggiornamento di Gambas.
E infatti, proprio ieri sera avevo installato l'ultima build... boh?!?
scoperto l'inghippo: la funzione _init deve essere definita STATIC!!! (come del resto evidenziato nel wiki)
;D
In PgDesigner ci sono parecchi metodi _call(...) che sono dinamici. Buon lavoro
Il problema era proprio _call() (e non _init() ;D ).
Praticamente la funzione è presente in tutti gli oggetti, quindi mi è toccato modificare tutto... >:( :evil:
Ad ogni modo, nella documentazione STATIC era facoltativo, dove hai letto che ora DEVE essere STATIC ?
Non sò se l'avevi notato, ma ora il drag&drop funziona dalla Tool, sia verso la View, sia verso la Tree.
Ho creato anche i pannelli per gli oggetti, per l'editing delle proprietà.
Nel menu, e nel popup, ora sono abilitate le voci "Object Property" e "Graphic Object".
Gli oggetti nella Tool sono visibili in base al tipo di driver del progetto.
Ho anche abilitato ed è funzionante il driver db del progetto, anche se non ancora operativo. La sua attività è ora ancora limitata alla gestione degli oggetti, e quindi non ha ancora le funzionalità di db.
Stò ancora abilitando gli eventi, i messaggi e la gestione degli errori, per la gestione unificata con il manager applicativo.
C'è da lavorare.... :'(
:D
Ad ogni modo, nella documentazione STATIC era facoltativo, dove hai letto che ora DEVE essere STATIC ?
più che altro una intuizione, dalla frase : This method can be static. Then, the class will be able to be used as a function, not the object.
Certo che qualche variazione è stata introdotta dalla rev 4945 che usavo fino a ieri. Ma nel log nn ho trovato nessun riferimento.
Non sò se l'avevi notato, ma ora il drag&drop funziona dalla Tool, sia verso la View, sia verso la Tree.
Ho creato anche i pannelli per gli oggetti, per l'editing delle proprietà.
Nel menu, e nel popup, ora sono abilitate le voci "Object Property" e "Graphic Object".
Gli oggetti nella Tool sono visibili in base al tipo di driver del progetto.
Ho anche abilitato ed è funzionante il driver db del progetto, anche se non ancora operativo. La sua attività è ora ancora limitata alla gestione degli oggetti, e quindi non ha ancora le funzionalità di db.
Stò ancora abilitando gli eventi, i messaggi e la gestione degli errori, per la gestione unificata con il manager applicativo.
C'è da lavorare.... :'(
:D
Sto mettendoci le mani proprio ora.
Lavoreremo... ;)
Lavora Remo ? E mò chi è questo? ;D
Nell'ultima build, ho iniziato a costruire la parte di read/write dei file progetto. Al momento c'è solo il write che sarebbe da testare.
Ho fatto un test veloce, con progetto senza oggetti, e mi pare funzionante. Nel file ci sono un mucchio di info che, almeno per la parte di setup del progetto mi pare alquanto completa.
Non ho provato le proprietà: Printer, Panel, Driver, oltre ai Canvas, gli oggetti e il resto... ci stò lavorando... :D
Credo tu abbia già notato che il salvataggio del progetto entra in loop nella sub Revision_Write della classe PgProject a causa della istruzione Me.Revision = NOW() della sub Me_ChangePropertyEvent(...)
Ho riscontrato anche un'anomalia nel nome del progetto.
Alla creazione di un nuovo progetto imposti il nome del file a $name & ".pgd", poi nella procedura PgApplication._saveAsProject imposti:
filename = project.filename
...
Dialog.Path = filename
...
filename = Dialog.Path
ora per effetto delle proprieta di Dialog il nome del file diventa Application.Path &/ project.filename con l'effetto di andare a salvare il progetto nella cartella dell'applicazione. Tutto bene fintanto che esegui pgDesigner in debug, ma qualora lo installassi come pacchetto potresti incappare in errori di permessi insufficienti.
Credo sia meglio impostare:
...
Dialog.Path = $configManager.Get(PgConfigManager.CFG_PRJPATH) &/ filename
...
dove CFG_PRJPATH corrisponde a $User.Home &/ "pgprojects"
Che ne pensi?
In realtà, dovrei salvare l'ultima path usata a livello di sistema, e nel progetto l'ultimo file salvato.
La tua idea è quella di usare una cartella repository, il che potrebbe anche essere un'idea, ma devo pensarci...
Riguardo gli errori, dovresti controllare se hai l'ultimissima build. Il problema l'avevo riscontrato e subito corretto.
Manca ancora qualcosa...
Ho aggiornato ora, ultima build 563
Nella build di oggi (l'ultimissima), ho attiva la lettura/scrittura dei file progetto.
Se hai la possibilità, tocca testare a fondo le due procedure dove, molto probabilmente, ci sarà ancora lavoro da fare per sistemare le cose.
Ho fatto dei test preliminari, e mi pare funzioni. Per il debug verrno emessi messaggi nella console, e una specie di timer prima del termine effettivo delle operazioni. Appena tutto è a posto li elimino...
Nel (poco) tempo libero farò certamente delle prove.
Nel frattempo vorrei suggerirti di impostare Nome del File uguale al nome del progetto, già in fase di creazione. Potresti usare l'evento LostFocus() della TextBox, allo scopo di evitare la sovrascrittura accidentale.
Inoltre abilitando il componente gb.form.dialog potresti impostare l'estensione automatica (.pgd) per i file di progetto nella maschera di salvataggio.
A presto. :ok:
Mi pare che le due cose che mhai menzionato ci siano, ma farò un controllo.
Nell build di questa sera, ho corretto e implementato ancora qualcosina riguardo il R/W dei file di progetto, in particolare la scrittura/lettura delle immagini per gli oggetti PgPaintImage.
Rispetto a Gambas2 sono cambiate parecchie cosette riguardo alla gestione dei puntatori in memoria, che mi hanno causato un bel mal di testa.
N.B.: per gli oggetti image non ho ancora messo un limite di dimensioni dell'immagine, e quindi tocca stare bene attenti a non caricare immagini troppo grandi perchè bloccano tutto...
REV 577
Ho riscontrato un errore di gestione del pannello laterale, precisamente nell'expander 'Tool'.
se apri contemporaneamente due progetti, com motori DB differenti, passando da un progetto all'altro, gli strumenti disponibili non sono aggiornati correttamente; gli strumenti specifici del SERVER spariscono.
Le foto allegate ti mostrano chiaramente la situazione.
Purtroppo non ho avuto il tempo di seguire il flusso del codice per verificare dove sorge il problema...ci darò un'occhio nel fine settimana.
Probabilmente c'è qualche dimenticanza nell'aggiornamento. Stavo appunto facendo delle verifiche anche su altri casi similari.
Rev #578 Mi sembra risolto il problema dei tools.
L'apertura di un progetto esistente fallisce con l'errore NULL OBJECT alla linea 1428 di:
PgApplication._actionUpdate(); l'istruzione:
Action[PgProjectManager.ACTION_PROJECT_CREATE_DOMAIN].Visible = project.Driver.IsValidObjectType(PgDataObjectType.Domain)
fallisce poichè la proprietà Driver di PgProject è NULL.
Che vuol dire all'apertura di un progetto esistente? Caricato da file? Se è così, quella parte non è ancora completata. Ci stò lavorando sopra, e devo pure dirti che la struttura interna dei file l'ho cambiata.
Se fai test sulle funzioni di lettura/scrittura file progetto, tieni conto che sono ancora in fase evolutiva, per cui potre cambiarle, e anche di parecchio... :-\
Ho quasi completato la parte lettura/scrittura file progetto. Sembra funzionare bene, ma non l'ho ancora provata con tutti gli oggetti...
Sto testando le procedure di scrittura / lettura del file di progetto.
In esso nella sezione Object utilizzi la seguente sintassi per definire le proprietà dei singoli oggetti:
...
<Property::Option>T</Property::Option>
...
ebbene questa sintassi provoca l'errore di 'Documento mal formattato' (non well-formed)
poichè il simbolo : nella sintassi xml indica un prefisso, utilizzato in associazione con un namespace
Forse mi sono scappati i due punti... provvedo... :ok:
Rev #627
Funzione Apri Progetto.
PgMysqlDriver.ImportXmlTable.3172:
tableObject.Property["OnUpdate"].Value = xmlElement.AsString()
genera errore Null Object in quanto tenti di impostare il valore di una proprietà che non esiste.
Vedi figura allegata.
Ovviamente succede solo se esiste un oggetto table nel progetto. Ti allego anche il file di progetto.
Svista... cut&paste... ;D
Ho corretto subito e messo nel repository.
Nota: Ho lavorato anche sulla stampa dei diagrammi, e parecchie altre cose (es. invio mail progetto e immagini). Comunque già lo noti dai menu abilitati... :D
:ok:
Ciao md9327,
oggi ho scaricato l'ultima revisione (#641) di pgDesigner2 per iniziare un nuovo progetto e al primo avvio il programma si è bloccato con l'errore Out of Bound alla linea:
sFile = Split(aRecentList[nId], "|")[0]
nella sub pgApplication._recentMenuUpdate().
La causa è la linea:
.AddItem(oGroup, pgClassStringArray(pgConfig.CFG_RECENTLIST, [""]))
in pgConfig.CreateDefaultConfiguration.
Il problema si manifesta solo se non esiste il file di configurazione, in questa condizione infatti, l'array aRecentList[0] conterrà il valore "" (stringa vuota); di conseguenza l'istruzione Split non può generare l'array.
Per ovviare all'inconveniente ti basta modificare come segue:
.AddItem(oGroup, pgClassStringArray(pgConfig.CFG_RECENTLIST, ["|"]))
:ciao:
Perdona, ma stai lavorando su pgDesigner2?
Il progetto l'ho lasciato com'era, perchè mi sono messo a scrivere la versione 3.
Se vuoi la modifico...
Ho modificato e aggiornato il repository! :ciao:
OK.
Lo so che hai abbandonato la versione 2. Ma la uso per sviluppare i miei DB. Avendo configurato un nuovo PC ho riscontrato il problema, che avrei potuto correggere nella mia copia locale, cosa che peraltro ho fatto, ma mi è sembrato giusto segnalartelo
Purtroppo non riesco a dedicare del tempo in modo continuativo ai test sulla versione 3, che per la verità aggiorno quasi regolarmente.
E visto che ci siamo:
Classe pgFieldLong, linea 5:
Static Public Const MIN_LONG As Long = -9223372036854775807
non dovrebbe essere -9223372036854775808
:ciao:
Stranamente, dopo la modifica che mi hai segnalato, ho compilato il programma che mi ha segnalato un errore di tipo proprio su quella definizione.
Dato che la cosa mi si era già presentata in precedenza, ho provato a ridurre la cifra di uno, e la compilazione è andata a buon fine.
E' probabile che vi sia qualche problema in gambas2, relativamente alle dimensioni dei Long, solo che non ho tempo di segnalarlo a Benoit, tanto più che la versione 2 è ormai chiusa.
Ad ogni modo, se non riscontri problemi con questa modifica sul Long, possiamo lasciarla così.
Riguardo ad altri problemi su PgDesigner2, segnalami comunque se trovi qualche altro errore. Dato che PgDesigner2 era praticamente quasi terminato, possiamo tenerlo comunque attivo, anche se non distribuito pubblicamente.
Ad ogni modo, se non riscontri problemi con questa modifica sul Long, possiamo lasciarla così.
Scusa ma ti riferisci alla versione 2? Poiché sulla versione 3, ho corretto il valore e mi ha compilato correttamente.
Parlo di PgDesigner2 con Gambas2... (tutto 2)
Chiaro,
la cosa è comunque legata all'architettura poichè Gambas2, pgdesigner2 su ubuntu 10.04.4 x86_32 funziona con il corretto valore di Long.
Se mi avanza del tempo lo segnalo a Minisini...
nel frattempo ho aggiornato Gambas3 e Pgdesigner3 per lavorarci su un pò, ma Gambas (rev5229) mi da errore di segfault all'avvio. :evil:
Escalato...
Agh!!!
Io ho la 5212, e pare funzionare... :-\
Agh!!!
Io ho la 5212, e pare funzionare... :-\
la 5212 è la vesrione cui ero fermo fino a ieri. Il prblema sembra legato alle qt4.
Ti aggiorno.
Tocca stare attenti alle versioni da repository, in quanto potrebbero non essere corrette, e quindi bloccare la compilazione o generare errori in esecuzione.
In ogni caso è sempre meglio poter ritornare indietro, alla versione funzionante.
Se vuoi ti invio uno script che ho creato appunto per scaricarmi le revisioni e ovviare a questi problemi...
Ti ringrazio, anch'io utilizzo uno script, molto semplice, che mi permette di selezionare la revisione, difatti sono tornato alla rev 5212. Ora sono in attesa che risolvano il problema.
In ogni caso inviami lo script, dal confronto si genera progresso.
Ciao
In allegato ti invio due script.
Uno verifica qual'è l'ultima versione su repository, e l'ultima scaricata
Il secondo scarica dal repository. Se gli passi il numero di revisione, lui scarica quella, altrimenti scarica l'ultima.
Ti ricordo che prima di scaricare la versione, è meglio disinstallare quella esistente (ovviamente come root).
Il download crea una cartella trunk in quella da dove lanci lo script. Inoltre crea un file di log e un file con lo storico delle versioni scaricate, in modo da poter tracciare la cosa. Quest'ultimo file è giusto utile quando devi tornare indietro...
Grazie per gli script, mi sono tornati utili.
Anche se da un po di tempo sono latitante qualche sguardo al forum lo caccio, e scarico quasi regolarmente gli aggiornamenti di PgDesigner3, anche solo per apprezzarne i progressi.
Proprio oggi con la revisione 668 e Gambas3 rev. 5416 tentando di creare un nuovo progetto ottengo l'errore
DrawingArea.Painted is deprecated do not use it anymore.
Questo a seguito delle modifiche apportate da Minisini nella dalla rev. 5382. evidenziati dal sig. Ambasciatore
http://www.gambas-it.org/smf/index.php?topic=2431.msg26265#msg26265
Questo perchè stò lavorando con la versione ufficiale rilasciata sui repository di Fedora.
Dovrei eliminare l'installazione dei pacchetti gambas da questi repository, e ripristinare il checkout dal repository sorgenti di gambas, ma a volte mi ritrovo con una release non funzionante.
Stasera cerco di fare nuovamente lo switch... :-\
....evidenziati dal sig. Ambasciatore
Je ne suis plus l'Ambassadeur ! :devil:
Grazie alla segnalazione di vuott, ho modificato anche gli script, che rimetto in allegato.
Ho ripristinato la versione "da repository di gambas" proprio ieri sera.
Ho dovuto eliminare la proprietà Painted sulle drawing, in quanto viene ripetutamente presentato un messaggio di warning, anche durante l'esecuzione del programma. Comunque, pare venga definitivamente rimossa con la release 3.4.
Stò quindi lavorando, si fà per dire, con gambas versione sviluppo...
C'é sempre qualcuno che ti mette i bastoni tyra le ruote...
Ciao MD9327,
dopo un lungo periodo di silenzio torno a far sentire la mia voce, e come avrai capito non porto buone nuove:
Ho ripristinato la versione "da repository di gambas" proprio ieri sera.
Ho dovuto eliminare la proprietà Painted sulle drawing, in quanto viene ripetutamente presentato un messaggio di warning, anche durante l'esecuzione del programma. Comunque, pare venga definitivamente rimossa con la release 3.4.
Stò quindi lavorando, si fà per dire, con gambas versione sviluppo...
Ho scaricato la revisione 669 proprio oggi.
Nei file delle FORM che ti segnalo in coda è rimasta la proprietà .Painted delle DrawingArea. Se utilizzi una versione di Gambas superiore alla 3.4 nella colonna delle Proprietà all'interno dell'IDE non risulta poichè eliminata. Ma eseguendo pgdesigner il messaggio di warning compare non appena utilizzi una di queste FORM.
Per eliminare la proprietà dovrai necessariamente intervenire sui file con un editor di testo (vi)
Le form sono:
- PgDialogQueryDragTarget.form (.src/application/dialog/)
-PgDialogViewPrint.form (.src/application/dialog/)
-PgCanvasTest.form (.src/graphic/test)
Ho corretto come da te suggerito.
Avevo eliminato la proprietà, come indicato nei ChangeLog di gambas, ma probabilmente non è stata tolta nelle Form.
Non ho più aggiornato (cosa che farò a breve) gambas3, anche perchè in questo periodo sono parecchio impegnato in altri progetti più urgenti, e in altre cose personali. E' anche per questo che non ho portato avanti la cosa, oltre al fatto che, nonostante i studi fatti, non riesco a velocizzare la parte grafica (il disegno e il movimento degli oggetti nei diagrammi). Se hai modo, puoi provare a vedere te se trovi qualcosa che possa migliorare il discorso...
Scusami ma mi sono scordato il file:
pgDesigner3/.src/graphic/panel/PgPaintExamplePanel.form:
{ Form Form
MoveScaled(0,0,18,18)
Expand = True
Border = False
Arrangement = Arrange.Fill
Margin = True
{ DrawingArea1 DrawingArea
MoveScaled(1,1,6,6)
Background = &HFFFFFF&
Expand = True
Border = Border.Etched
Painted = True <--------------------
}
}
Riguardo le prestazioni di Draw, onestamente non mi paiono così scarse. E' pur vero che ho provato semplicemente a creare alcuni oggetti e muoverli all'interno della DWA.
Ho corretto anche quell'oggetto.
I test che ho fatto, li ho eseguiti su un mio database di contabilità, che ha parecchi oggetti (tabelle, viste, procedure, funzioni e sequenze), e devo dire che il programma si impianta.
Dai test ho verificato che la velocità di disegno degli oggetti, se vengono movimentati nel diagramma, dipende dal numero e dalla dimensione della drawingarea. Rimpicciolendo l'area di disegno, la velocità aumenta in maniera logaritmica, come anche con un numero di oggetti minore.
Avevo lasciato il progetto in debug, con dettagli maggiori sul log, in modo da capire quanti passaggi vengono effettuati, e cosa viene chiamato.
Forse c'è qualcosa di esagerato negli eventi scatenati, oppure è proprio la logica di gestione del grafico che non và bene.
Insomma, la cosa mi fà imbestialire, pensavo che la nuova libreria velocizzasse le cose, ma mi pare che si comporti allo stesso modo.
E' anche probabile che la cosa dipenda dalla memoria utilizzata dal programma (forse anche perchè lanciata dall'interno dell'ide), che potrebbe saturare lo spazio disponibile, swappando un pò troppo...
E' da analizzare bene.