Newsgroup: it.comp.programmare.win32
Titolo: Quando è che serve passare a MDI?

Ciao,
sto scrivendo un piccolo disassembler, che conto
poi di mettere su Sourceforge quando funzionerà a
dovere (o quando mi sarò stancato io di aggiungere
roba e funzioni... :-) se non che sono arrivato a un
punto critico: mi sto accorgendo che la sola finestra
del codice assembler, di per sè, non è molto utile:
ci vorrebbe anche una vista della sezione dati... e
magari pure una della sezione risorse. Insomma non mi
basta una sola finestra ma me ne farebbero comodo due
o tre.
Il che mi ha fatto pensare: "E se trasformassi il
programma in un programma MDI?"...
In questo modo avrei la possibilità di aprire quante
finestre voglio senza doverle programmare in anticipo.
MA... quanto è  complicato poi gestire un programma MDI?
Mi conviene riscrivere tutto (più o meno) o mi conviene
arrangiarmi e tirare avanti col modello SDI?

In data Mon, 29 Dec 2003 00:16:51 GMT, Tin Toy ha scritto:
[cut]
Manca una informazione per me fondamentale: in che linguaggio lo stai
scrivendo ? C ? C++ & Win32 ? C++ & MFC ? Nei primi due casi passare ad un
modello MDI ti porta a creare una finestra in piu' (la client area)
all'interno della main (che diventa frame window), poi la creazione delle
mdi child non cambia molto (c'e' la API CreateMDIWIndow mi sembra), hai
sempre bisogno di una class window, window procedure etc etc.
Con le MFC non ne ho la piu'pallida idea.
BTW Il mio mini framework in signature gestisce le applicazioni MDI senza
tanti problemi :-)
Ciao
Stefano "HappyMan" (Lake Maggiore - Italy)
-- 
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) 
despammed.com

 scrivendo ? C ? C++ & Win32 ? C++ & MFC ?
C++Builder per Windows. Quindi C++ & Win32.

, 
massim...@hotmail.com
 says...

...non sono un esperto di C++ Builder...ma dall'idea che mi ero fatto 
leggendo qua e la e provando qualche trial, mi pare si trattasse di un 
"Visual Basic versione C++" :-) ...la programmazione Win32 C/C++ "pura" 
e' ben altra cosa ;-) 
Non confondere la programmazione Win32 C/C++ pura con l'uso di un RAD 
come VB o C++Builder e la "chiamata a qualche API"... 
Se non erro con il C++Builder non devi definire classi di finestra, 
window procedure, switch per gestire i messaggi di Windows, ecc. ...o 
sbaglio?
Dan



Come ha scritto Danguard il C++ Builder, se usato con le sue VCL e' ben
lontano dall'essere "C++ & Win32" :-)
Sorry ma in questo caso non ti so aiutare...


 Sorry ma in questo caso non ti so aiutare...
Beh, direi che puoi aiutarlo col tuo validissimo framework C++! :-) 
Avra' anche il beneficio di un exe ben piu' leggero di MFC, e giacche' 
non gli serve OLE...
Bye
Dan

 e' ben altra cosa ;-) 
Nono, va bene che c'è la VCL che semplifica di molto le cose
ma l'eseguibile risultante è un programma compilato e non un
pcode come col VB. Insomma è proprio un compilatore completo:
se ti gira, escludi la VCL dal progetto e ti metti a scrivere
le classi finestra, il message loop eccetera tutto a manina.
Chiaro che con la VCL a disposizione, col cavolo che lo faccio :-)
Ma il programma finito poi è veloce nè più nè meno di un normale
programma compilato per Windows. Solo, paga un prezzo di 200K
circa per le librerie VCL incluse nell'EXE.

Vedo che la discussione sta partendo per la tangente,
cosě riposto la domanda...
"In Generale", quando conviene fare un programma MDI
e quando invece no?
A prescindere da che linguaggio si sta usando.

 ...non sono un esperto di C++ Builder...
Quindi faresti bene a non aprire bocca sull'argomento (sorvolo sul
paragone col VB che è una vera e propria bestemmia).  In C++ Builder è
possibilissimo adoperare le API allo stesso livello con cui è
possibile farlo con altri compilatori ed ottenere, quindi, uno strato
C++ & Win32 puro.  Per l'OP, mi limito a dire che il modello MDI è
ormai "deprecated" persino da Microsoft.
Difficile trovare nuove applicazioni che usano questo modello.

 o tre.
