Newsgroup: it.comp.lang.visual-basic
Titolo: ...ma il WPF...

...lo usate voi ?
Io uso solo i Windows Form. A quanto mi sembra di capire dalla mia 
'Bibbia' del VB .NET (Michael Kofler, 'Visual basic 2008', 1333 pagine,
che NON ho assolutamente intenzione di andare a spulciarlo tutto, a meno 
che non mi informi su qualcosa di nuovo che cambi totalmente la mia 
vita) che la maggiore differenza è quella di poter avere la GUI in forma 
xaml. Queesto indubbiamente è una ottima cosa, perchè rende la GUI molto 
più flessibile. Ma per il resto ?
C'è qualcuno che lo usa ? Ha delle differenze sostanziali/eclatanti 
rispetto ai Windows Form ??

Ciao John,

abisso, il giorno e la notte.
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com/profile/mauro
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it

 rispetto ai Windows Form ??
abisso, il giorno e la notte.
**********************************
Il passato ed il futuro......il futuro?
Uhmmm.... Windows 8, Silverlight.... ;-)
---------------------------
Mauro Gamberini
Microsoft MVP - Excel
http://www.riolab.org/
http://www.maurogsc.eu/
 


Vabbè ragazzi, siete riusciti a incuriosirmi.
Sono disposto a leggermi tutte le 1333 pagine se, (come state insinuando 
voi) cambierà la mia vita drasticamente.
Potreste spendere due righe a spiegare 'summa summarum' in che cosa 
cambierà la mia vita ? produrrò di più lavorando meno ? si alza il 
'livello' di interfaccia human-computer ? con una linea di comando 
riuscirò a leggere un file binario e plottare i risultati come in MatLab ?
Che cosa c'è di così eclatante ? Ditemelo che muoio di curiosità... :-))))

> Uhmmm.... Windows 8, Silverlight.... ;-)
Traduco un pezzo di articolo da un forum di discussione (tedesco) :
http://www.heise.de/developer/artikel/WPF-versus-Windows-Forms-Die-Diskussion-353457.html
" per applicazioni di tipo 'business' laddove le cose più importanti
sono leggere e scrivere dei dati su database e produrre 
rapporti/tabelle, WPF non è assolutamente niente così produttivo come 
Windows Form".
Sembra che il famoso 'abisso', da come è scritto qui, sia a favore di 
Windows Form, se si parla di produttivitá aziendale in campo 
'gestionale' e non  'illustrativo'. Per il secondo puo' darsi che invece 
l'abisso sia a favore di WPF.
Questo è quanto ho attinto in rete, così alla spicciola, in due minuti. 
Ma se qualcuno vuole aggiungere altri commenti sarò molto contento di 
sentire e imparare di più sull'argomento.
Specialmente se qualcuno ha esperienza diretta, mi piacerebbe ascoltare 
la sua opinione.

 la sua opinione.
io sto migrando da windows form a wpf!!
io sono un ingegnere civile che produce software per produttività
interna. lavoro con la grafica (cad, gis ecc) e da quando è uscito wpf
è cambiato tutto.
xaml a spostato i limiti della programmazione oltre l'inimmaginabile.
quindi, per il discorso grafica nemmeno a discuterne.
per il capitolo della produttività aziendale si potrebbe discutere a
lungo. secondo me dipende da cosa devi fare. comunque sia, anche
quando devo usare semplivemente un db access, oramai costruisco i miei
report in xaml.
cosiglio: studiare il wpf a fondo!!


allora il libro che ho posso buttarlo nel cestino, perchè, 
dichiaratamente, è prevenuto. Parla molto male del WPF. D'altro canto, 
la sua credibilitá personale se l'è costruita durante gli anni : in 
lingua tedesca, è un *guru* del Visual Basic. Infatti il suo VB6 del 
1999 fu un bestseller. Ma puo' darsi che ora cominci ad abusarne.
Qualcuno puo' consigliare un ottimo testo sul WPF  ??


WPF Programmer's Reference
qui trovi pure materiale interessante per inziare..
http://www.vb-helper.com/wpf_prog_ref.htm


Ciao
Prova a vedere questo sito, per farti un'idea su WPF:
http://www.wpftutorial.net/Home.html
Roberto

 
http://www.vb-helper.com/wpf_prog_ref.htm
Am 07.06.2011 22:52, schrieb RMX:
 >
 > Prova a vedere questo sito, per farti un'idea su WPF:
 > 
