Newsgroup: it.comp.programmare.win32
Titolo: .NET

Ciao a tutti,
sto provando ad usare il C# sotto il framewwork .NET con Visual studio
2010. Sono veramente deluso dal constatare che anche per le piu
elementari funzionalita da applicare ai vari controlli bisogna sempre
far ricorso alle API native. Ad esempio per inserire un'immagine in un
subitem di un ListView oppure per inserire una scroll bar orizzontale
in un combobox.  Ma questi framework non dovrebbero servire proprio
per evitare il ricorso alle API native e avere oggetti comodamene
usabili e di facile gestione ?

 sto provando ad usare il C# sotto il framewwork .NET con Visual studio
 
Ragazzi qualcuno mi riporta le sue impressioni sulla mia riflessione ? 
Voi lo usate il framework .NET ? Come vi trovate ?
 
 
 
 


Il motivo per cui hai questo tipo di difficoltà è che stai usando 
Windows Forms che è un mero wrapper della GUI Win32. Alcune 
funzionalità non sono esposte e quindi ecco la necessità di ricorrere a 
PInvoke.
Devo dire che con Winform non è così ricorrente ma effettivamente è 
necessario.
 
Dal 2005 è disponibile WPF (che usa XAML) che è ormai la GUI 
preferibile per lo sviluppo desktop su Windows.
Con WPF non hai mai necessità di usare le chiamate native per quanto 
concerne l'interfaccia grafica e hai numerosi altri vantaggi:
- performance nettamente superiori (la grafica gira su GPU)
- binding dei valori esposti sui controlli così da evitare di dover 
leggere/scrivere i valori sui controlli ogni volta
- styling dei controlli in modo da rendere più uniforme lo stile della 
tua app
- uso dei temi per poter cambiare in blocco lo stile grafico dell'app
- uso dei template che consentono di comporre in modo arbitrario i 
controlli. Per esempio dentro una listbox puoi dire che ogni elemento è 
uno user control che contiene immagini, scritte, altre liste, e tutto 
quello che vuoi.
- layout basato su diversi pannelli che permettono un allineamento 
"elastico" che esegue automaticamente il resize adattandosi a schermi 
di risoluzione differente (o con dpi differenti)
... e molto altro.
 
Il consiglio quindi ... è di passare a WPF e di lasciar perdere 
Winform. Se possibile parti già da subito utilizzando il pattern MVVM 
che è perfetto per lo sviluppo WPF.
 
 
Se poi vuoi sviluppare le app di nuova generazione per Win8, lo XAML è 
molto simile (subset) di quello di WPF.
 
-- 
Raffaele Rialdi  
http://www.iamraf.net
 
Weblog: 
http://blogs.ugidotnet.org/raffaele
 
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
 
UGIdotNET - 
http://www.ugidotnet.org/
 
 
 

 Il consiglio quindi ... è di passare a WPF e di lasciar perdere Winform.
 
Grazie del suggerimento. XAMl mi sembra di aver capito trattasi di un 
linguaggio di markup che alla fine genera codice .NET . I vantaggi da te 
enumerati da cosa derivano visto che sotto sotto il codice usato e' lo 
stesso?
 

stesso?
 
Provo a rispondermi da solo.
XAML si appoggia ai controlli implementati in WPF non disponibili
sotto WinForm. Questi controlli sono implementati in una maniera molto
piu funzionale per cui si presume debbano avere praticamente tutto
quello che uno sviluppatore necessita. Sarebbe da chiarire cosa
succede se per qualsiasi motivo vi fosse necessita di uscire dal
codice "preconfezionato". Quello che non capisco e' perche Winform non
ha implementato direttamente questi controlli.
Diverso il discorso per  MVVM che potrebbe essere molto interessante
come nuovo approccio alla realizzazione del software.
Spero di non aver detto castronerie. 


 
Da tutta l'infrastruttura (liberie + dispatcher) che c'ï¿œ dietro.
Winform come dicevo ï¿œ solo un wrapper e quindi c'ï¿œ sempre la message 
pump con i controlli base Win32 che dettano le regole.
Per esempio una textbox o un button ha quella forma perchï¿œ ï¿œ disegnato 
cosï¿œ in kernel mode da windows. Rifarlo con winform ï¿œ una enorme 
perdita di performance perchï¿œ la tua app gira un user mode e quindi hai 
montagne di context switch da user a kernel mode.
Inoltre la maggior parte delle chiamate ai controlli winform finiscono 
in una pinvoke che ï¿œ notoriamente poco performante.
 
In WPF invece hai il dispatcher che funge da coda al posto della 
message pump e il rendering non avviene al momento in cui lo esegui 
dall'applicazione ma viene passato a DirectX che provvede a fare il 
merge dei vari strati in modo da poter realizzare in modo 'economico' 
anche le trasparenze (nelle trasparenze ridisegnare le stesse zone ï¿œ 
eccessivamente dispendioso, invece in WPF avviene prima il blend 
'logico' e poi l'effetivo disegno)
 
Con questa logica disegnare un controllo base o uno custom ï¿œ del tutto 
indifferente e quindi puoi descrivere in xaml il contorno del tuo 
bottone a zig zag. Il codice generato ï¿œ C# ma alla fine quello che 
conta ï¿œ che chiami una primitiva che passa al dispatcher le istruzioni 
di redraw.
Al momento in cui tutto il blocco del redraw finisce a WPF, lui usa 
DirectX per disegnarlo e che puï¿œ avvalersi della GPU.
Tra l'altro dentro l'sdk c'ï¿œ un tool di performance di WPF che ti 
permette di vedere quanta memoria GPU stai usando, e ti fornisce 
parametri che ti permettono di migliorare le performance.
 
Fai una prova, la differenza in performance ï¿œ abissale.



Winform non può fare nulla di diverso perché usa GDI e User32 che 
lavorano a livello kernel nel sistema operativo.
Quindi per usare GDI e User32:
- devi necessariamente passare da quelle API che sono native (costi di 
pinvoke)
- gdi e user32 non usano la gpu e sono molto meno efficienti rispetto a 
DirectX
 
WPF è totalmente managed per cui non hai per esempio chiamate a 
Dispose. I veri vantaggi di questo approccio sono, come già detto, 
binding, styling, template, solo per citarne alcuni.
 
 
Per il 'codice preconfezionato' credo di averti risposto nell'altro msg