Il modello MDI non è più consigliabile per nuove applicazioni.
Usa SDI.  In C++ Builder è semplicissimo usare entrambi i modelli.

 Usa SDI.  In C++ Builder è semplicissimo usare entrambi i modelli.
Lo farei, SE fosse possibile creare a runtime più
istanze di una stessa classe finestra che mostrino
sezioni diverse: purtroppo però, non basta un semplice
NEW per creare una seconda istanza di uno stesso form
(ci ho già provato...) ma devo progettare espressamente
ogni finestra che uso. O forse non ne so abbastanza
sulla VCL e quello che mi serve di fare c'è già un
modo per farlo ma io non lo conosco.

 paragone col VB che è una vera e propria bestemmia).
E invece la bocca la apro, (eccome!) precisando che non sono esperto 
sull'argomento, come ho gia' fatto. 
Se poi non vuoi sentire cio' che dico, sei libero di non farlo; se, in 
quanto esperto, hai da fare rettifiche (con calma e rispetto), queste 
sono le benvenute.
Tra l'altro, alcuni mi hanno dato conferma che la programmazione con C++ 
Builder e' cosa ben diversa che la programmazione C++&Win32 pura
:)
Bye

 Difficile trovare nuove applicazioni che usano questo modello.
Gia', Visual Studio .Net 2003 (e' abbastanza recente ?) ha un pieno
supporto per lo stile MDI delle finestre, oltre che a quelle docked, etc
etc. Non sarà quello predefinito ma da qui a dire che e' "Difficile trovare
nuove applicazioni che usano questo modello" ce ne corre.
Prima di dire agli altri di stare zitti bisognerebbe verificare che quanto
si dice in prima persona non sia peggio di cio' che si critica.
Stefano "HappyMan" (Lake Maggiore - Italy)
-- 
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email sg2004 (at) 
despammed.com

 Usa SDI.  
Chi dice che non e' piu' consigliabile ? Mi interessa saperlo.
Puoi linkare la fonte, un testo, un qualcosa che ne spiega i motivi ?


 Builder e' cosa ben diversa che la programmazione C++&Win32 pura
Già. Infatti con BC++B hai già tutte le classi mentre
altrimenti te le dovresti scrivere tu a mano. Sai che
divertimento... a parte che io li vorrei vedere quelli
che programmano in Windows solo col C++ e le API... e
vorrei pure vedere che programmi tirano fuori. Ci arrivano
a 300Kb?
E comunque, non è "cosa ben diversa": è la stessa cosa,
solo che oltre alle API puoi usare anche la VCL. Hai una
marcia in più, un framework che puoi decidere di sfruttare
o meno, a seconda di come ti va. Sei libero.

 a 300Kb?
Oh ? Qualcuno ha chiamato ? :-) Eccomi qui: sviluppatore *anche* C++ &
Win32 "pure" (oltre che VB6, VB.Net, e da poco ASP.Net)
Se vuoi vedere un programma scritto solo con le api puoi scaricare il mio
SQL Editor (vedi sito in signature), puro codice "massacrante" Win32, ma la
soddisfazione e' stata tanta :-)
Chiaramente quando la produttivita' e' l'unica cosa che conta passo ad
altro ma per progetti "personali", che porto avanti nel tempo libero e/o
senza scadenze...le Win32 sono le mie preferite.


 Il modello MDI non è più consigliabile per nuove applicazioni.
taci, pezzo d'asino. Siamo quasi nel 2004. Tienici le tue superstizioni 
alla larga
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 si dice in prima persona non sia peggio di cio' che si critica.
Rimbalzo il consiglio: informati, prima di parlare.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Idiota, sei tu che fai bene a tacere.


 ogni finestra che uso. 
In che senso ? C++ Builder ti costruisce una *classe* form.
Poi questa la puoi istanziare n volte.


 :)
A parte che non capisco proprio in che contesto si inquadri questa tua
osservazione su "C++ & Win32 pura", a partire dalla domanda del poster
originale, le presunte "conferme" che hai avuto valgono ben poco, viste le
risposte.  C++ Builder è un ambiente RAD e questo è sacrosanto, ma è
*ANCHE* un ambiente RAD, non *SOLO*.  Questo significa che se da un lato
ti da modo di usare VCL, MFC e quant'altro per scrivere applicazioni in
modo veloce, nulla ti vieta di implementarti la tua bella finestrella con
tanto di window procedure e un bel loop di recupero dei messaggi e
dispatch, analogamente a uanto faresti con la tua programmazione "pura". 
Un ultimo punto: se ti stessi rivolgendo a me, direttamente, allora potrei
anche ignorare quanto scrivi (e stai tranquillo che lo farei); il problema
è che sei in un ng, ti stai rivolgendo ad altri, quindi assicurati di
conoscere bene ciò di cui stai parlando.


 dispatch, analogamente a uanto faresti con la tua programmazione "pura". 