http://www.wpftutorial.net/Home.html
 >
grazie ragazzi !!!

  Parla molto male del WPF.
se hai volgia/tempo potresti dettagliare perchè?


 
Secondo me non dovresti pensare ad una "esclusiva" tra WinForm e WPF. Ma 
conoscere entrambe ed usare lo strumento migliore a seconda del caso. Inutile 
forzarsi ad usare un pezzo di ferro se hai un martello per piantare un 
chiodo :D


Il libro (come dicevo 1333 pagine) è seminato ogni tanto di commenti
del tipo "sia chiaro che comunque il WPF - al momento version 1.0 - è 
quindi come un drappo rosso (nel senso di 'cosa vietata')  per ogni 
sviluppatore che ci tiene alla stabilità". E poi ancora "così come sono 
tante ed eccitanti le nuove funzioni e possibilità di Layout, così tanti 
sono anche i limiti di questo nuovo WPF.
Elenca poi una serie di vantaggi e svantaggi, tra gli svantaggi ad 
esempio dice che "il WPF Designer del VB2008 è inutilizzabile e il 
codice XAML contraddice  importanti principi del WPF. L'unica cosa 
ragionevole da fare è di scrivere il XAML direttamente a mano, e questo 
è un passo indietro che ci porta alla preistoria dell'informatica."
Il libro, come dicevo è un grosso volume (Michael Kofler, Visual Basic 
2008, Addison Wesley, 2008) e la parte WPF me la sono risparmiata 
(finora). Ma ho visto che,  al contrario del 'Visual Basic 6' del 1999, 
l'autore è molto critico verso Microsoft.
E quando un autore che conosci e reputi serio, comincia a scrivere certe 
frasi, fa passare la voglia di andare avanti a leggere i capitoli seguenti.
Tra gli altri svantaggi del WPF menziona la 'troppa complessità'.
Riporto testualmente :
"Il WPF È valido solo in teoria. In pratica le cose seemplici diventano 
più complicate. In  altre parole : i nuovi concetti WPF servono 
solamente per GUI molto complesse, mentre i dialoghi (il pane quotidiano 
degli sviluppatori Windows) sono resi più difficili".
"L'offerta di Toolbox del Windows Form il WPF se la sogna. Cioè offre 
molti nuovi tools ma mancano i paralleli di molti tools del Windows 
Form, alcuni molto importanti :
standard : ColorDialog, FolderBrowserDialog, FontDialog, 
PageSetupDialog, PrintDocument, PrntPreviewDialog
ADO.NET
 : BindingNavigator, DataGridView,
altri: DateTimePicker, ErrorProvider, HelpProvider, ImageList, 
LinkLabel, MonthCalendar, NotifyIcon, PropertyGrid.
Compatibilità limitata con ADO .NET,
Niente PostScript Support"
In sostanza, alla fine sconsiglia di correre a 'lasciare la strada 
vecchia per la nuova' e ad abbandonare i Windows Form per sviluppare in WPF.
Ora, io non so qui in Italia, ma in Germania si tende SEMPRE a snobbare 
qualsiasi novità e a etichettarla by default come 'instabile'.
Il risultato è che le versioni 1.0 di qualsiasi software (parlo di 
sistemi di sviluppo) sono quasi sempre invendute.
Devo ammettere che quel vizio ha contagiato anche me. Io ho tenuto il 
Windows 2000 Professional fino all'estate del 2009. Da allora uso il 
Windows XP. Probabilmente upgraderò a Windows 7 quando sarà arrivato sul 
mercato Windows 8.
Ricordo che il libro è giá vecchio di tre anni. Quindi qualcosa magari è 
cambiata nel frattempo.
Io lo uso come primo 'reference Book' prima di cercare in rete.
Ciao.
John.

 non è assolutamente niente così produttivo come Windows Form".
