In effetti, come prima impressione, penso tu abbia esagerato con le dimensioni dell'area.
Concordo con leo, penso sia più gestibile a livello di utility in un pannello.

E' solo un consiglio...

Grazie andy, sarà utile anche a me per l'idea che tu hai proposto.

Nei miei approcci con Gambas, ho avuto modo di fare abbastanza esperimenti a livello di disegno grafico e ho notato che, a differenza di altri linguaggi, oltre certi limiti Gambas diventa piuttosto lento.
Non ho potuto sperimentare la parte di librerie gtk, di cui ò che possono esserci problemi, ma con le qt ho sicuramente notato questa cosa.

Es.: se disegniamo linee, testi o rettangoli, colorati o meno, con la funzione draw() su una DesignArea di piccoli dimensioni, il problema non si verifica a meno di non disegnare un numero cosmico di oggetti grafici.
Se, diversamente, allarghiamo quest'area su dimensioni notevoli, ad esempio 2000x2000, a questo punto si verifica il problema di lentezza.

La lentezza si nota se si interagisce con questi oggetti grafici, ovvero si abilitano gli eventi del mouse, in modo da poter selezionare e spostare un singolo oggetto sul piano grafico; il ridisegno degli oggetti inizia a diventare notevolmente lento, causato probabilmente dal fatto che occorre aggiornare l'intera area.

Ho fatto delle prove comparative con altri linguaggi, ad esempio python e java, e indipendentemente dalle dimensioni dell'area di disegno, gli oggetti vengono disegnati alla stessa velocità di uno solo, con nessun refresh fastidioso o tentennamento del mouse.

Non sò se questo dipende dal ponte tra le librerie Gambas e quelle QT, ma sicuramente c'è qualcosa che non và.

Che ne dite, si può segnalare al team di Gambas ???

Bye

Inizio a postare con una domanda:

- Mettiamo un progetto con una serie di risorse, ad esempio una sotto directory contenente le icone e le immagini utili al programma;
- Durante la compilazione Gambas non tiene conto di queste risorse, pur includendo indistintamente tutto il contenuto della directory di progetto;
- Ovviamente, l'inclusione nell'eseguibile di tutto, accresce notevolmente e inutilmente le dimensioni dello stesso che, anche se non provoca apparentemente problemi all'applicazione, certamente ne rende difficile il trattamento a livello di s.o., oltre a sprecare spazio su disco;
- Anche nella creazione del pacchetto, non funzionante fino a qualche versione fà, nello stesso non viene incluso nessun'altro file al di fuori dell'eseguibile e delle icone che verranno inserite poi nel desktop;

Come accennato in altra discussione, forse sarebbe il caso di segnalare al team di Gambas queste anomalie.

E comunque, il formato dipende dal database che si stà usando, tra quelli previsti dal motore o, a volte dalla configurazione del server (vedi per Oracle e PostgreSQL).

A parte gli ambienti RAD, e a meno che non si utilizzino le funzionalità di Gambas con i database a livello di puro codice, ho avuto anche io difficoltà con gli esempi, specialmente se presi dal mio punto di vista, dato che lavoro molto con Oracle, e il fatto di gestire form che fanno tutto per conto proprio, con una singola tabella, e che dipendono in maniera nascosta l'una con l'altra... insomma, la cosa mi lascia un pò perplesso.
Comunque, ritornando agli esempi, in effetti ho notato che non sono di evidente chiarezza; a parte il presentare o meno dei dati da una archivio, non si capisce bene come interagiscono i vari oggetti tra loro.
Forse credo sia il caso di approfondire la documentazione con qualcosa di più dettagliato.
Ovviamente è un mio parere, tenendo anche conto della difficoltà di gestire lo sviluppo di un linguaggio come è appunto Gambas, a cui faccio sempre i miei complimenti agli sviluppatori!

Bè, così su due piedi...
ambienti IDE simili a quelli windoz ne esistono parecchi; per quanto riguarda, ad esempio, foxpro credo che ormai quel tipo di RAD sia andato per come dire fuori moda.
Ad esempio, sei vuoi programmare in C/C++ c'è kdevelop, per il basic appunto Gambas, per python molti altri, ecc.
Però non mi risultano ambienti che comprendano tutto, dallo sviluppo facilitato di entry form e aggancio a tabelle proprietarie, come del resto erano dbase/clipper o foxpro, oppure visual dbase...
Ora i linguaggi di programmazione sono parte a se, e fanno solo il loro lavoro di linguaggi; un database, per esempio, è ora un'entità a sè, e con cui si colloquia tramite apposite interfacce (driver/librerie). Un esempio è appunto Gambas, che fà il suo lavoro di puro linguaggio, e appoggiandosi a librerie esterne per colloquiare con i programmi e le applicazioni esterne, che non hanno nulla a spartire con il linguaggio in se stesso.
A dire il vero, se ci pensi, anche clipper (è un esempio ma reale), si appoggiava ad un motore db che era un derivato dal dbIIIplus, di più vecchia data, e l'integrazione in un singolo ambiente RAD era all'epoca un tentativo tecnologico di fornire un ambiente unico, proprietario e, appunto, integrato.
Da un pò di anni questa cosa è andata sparendo, lasciando il posto ad una tecnologia più distribuito.
Penso che una cosa come la cerchi tu non la troverai più, e lo dico con un pò di commozione, perchè quegli anni li ho passati anche io a sperimentare.
Ad ogni modo, il tempo è necessario per qualsiasi cosa, anche con Access; se vuoi poi un'ambiente che ti fà tutto da solo, magari anche il porting dei tuoi progetti, bè... non sò come aiutarti...
Purtroppo tocca studiare...

Mi dispiace di non poterti aiutare.

Ciao