OK, punto chiarito.
Cmq, io personalmente non ho niente contro il BC++Builder, ne' contro i 
suoi utenti :) Semplicemente, osservo che e' cosa ben diversa sviluppare 
un programma con un ambiente in cui si fa drag-and-drop dei componenti, 
si fa doppio click per gestire un evento, e simili... ed un modo di 
programmare invece in cui devi partire dalla WinMain(), registrare 
classi di finestra, scrivere la WindowProcedure, intercettare eventi, 
wParam, lParam, ecc.
E questo, ripeto, prescinde dal discorso BC++Builder o altro.
Aggiungo anche che, se si hanno vincoli di tempo o altro, non c'e' 
niente di male, a priori, nello scegliere un ambiente RAD.
La cosa che mi ha dato fastidio (e ovviamente non accetto) e' l'incipit 
del tipo "tu non capisci, stai zitto". Si tratta se non altro di buona 
educazione (anche su ng).

 o meno, a seconda di come ti va. Sei libero.
Per l'ultima (spero :) volta, dico che la programmazione Win32 "pura": 
scrivere WinMain(), registrare finestre, scrivere window-procedure, 
intercettare eventi, inviare messaggi a controlli per modificarne lo 
stato e il comportamento [es.: avete provato ad usare il list-view-
control o il tree-view da API? :) ], lParam, wParam, LOWORD(), HIWORD(), 
[per non parlare poi di definire controlli custom...] ecc. e' cosa ben 
diversa dal fare drag-and-drop da una palette, e qualche click per 
modificare proprieta' o gestire eventi, ecc. Questo indipendentemente da 
BC++Builder o altro.
Rimarco anche che, non ci vedo niente di male se uno usa un ambiente 
piu' o meno RAD, per semplificarsi la vita, se ha vincoli di tempo, o 
altro.
Bye!
Dan

 modificare proprieta' o gestire eventi, ecc. 
Appunto, č un'inutile complicazione, specie in un contesto in cui č
necessario essere produttivi (come tipicamente č qualsiasi ambiente di
lavoro serio).  Se si ha voglia e tempo di divertirsi, allora si usino le
API.  La storia dei real programmers che lavorano in assembly č trita e
ritrita.


 educazione (anche su ng).
Stravolgi quanto leggi pro domo tua: non ho mai messo in dubbio le tue
capacità di comprendere quanto dico, difatti non starei qui a risponderti.
Per essere precisi, non ho mai neanche detto che, in assoluto, devi stare
zitto.  Ammetterai, viceversa, che il fatto di non essere esperto di un
argomento (al punto da non conoscerlo proprio, come tu hai dimostrato) è
ragione sufficiente per astenersi dall'esprimere giudizi.  


 API.  
Siamo d'accordo.
Bye
Dan

Puoi linkare la fonte, un testo, un qualcosa che ne spiega i motivi ?
"Note  MDI is an application-oriented model. Many new and intermediate
users find it difficult to learn to use MDI applications. Therefore,
many applications are switching to a document-oriented model.
Therefore, you may want to consider other models for your user
interface. However, you can use MDI for applications which do not
easily fit into an existing model until a more suitable model is
introduced."
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/multipledocumentinterface.asp
-- 
S.L.

programmi).
Ok, ti lascio arrampicarti sui vetri...buon viaggio.
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email happyman69 (at) 
despammed.com

 Ok, ti lascio arrampicarti sui vetri...buon viaggio.