facciamo una *prima* distinzione importante, che spiega perchè quella 
frase non ha senso dato che mette insieme capre e cavoli: ne Windows 
Forms (da qui in avanti wf) ne WPF servono per "leggere e scrivere dei 
dati su database e produrre rapporti/tabelle". Entrambe sono tecnologie 
per realizzare UI (punto).
*seconda* importante considerazione: wf e WPF sono talmente diversi che 
un confronto è molto difficile, ma dato che producono (almeno agli 
occhi dell'utente finale) la stessa cosa un confronto ha senso tentare 
di farlo.
*terza* nota: la curva di apprendimento di WPF è mostruosamente ripida, 
mostruosamente, e lo è ancora di più se ci si approccia pensando di 
fare le cose come le si facevano con wf.
Ora, hai due approcci all'uso di WPF:
a) usarlo come usi wf, quindi drag&drop a manetta, doppio click per 
generare gli eventi etc... ci fai sicuramente il 90% di quello che fai 
con wf e produci sicuramente il 100% del codice schifoso che produci 
con wf; è produttivo? sicuramente si, una volta capite le differenze 
(poche) in termini di designer non ci sono particolari problemi; il 
problema vero è quel 10% che non puoi fare, perchè non lo puoi fare? 
perchè WPF e wf sono due cose abissalmente diverse, WPF basa tutto sui 
concetti di data-binding, templating e styling, concetti, data binding 
a parte che esiste anche in wf ma che a confronto di quello di WPF è un 
giochetto per poppanti, semplicemente in wf non esistono; quindi 
l'approccio in stile wf non è vincente, anzi è decisamente 
controproducente;
b) usare WPF per quello che è, utilizzando al 100% un pattern di 
presentazione dei dati (anche in wf andrebbe fatto sia chiaro) e in 
questo caso vincente è m-v-vm; cosa cambia? partendo dal presupposto di 
sapere molto bene quello che si sta facendo (quindi confrontiamo capre 
e cavoli conoscendo bene entrambi, altrimenti il confronto è 
falsatissimo)  cambia che la produttività "apparente" precipita, cosa 
intendo per apparente? intendo che se partiamo a T0 e realizziamo 
un'applicazione con wf e la stessa con WPF + m-v-vm, quando siamo a T1 
quella con wf è finita quella con WPF no, probabilmente è a qualcosa 
come il 60/70% dello sviluppo. La differenza fondamentale è che dal un 
lato banalmente hai scritto di più perchè hai in mezzo anche m-v-vm ma 
dall'altro se guardiamo alla vera produttività, guardiamo cioè al ciclo 
di vita dell'applicazione, appena inziamo la manutenzione con wf 
probabilmente inizia il bagno di sangue perchè lo spaghetti-code regna 
mentre sovrano con WPF vivi felice.
Perchè?
WPF + mv-v-vm mi impone una netta separazione della mera UI dalla 
logica di business che controlla quella UI consentendoci di: cambiare, 
a parità di logica, la UI cono costi bassissimi; testare la logica di 
business senza fare F5 (che ha un costo spaventoso); implementare tutta 
una serie di cose che in wf (ad esempio UI Composition) o non si 
possono fare o hanno un costo astronomico.
Un altro vantaggio è che, una volta compreso come funziona, con WPF 
abbatti la necessità di controlli di terze parti (quindi costi) e la 
necessità di "ereditarietà" dei controlli per customizzare il 
comportamento in base al caso d'uso (anche qui costi);
Infine sempre a vantaggio di WPF hai che il motore di templating (il 
famoso concetto dei lookless control) rende quasi del tutto inutile la 
realizzazione di custom control (io in 4 anni di WPF ne ho scritto 1 
per un caso veramente di nicchia, mentre in wf ne ho una paccata); ti 
faccio qualche esempio:
* customizzare come appare il "ListViewItem" di una ListView:
 - wf: metti a OwnerDraw la ListView e piangi in cinese a suon di 
OnPaint...;
 - WPF: con il designer (in questo caso Blend) oppure a mano via xaml, 
