20/04/2024 - grumpy ha scritto:
Ehi calma! La mia era solo un'osservazione innocente di tipo generico. Apprezzo comunque la tua ironia.
Ironia era. :)
20/04/2024 - grumpy ha scritto:
Dal mio personale punto di vista, per quel poco che possa valere, mi pare che la principale obiezione all'uso dei form MDI sia… che sono passati di moda e quindi, essendo per natura contrario alle mode, io continuo ad usarli con soddisfazione
Capisco il punto di vista, nel senso che pure io sono contrario alle “mode in quanto tali”, ma qui le valutazioni sono meramente tecniche: un paradigma che non viene più utilizzato e che risulta fuorviante per molti utenti (la UX non è un aspetto secondario, e non è una questione di moda), una API che è stata deprecata dal produttore e che non viene più aggiornata, una serie di bug visuali fastidiosi per me che sviluppo e per l'utente che deve usare, infine una strada molto incerta soprattutto per nuovi progetti, in quanto non è dato sapere che fine farà quell'interfaccia nelle prossime versioni di Windows, esistendo comunque alternative valide.
20/04/2024 - grumpy ha scritto:
il form MDI, se si vuole, circoscrive l'area di lavoro dell'intera applicazione a una porzione dello schermo, evitando interferenze con finestre estranee all'applicazione
Questo vale per qualsiasi applicazione che ospita banalmente “controlli” al posto di finestre.
20/04/2024 - grumpy ha scritto:
Anche con una struttura “a tab” si può ottenere questo risultato, ma la fase di design è più complicata non potendo visualizzare separatamente i singoli tab.
Prima o poi ci farò un video, ad ogni modo questo design non è così complicato come sembra; inoltre, una volta realizzato, può essere facilmente “componentizzato”, ossia racchiuso in una libreria e riusato in qualsiasi progetto.
20/04/2024 - grumpy ha scritto:
nel form MDI di solito è presente una toolbar e/o una barra dei menu da cui si attivano azioni relative all'intera applicazione, mentre una toolbar di una finestra figlia consente azioni solo verso quella finestra
Questo (e pochi altri) sono senz'altro gli unici vantaggi che a oggi offre l'approccio MDI: è facile e immediato da utilizzare. That's it.
Dal mio punto di vista, questa immediatezza - sempre al giorno d'oggi intendo - non vale i “mal di pancia” e le limitazioni visuali e funzionali che procurano in seguito, dando per scontato che il progetto non sia banale e che debba avere una sua evoluzione e manutenzione negli anni.
20/04/2024 - grumpy ha scritto:
Il possibile problema evidenziato nelle immagini che hai postato mi sembra che si possa evitare facilmente con le proprietà relative ai pulsanti Minimize e Maximize e al tipo di bordo o, al limite, con l'evento Resize.
Ogni workaround è tale: un escamotage, un aggirare il problema. Ne ho fatti diversi anche io su applicazioni legacy di clienti che a oggi hanno smesso di funzionare. E come sempre non c'è alcuna garanzia per quanto riguarda le versioni future di Windows. Infatti, tutti questi “glitch” che ho mostrato negli screenshot non sono usciti dall'oggi al domani, ma si sono gradualmente presentati release dopo release di Windows, proprio per il fatto che quell'API non ha subito aggiornamenti rispetto al resto (perché Microsoft stessa non la considera più).
In ogni caso, se proprio devo scrivere comunque codice o fissare delle proprietà in modo specifico, allora preferisco farlo per soluzioni appropriate. :)
20/04/2024 - grumpy ha scritto:
Tornando alla domanda iniziale di Zeusmax, nel caso volesse ancora usare l'approccio parent/child, non capisco per che frmPlanner non possa essere anch'esso di tipo child.
Infatti, secondo me il problema originale è legato al fatto che poi - volendo adottare l'approccio MDI - c'è chi vorrebbe “piegarlo” per funzionare diversamente da contesto a contesto, cosa non possibile (almeno non sempre) perché altrimenti sfumerebbe in toto il vantaggio di utilizzarlo. :)