E io ti lascio alla tua abissale incompetenza, informati, ignorante.
Siccome sono buono, mi sono premurato di cercare per te un pò di messaggi
su Google che contenessero un pò di paroline magiche.  Ecco, ad esempio,
cosa dice Jeff Overcash (tanto per intenderci: appartenente al gruppo di
esperti TeamB di Borland):
"For instance MS Word has never been a MDI app.  It has looked and felt
like one, but MS always simulated MDI and did not use the OS supplied MDI
operations.  AFAIK, MS hasn't released a true MDI app in years, they
continue to use their simulated MDI instead of fixing the bugs in the MDI
implementation contained in the OS.  Back when Win95 came out MS officially
discouraged the use of MDI applications."
..o Kurt Barthelmess (sempre del TeamB):
"You might want to talk with MS. My understanding is that they are
discouraging all future use of MDI in favor of SDI. (If they tell you
that is not the case, ask them why they have not fixed any of the bugs
in MDI since Win 3.0<g>.)"
..ne trovi tanti altri in rete.  Buona ricerca.



http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/multipledocumentinterface.asp
Grazie per il link. 
pensavo lo postasse Andrea La Forgia che invece mi riporta le
riflessioni di uno del TeamB di Borland.
Peraltro in queste righe leggo che il modello MDI e' utilizzabile fin
tanto che non si trova un modello differente che meglio si adatta
all'applicazione che si deve scrivere. Questo vuol dire "deprecated"
in gergo Microsoft (cosi' come ha scritto La Forgia ?), e' una domanda
vera, non retorica :-)


 vera, non retorica :-)
Sě, č ciň che generalmente si intende per "deprecated".  
Piccolo suggerimento: vai su 
groups.google.it
 e cerca per "Microsoft is
moving away from MDI".


moving away from MDI".
Ci sono molti risultati in merito, alcuni sono discussioni su forum
nel quale si cerca di capire se in effetti Microsoft stia abbandonando
tale stile di interfaccia, altri sono produttori di componenti per
migrare tale tipo di interfaccia ad un altro (e mi sono limitato alle
prime 3 pagine di link): valore informativo ? 0.
Di documenti ufficiali Microsoft per ora c'e' solo il link precedente
dove a tuo giudizio tale stile sarebbe "deprecated".
Per il resto leggi l'altro mio post che mando in contemporanea.
Bye super uomo.


esperti TeamB di Borland):
Potevi citarmi anche il Papa. Fino a prova contraria e' Microsoft che
decide come devono essere le interfaccie, non la Borland o i suoi
programmatori, soprattutto quando riportano una loro *impressione*
("My understanding is that they are discouraging...")
Bye bye super uomo.


 TT: C++Builder per Windows. Quindi C++ & Win32.
Io credo che nella domanda inziale SH intendesse con C++&Win32 quello 
che lui sostanzialmente ha fatto col suo framework: scriversi tutto da 
zero, a partire da WinMain(), senza drag-and-drop alla RAD. ...ed e' 
cio' che la gente normalmente intende con programmazione "C++ & Win32". 
Che poi cio' si possa fare con BC++Builder a me va bene. 
Pero' TT voleva usare le VCL, mi pare (quindi drag-and-drop, e approccio 
RAD), allora direi che la sua risposta non doveva essere "[...] Quindi 
C++ & Win32".
Io volevo semplicemente puntualizzare: programmazione C++&Win32 e' cosa 
ben diversa dalla programmazione RAD con drag-and-drop di componenti, 
ecc.
...e questo lo si puo' affermare anche senza essere esperti di 
C++Builder :)
Ciao,
Dan

 o device-driver, ecc. la scelta di un RAD non penso sia adatta :)
No.
Non ci sei proprio.
Tu quando parli di RAD hai sempre in mente il Visual Basic
interpretato. Ecco perchè non riesci a capire il punto.
Un programma creato con le VCL in C++Builder è COMPILATO.
COM - PI - LA - TO.
Se mi gira, posso scrivere con C++Builder un driver hardware
e metterci PURE la VCL per gestire una dialog di opzioni
senza che questo lo rallenti di un solo nanosecondo.
E se mi gira di più posso usare il C++Builder e la VCL per
scrivere e gestire l'editor di un programma di rendering
tipo 3DStudio, scriverne il motore di rendering in C++ col
C++Builder senza chiamare manco una funzione della VCL e
avrò un renderer veloce quanto qualunque altro programma
di rendering. Anzi, se faccio un buon lavoro potrei pure
crearne uno PIU' VELOCE ANCORA.
Il C++Builder è un compilatore C++ a tutti gli effetti.
Che ha anche una libreria di classi, COMPILATE ANCHE LORO,
in aggiunta a tutto il corredo delle API di Windows.
Tu non conosci il C++Builder, non sai cosa può fare.
Io sì. E ti dico che lo stai CLAMOROSAMENTE sottovalutando.

 Io sì. E ti dico che lo stai CLAMOROSAMENTE sottovalutando.