definisci il layout grafico che il ListViewItem deve avere e vivi 
felice, pochi minuti;
un esempio è: il cliente vuole una ListView come quella di Outlook, 
quindi dove ogni elemento presenta più righe di informazione con stili 
particolari in base all'informazione presentata e al contesto, con il 
supporto per lo stretching e cazzi e mazzi :-) in wf io cambierei 
lavoro o comprerei un controllo di terze parti con tutti i rischi che 
comporta, in WPF ci metti 10 minuti secchi;
* realizzare "comportamenti" visuali che sono trasversali ai controlli: 
ad esempio realizzare una sorta di componente che ti permetta di 
mettere ovunque ti serva (magari solo su una porzione di UI) una 
pannello in overlay che faccià da "busy panel" per le operazioni 
asincrone "bloccanti", nel mio caso il cliente voleva (per un 
gestionale non per chi sa che cosa): che il pannello in overlay fosse 
semitrasparente, e che la progress bar visualizzata fosse circolare 
(per l'esattezza una corona circolare) a spicchi...
 - wf: ho pianto in cinese e dopo circa 10 giorni di lavoro (e infinite 
litigate con le mie nozioni di trigonometria) ho realizzato qualcosa 
che soddisfasse il requisito, ma purtroppo era legato a filo doppio al 
progetto per il cliente, lasciamo stare le prestazioni;
- WPF: 1 giornata e mezza e ho realizzato un custom behavior totalmente 
slegato dal progetto in oggetto, con tanto di supporto per i template e 
con prestazioni pari a tutto il resto: una figata pazzesca; in wf gli 
extender provider sono i bisnonni dei behavior di WPF ma sono anche 
lontani anni luce nelle possibilità che offrono;
si aprono poi tutta una serie di possibilità che non necessariamente 
possiamo sfruttare da soli ma spesso anche da soli sono un vantaggio in 
termini di produttività: possiamo nettamente separare la fase di design 
della UI dalla fase di "programmazione" della logica, possiamo 
addirittura farlo fare a figure diverse (come nel caso dell'azienda 
dove lavoro io) o farlo sempre noi, cosa che accade normalmente) in 
tempi/momenti diversi con strumenti diversi, ognuno adeguato al caso;
Il motore di data-binding è semplicemente potenza pura e ti permette di 
fare cose che in wf non avresti nemmeno potuto pensare, padroneggiarlo 
non è facile ma ne vale la pena;
Non hai GDI, quindi non c'è rendering delle bitmap, ma tutto è DirectX 
based e vettoriale quindi scala alla grande in base alla risoluzione, 
ecco perchè WPF è device independant;
A parità di hw le prestazioni sono sicuramente a favore di WPF, del 
resto non hai GDI in mezzo ai "maroni" che cuba un sacco di CPU, ma è 
la GPU che si occupa di fare il lavoro di rendering delle surface. Ho 
realizzato un gestionale per librerire in WPF installato su hw che 
definire preistorico è un complimento (XP SP3, PIII, 256Mb Ram, Virge 
8Mb o simili) e l'applicazione va che è un piacere (naturalmente niente 
effetti speciali, ma non è lo scenario in cui avrebbe senso averli) la 
stessa applicazione in versione wf era un chiodo e siccome le "form" 
sono cariche di controlli il primo effetto schifoso che c'era in wf era 
che vedevi chiarmente la form che si disegnava e c'erano volte in cui 
la macchina "finiva" gli handle GDI...un delirio insomma.
Ovvio che se ci spostiamo in un mondo dove hanno senso gli effetti 
speciali, magari anche della banali transizioni, WPF vince a mani 
basse.
Purtroppo WPF non è solo vantaggi, ad oggi vedo due ordini di problemi:
- i designer (quindi gli ambienti visuali) non sono ancora al passo con 
quelli di wf, ci sono molto vicini (VS2010 ha un designer con i 
contro-cazzi e Blend lo completa) ma ci sono ancora molte cose che 
conviene, non sei obbligato, ma conviene fare a mano;
- fare alcune cose, magari un po' di nicchia, è veramente complesso, 
soprattuto quando entri nel mondo del rendering dei controlli e ad 
esempio hai bisogno di scrivere codice che 
intervenga/reagisca/partecipi al processo di rendering in primis perchè 
ti scontri con il fatto che il processo di rendering è parzialmente 
asincrono e multi-threading complicando di molto il gioco;
A questo punto potrebbero sorgere un po' di domande del tipo: si 
possono realizzare applicazioni complesse? Visual Studio 2010, Blend, 
AutoCad, se non ricordo male Nero, la OVI Suite di Nokia, tutti i tool 
di amministrazione di Dell sono solo alcuni esempi ma ce ne sono a 
bizzeffe ormai. Visual Studio in primis è la dimostrazione che si 
possono realizzare applicazioni mostruosamente complesse in WPF mixando 
3 tecnologie abissalmente diverse: WPF, Windows Forms e COM. E' un 
casino? ovviamente si, pensa solo al fatto che hai 3 message pump 
diverse che hai 3 gestori del focus e che hai diversi motori di 
rendering che di certo non vanno d'accordo... mal di testa :-P ma si 
può fare dimostrando che è pensabile migrare a blocchi un'applicazione 
enorme.
Ma quindi perchè ad esempio Office non è ancora WPF? a me la risposta 
che è stata data è che prima di cominciare a migrare 14 milioni di 
righe di codice ci si pensa bene, molto bene :-) sarà in WPF prima o 
poi? credo di si, ma sono supposizioni mie, ad oggi è già un piccolo 
mix di alcune cose in alcune parti.
Cosa fare se vuoi migrare a WPF? studia, studia, studia, studia, 
studia, studia, studia, studia, studia, studia e poi studia :-) ma 
dimentica anche tutto quello che sai di wf. Insomma suda e fai fatica 
ma ne vale la pena secondo me (io non tornerei indietro neanche dipinto 
sui muri). Considera infine che se conosci WPF sviluppare per 
Silverlight o per Windows Phone è un passaggio pressoché indolore, il 
che schifo proprio non fa.



