.NET

[xnoise]

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 ?

[xnoise]

Il 31/12/2012 15:32, xnoise ha scritto:
> Ciao a tutti,
> 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 ?

[Raffaele Rialdi [MVP]]

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/

[xnoise]

Il 03/01/2013 19:31, Raffaele Rialdi [MVP] ha scritto:

>
> 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?

[xnoise]

On Fri, 04 Jan 2013 13:26:17 +0100, xnoise <xno...@mail.it> wrote:

>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?

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.

[Raffaele Rialdi [MVP]]

xnoise wrote:
> Il 03/01/2013 19:31, Raffaele Rialdi [MVP] ha scritto:
>
>>

>> 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?
>

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.

[Raffaele Rialdi [MVP]]

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