OK! Ti (e vi) chiedo scusa se ho dato l'impressione di sottovalutare il 
C++ Builder. Ribadisco: non ho personalmente niente contro il 
C++Builder, ne' contro i suoi utenti. :-)
Colgo l'occasione per fare a tutti auguri di Buon Anno nuovo! :)
Bye
Dan

vera, non retorica :-)
   Onestamente non lo so. Pero` direi che l'uso non e` consigliato.
   Il resto sono illazioni, pero` anche io, in effetti, non mi aspetto
che la Microsoft continui a lavorare sul supporto per MDI, dopo
un'affermazione del genere.
-- 
S.L.

 un'affermazione del genere.
Mi sfugge qualcosa: cosa dovrebbe ancora fare Microsoft per il supporto MDI
? Ci sono delle API (CreateMDIWindow, DefFrameProc, messaggi vari, etc.)
che esistono da Windows 95 a XP. Non ho visto su MSDN esplicitamente un
solo avvertimento che tali API sono "deprecated", e non certo perche'
Microsoft eviti di usare tale termine quando e' il caso (esempio l'API
Win32_DisplayConfiguration). Non essendo state dichiarate esplicitamente
*deprecated* o *obsolete* tale API saranno presenti anche in futuro: il
successore di Windows XP avra' un sistema di API diverso (WinFX) che
Microsoft ha dichiarato compatibile 100% con le Win32
(
http://msdn.microsoft.com/longhorn/
) quindi *anche* con le api legate a
MDI.
Cosa dovrebbe fare Microsoft di piu' per questo stile di interfaccia ?
Ciao e buon capodanno :-)
Stefano "HappyMan" (Lake Maggiore - Italy)
-- 
The Personal Framework for Object Oriented Windows Development (Win32)


Cosa dovrebbe fare Microsoft di piu' per questo stile di interfaccia ?
   Mi pareva di aver specificato che erano illazioni, comunque,
sottolineando che sono opinioni *personali*: a parte il fatto che c'e`
qualche problemino nella gestione delle finestre figlie da sempre, a
me MDI non piace.
   *Per me* un'applicazione MDI ha un aspetto obsoleto, vecchio e
sgradevole. *Per me* erano piu` tollerabili le finestre ridotte a
icona del program manager di windows 3 (credo che sia la prima
applicazione MDI che ho mai visto) rispetto a quegli agghiaccianti
rettangolini sparsi per la client area, la navigazione tra le finestre
e` scomoda e inefficiente, 
p.es
. affiancare due finestre e`
scomodissimo per l'utente (a meno che non si accontenti della
suddivisione di default dell'auto-tile).
   Il resto della GUI di windows ha fatto enormi passi avanti sia
graficamente che funzionalmente, MDI sta sempre la`, anche su windows
XP.
   Poiche`, come ho gia` detto prima (ho detto che e` un'opinione
*personale* vero?) non mi aspetto che la Microsoft faccia sforzi per
migliorarla, rinuncio allegramente al suo uso ogni volta che sia
possibile.
   Quanto sopra e` un'opinione personale, non intende in alcun modo
essere verita` per alcuno al di fuori di me.
-- 
S.L.

In data Fri, 02 Jan 2004 15:43:09 GMT, S.L. ha scritto:
[cut]
Non ho ben capito: era una tua opinione personale ? :-)
Avevo capito che le tue erano considerazioni personali e mi chiedevo cosa
avrebbe dovuto fare Microsoft per te per ..etc etc
Caspita non pensavo che l'argomento MDI toccasse cosi' tanti nervi
scoperti...
Stefano "HappyMan" (Lake Maggiore - NO)


scoperti...
   Colpa mia! E` che odio finire dentro flame e pecco di eccesso di
difesa :)
-- 
S.L.

 suddivisione di default dell'auto-tile).
scusa, ma: chissenefrega? Windows non fa le finestre irregolari. Eppure 
esiste Sonique. Nč Windows ha un controllo splitter standard. Eppure il 
regedit ha uno splitter verticale. Windows puň posizionare il menu solo 
in cima alla finestra. Eppure in Office si puň mettere anche di lato in 
verticale. Microsoft non lavora piů a MDI? pace. Anzi, pure meglio: non 
rischiamo piů di trovare soluzioni che andranno in conflitto con quelle 
ufficiali


 ("My understanding is that they are discouraging...")