Ottime argomentazioni. Le userò per per raccomandare il wpf quando mi 
chiamano a fare il consultant.
Grazie.
Ciao.
John.

 mix di alcune cose in alcune parti.
E poi come lo porti su Mac? Lanciamo perdere i sistemi *nix, dove 
ovviamente MS non ha alcuna intenzione :-)
-- 
Saluti
VITRIOL

 MS non ha alcuna intenzione :-)
semplicemente non lo "porti" su Mac come non lo porti oggi, sono due 
team completamente diversi già oggi con due prodotti fndamentalmente 
diversi.


 diversi.
Ci credo, però immaginino che moltissime funzioni C++ del core siano 
fondamentalmente identiche su entrambe le piattaforme. Se riscrivi tutta 
le versione Win in .NET è finita, a meno che non vuoi riscrivere solo 
interfaccia e lasciare il core in codice nativo. Sbaglio?
-- 
Saluti
VITRIOL

 John.
ciao e grazie.


 riscrivere solo  interfaccia e lasciare il core in codice nativo. Sbaglio?
Sbagli se nella vision di MS ci fosse una versione del fx per Mac ad 
oggi ci sono il runtime di Silverlight e Mono domani ci potebbe essere 
qualcosa di nuovo che unifica il tutto? probabile...resta il fatto che 
sulle grossissme applicazioni che migrano dal passato il futuro è 
sicuramente "mixed".


 qualcosa di nuovo che unifica il tutto?
La tendenza delle grandi case oggi è quella di portare tutto sul web in 
modo da avere il controllo totale delle applicazioni. Spero che l'idea 
fallisca per il rifiuto degli utenti :-)
Quanto alla completa portabilità è logico che bisogna scendere a qualche 
compromesso, però la possibilità di poter cambiare sistema trovandosi 
davanti la stessa identica applicazione che si conosce è una goduria. 
Software come Firefox o OOo/LibO sono perfettamente identici su ogni 
piattaforma, fatto salve piccole differenze nella UI specifiche del sistema.
Ovvio che questo lo può fare solo chi non ha un diretto interesse a una 
piattaforma particolare. Altrimenti la non portabilità diventa un vanto :-)
-- 
Saluti
VITRIOL

Il Wed, 08 Jun 2011 10:13:05 +0200, Mauro Servienti [MVP] ha scritto:
[cut]
Ti rigranzio per quest post, da incorniciare, e lo dico da sviluppatore
ancorato a WF.
Approfitto della tua competenza per una semplice domanda: Windows Form non
è altro che la trasposizione .NET (managed) dei concetti Win32 dei window
handle, con i quali ho mosso i primi passi agli inizi degli anni 90 (in
realtà era ancora Win16...) con il C e C++, concetti "nativi" con il
sistema operativo stesso.
WPF come si pone nei confronti di ambienti non managed ?
PaF

 WPF come si pone nei confronti di ambienti non managed ?
WPF è, banalizzando, per la parte di renderering e interazione con 
l'utente un mega wrapper di DirectX.


 piattaforma particolare. Altrimenti la non portabilità diventa un vanto :-)
ovvio, anche se io sono convinto che la portabilità sia sempre e solo 
un vanto.
