Mi rifaccio al post dell'amico Gabriele in merito al modello di programmazione di WPF.
Credo il discorso parta da una chiaccherata con Andrea Boschin in WPC. Le mie elucubrazioni su WPF partono in un post di Agosto al termine di un progetto reale, successive chiaccherate con Corrado ed infine i miei recenti post con Miguel De Icaza e Rob Relyea il quale ha ammesso la farraginosità di WPF pur sostenendo che l'intenzione è di limare tutto per le prossime versioni.
Quanto voglio sottolineare è che WPF mi piace ma non si può negare la sua poca immediatezza e la farraginosità del modello.
L'ultimo esempio è di oggi, quando ho cercato di ottenere la stringa equivalente ad un carattere dentro il KeyDown. La stringa cambia a seconda del caps lock, shift, gli altri modifiers o magari del numlock e così via. Convertire quindi la Key nella vera stringa che verrebbe mandata ad una TextBox è tutt'altro che banale e purtroppo WPF non espone nulla che permetta una semplice conversione.
La soluzione di questo problema l'ho trovata a fatica facendo l'hook dei tasti con TextCompositionManager.AddPreviewTextInputHandler.
Esempi di questo tipo ce ne sono a bizzeffe in WPF ma questo non significa che non sia certamente il migliore modello di UI che oggi abbiamo a disposizione. Le cose ci sono ma trovarle costa caro.
La morale è che il programmatore VB6 (e non lo dico in senso spregiativo) farà tanta fatica perché non risolverà a botte di intellisense e non potrà esimersi dallo studiare a fondo il modello prima di scrivere una sola riga di codice. E ribadisco che anche con la versione finale di Cider dubito che si potrà scrivere WPF senza conoscere XAML.
WPF, piaccia o meno, non è immediato e questa è la realtà da affrontare a colpi di articoli, libri e tanto esercizio.