La MS talvolta può essere considerata arrogante, per esempio: non ha mai
ammesso diversi errori per cui è stata criticata, però si sa che ha
sempre ascoltato tali critiche, ritenendole più che fondate: lo dimostra
- caso più eclatante - l'abbandono del vecchio VB in favore di .NET...
Tirando le somme: *tu* non vuoi ammettere un errore di conoscenza di
fronte a qualche persona di remoto thread di un remoto newsgroup, ma
pretendi che la *MS* riconosca di fronte al mondo intero un errore che
porta avanti da diversi lustri? ...misteri della logica! <eg>
Buon 2004,
Maverick

 porta avanti da diversi lustri? ...misteri della logica! <eg>
1. Vuoi che ammetta che non sapessi che il TeamB della Borland avesse
riflettuto sul fatto che per *loro* Microsoft stesse per abbandonare il
modello MDI ? Lo ammetto.
2. Vuoi che ammetta che su decine di ng/mailing list si parli del fatto che
*per le persone* che discutono in tali luoghi Microsoft stia per
abbandonare il supporto a MDI ? Lo ammetto.
3. Vuoi che ammetta che Microsoft nei propri s.o. abbia tolto il supporto a
MDI o lo abbia definito *deprecated* in MSDN e non faccia piu' applicazioni
che funzionano secondo *anche* lo stile MDI (emulato o no per l'utente e'
trasparente) ? Dimostralo (io ho citato un prodotto RECENTE di Microsoft
che lo supporta pienamente, lo uso tutti i giorni) e lo ammettero'.
Buon 2004 anche a te :-)
Stefano "HappyMan" (Lake Maggiore - NO)
-- 
The Personal Framework for Object Oriented Windows Development (Win32)


In data Sun, 04 Jan 2004 20:22:29 GMT, Maverick ha scritto:
[cut]
Piccola aggiunta: ho appena installato Microsoft Visio 2002 SR1 (e' un
prodotto Microsoft abbastanza recente ?): i documenti sono gestiti in
*pieno* stile MDI, con tanto di menu "Finestra" con le opzioni "Affianca" e
"Sovrapponi". E' emulato ? Non lo so ma come utente non mi interessa, le
funzionalita' MDI sono le stesse di Microsoft Office 95, con le finestre
iconizzate messe in basso nella client area, il tasto CTRL 6 per muoversi
tra le finestre, etc. Alla faccia del mancato supporto di questo stile da
parte di Microsoft per le recenti applicazioni.
Questi sono dati di fatto che io porto a sostegno della mia tesi, voi (tu e
LaForgia) dovete ancora argomentare le vostre, senza possibilmente citarmi
vostro cugggino che ha letto che il TeamB pensa che ..etc etc e senza
possibilmente dare dell'ignorante in modo del tutto gratuito al prossimo se
la pensa diversamente da voi.
Ciao
Stefano "HappyMan" (Lake Maggiore - NO)
-- 
The Personal Framework for Object Oriented Windows Development (Win32)


ufficiali
   Agree. :)
-- 
S.L.

 - caso piů eclatante - l'abbandono del vecchio VB in favore di .NET...
Hai usato decisamente la parola migliore per descrivere la cosa: abbandono.
Il modo in cui hanno gestito il passaggio da VB6 a VB.Net mi ha convinto
ad attuare a medio termine l'abbandono di VB6 per i frontend *ma* a non
fare il passaggio a VB.Net (e ad evitare se possibile il C#).
un Lorenzo che il problema e' riuscire a gestire la fase di transizione.

 arrangiarmi e tirare avanti col modello SDI?
A parte la solita testa calda che si diverte palesemente
a far arrabbiare a turno i partecipanti del ng (ed ha perfino un
ammiratore!),
posso riportare la mia modesta esperienza di programmatore.
Io sono passato a MDI e lo rifarei.
Da molti anni implemento MDI (via MFC) con soddisfazione
e senza problemi.
Non nego la difficoltà incontrata nell'implementarla la
prima volta.
Il mio contributo, che si basa sulla MIA esperienza,
è che si riescono a gestire più sessioni, documenti, simulazioni,
ecc.  molto semplicemente con MDI. 
Nulla vieta che uno si faccia un super
Documentone-Interfaccione-Galattico...:-)
Saluti
JJ
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ogni finestra che uso.
for (; tutte_le_volte_che_vuoi; )
   new TFormPippo(parametro_che_discrimina_il_comportamento_del_form);