Newsgroup: it.comp.lang.delphi
Titolo: richiesta consigli: FORM e MDI  + varie "FOCUS e indicazioni in statusbar menu_principale"

Buonasera a tutti
sto "sperimentando" lo sviluppo in delphi di una applicazione gestionale e volevo chiedere consiglio essendo un neofita.
 
1) Ero indeciso se utilizzare o meno l'MDI.
Nel mio gestionale vorrei dare la possibilità a qualche utente più avanzato di poter affiancare 2 form (esempio FATTURE e DDT) per poter visionare 2 schede di 2 "funzionalità" diverse contemporaneamente.
 
Ho notato che gestire le finestre con l'MDI "porta" dei fastidi sui dimensionamenti/ridimensionamenti automatici quando si aprono form figli (partendo ad esempio da un menu principale) oltre che incorrere nel rischio che un utente "avanzato ma poco pratico" si perda nei meandri delle finestre che poi si sovrappongono.
 
 
 
2) sempre in virtù della possibilità di avere 2 form "davanti all'utente" avevo pensato di avere una status bar unica relativa al menu in cui venissero visualizzate a seconda del FOCUS delle indicazioni dell'uno o dell'altro form (Fatture o DDT) nella status bar interente il form_menu  e non nei 2 form separati
per indicare all'utente se ci sono tasti speciali da poter premere e/o informazioni sui campi.
In considerazione del fatto che 
"Schedaprincipale1" conosce cosa fa (ad esempio) scheda2_Clienti (in quanto figlia) il form principale dei Menu non sa cosa fa "Scheda2_Clienti (non ha nessun collegamento) e quindi non mi viene in mente come poter gestire al meglio il cambiamento di info nella status bar associata al menu ed in cui vorrei "scriverci" info relativi ai 2 form Fatture e DDT (in base al focus)
 
vorrei evitare di inserire una statusbar in ogni form (fatture e ddt) per limitare la "dispersione" dell'utente
 
grazie
saluti

 Ero indeciso se utilizzare o meno l'MDI.
 
Non lo prenderei in considerazione in quanto già sorpassato da tempo e adatto solamente ad applicazioni che lavorano con documenti da visualizzare: meglio privilegiare una soluzione che adotti un uso intelligente dei *TFrame* con all'interno quello che vorresti visualizzare, e affiancarli agganciandoli a pannelli o giocando con gli allineamenti, sfruttando l'area che hai a disposizione nel Form principale dell'applicazione.
 
Ciao,
  Marco.
 
--
MARCO BREVEGLIERI (Software and Web Developer)
#Home: 
http://bit.ly/marcobreveglieri
 
#Blog: 
http://bit.ly/compilaquindiva
 

"Marco Breveglieri"  ha scritto nel messaggio 
news:917c83ec-1845-48ad...@googlegroups.com...
Non lo prenderei in considerazione in quanto già sorpassato da tempo e 
adatto solamente ad applicazioni che lavorano con documenti da visualizzare: 
meglio privilegiare una soluzione che adotti un uso intelligente dei 
*TFrame* con all'interno quello che vorresti visualizzare, e affiancarli 
agganciandoli a pannelli o giocando con gli allineamenti, sfruttando l'area 
che hai a disposizione nel Form principale dell'applicazione.
Ciao,
  Marco.
 
E con dei forms all'interno di un pageControl ? 
 
 
---
Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus.
http://www.avast.com
 
 

> E con dei forms all'interno di un pageControl ? 
 
xche form e non frame?
 
A.

 E con dei forms all'interno di un pageControl ? 
 
Secondo me, è sufficiente "mimare" quelle che sono le interfacce dei programmi che si trovano in giro e che ricalcano grossomodo le funzionalità da realizzare, in termini di organizzazione della UI.
 
Mettere dei Frame (e non dei Form) all'interno di un *TPageControl* non può essere definito giusto o sbagliato a prescindere: se devi fare un programma che visualizza più documenti, allora può essere adatto, mentre in altri contesti potrebbe non esserlo.
 
Pensando alle cose da mostrare, io metterei su carta una bozza di interfaccia da realizzare che soddisfi i requisiti, poi passerei a vedere quali sono i controlli giusti per implementarla fisicamente nel software.


 E con dei forms all'interno di un pageControl ?
xche form e non frame?
A.
 
La domanda non è reversibile ?
(forse perchè sono più abituato ai form) 


 poi passerei a vedere quali sono i controlli giusti per implementarla fisicamente nel software.
 
Io ho sempre cercato di ricalcare UI dei programmi più usati per 
scoprire, alla fine, che molti miei clienti non sapevano usare per 
niente i programmi più usati.
 
Non se terminare con :) o con :(
 
-- 
@WarpTen10

 (forse perchè sono più abituato ai form) 
 
..quindi, il concetto è "ho lavorato sempre cosi?"? :-|
 
A.

> Io ho sempre cercato di ricalcare UI dei programmi più usati per 
 
che vuol dire "più usati"?
 
A.
 
 
 

 che vuol dire "più usati"?
 
Browser a pagine.
Ogni pagina un elenco o una scheda (cliente, fornitore, fattura...).
 
Niente ribbon perché molti miei clienti adottano ancora Office2003.
 
-- 
@WarpTen10

Non è assolutamente detto che siccome gli altri fanno in un modo hanno ragione. 
 
Ricordo ancora l'interfaccia utente di "Esatto", prodotto da Esa Software, ti faceva veramente incazzare per alcune scomodita'.
E stiamo parlando di una azienda che negli anni scorsi era tra i leader nel settore dei gestionali a livello nazionale, insieme a Zucchetti e e pochi altri.
 
Un conto è prendere spunto, un conto è imitare in modo bovino.
 
 
A.

 Niente ribbon perché molti miei clienti adottano ancora Office2003.
 
Se hai a che fare con clienti dalle esigenze specifiche, allora il discorso non si applica.
 
Se i tuoi clienti non vogliono avere a che fare con delle schede, si tratta di un requisito su cui puoi tentare di fare leva per rimuoverlo, ma ciò non toglie che il "Tabbed Browsing" in generale sia un successo mondiale e largamente impiegato anche in altri software oltreché nei browser.


 ...il "Tabbed Browsing" in generale sia un successo mondiale e largamente impiegato anche in altri software oltreché nei browser.
 
I miei! :)
 
-- 
@WarpTen10

 Non è assolutamente detto che siccome gli altri fanno in un modo hanno ragione.
 
No, ovviamente, ma non si deve nemmeno inventare un modo completamente 
diverso di fare una cosa ovvia come ho visto fare da un sw sotto Windows 
che obbligava l'utilizzatore a premere ? + TAB per avere l'elenco delle 
voci da cui scegliere per inserirle nel campo.
 
Il cliente vuole che il software funzioni in un modo solo: come vuole lui.
 
-- 
@WarpTen10

 che obbligava l'utilizzatore a premere ? + TAB per avere l'elenco delle 
 
Davanti alla demo di un software che fa ste cose, il "dimostratore" sarebbe cortesemente accompagnato alla porta senza possibilita' di appello.
 
A.
 
 

 Davanti alla demo di un software che fa ste cose, il "dimostratore" sarebbe cortesemente accompagnato alla porta senza possibilita' di appello.
 
Erano anni che lo usavano.
 
-- 
@WarpTen10

grazie per i suggerimenti
 
 
e se usassi una comunicazione tra unit ?
 
parte da unit_A-> unit_B--unit_C-> che infine torna a dire ad unit_A cosa e' successo
 
non so però, se cambiando il focus su 3 unit/form riuscirei a cambiare la statusbar con i pulsanti del form su cui vi è il focus


dipende, se la statusbar che controlla i pulsanti è su unitA,
quando unitB cambia lo stato (da Browse a Edit) può comunicare a unitC
la variazione e unitC a sua volta comunicarlo a  unitA, che dovrà avere 
un metodo pubblico per ricevere dei parametri;
tra  i parametri servirà il nome del form, per potere rintracciare quale
form ha variato il suo stato.
che ci siano 1 o n form non ha importanza, devi solo comunicare a unitA, 
nomeForm e stato.
la cosa è certamente fattibile, ma perchè non provi ?
l'idea del ng è una cosa, che può sostituirsi alla implemetazione pratica.


lo so, ma putroppo  da neofita delphi (come da oggetto) non sono ancora in grado di provare da solo e quindi sto facendo uno studio di fattibilità :)
 

>
nessuno e' nato con Delphi nel dna, ma solo provando e sbagliando; in 
Delphi come in altri linguaggi; si riesce a capire.
parti da un Form con un TButton, provi a fare qualcosa come al click sul 
TButton mandare una stringa ad un'altro form, e poi un passo alla volta 
provi a fare altre cose.