Interfacce e comportamento pulsanti

[cdimauro]

• 

Per questo ci sono i binding, come dicevo prima, che mettono a disposizione una enorme flessibilità.

Ti faccio un esempio con XAML (per Silverlight):

Codice: [Seleziona]

<TextBlock Text="{Binding ElementName=MyTimeout, Path=Value, Converter={StaticResource HoursFormatter}}"/>
<Slider Name="MyTimeout" Minimum="1" Maximum="24" SmallChange="1" Value="1"/>Il controllo TextBlock ha "legato" la sua proprietà Text (di tipo stringa) alla proprietà Value (di tipo double) dell'oggetto UI che si chiama MyTimeout (lo slider definito subito dopo).

In questo modo non appena MyTimeout.Value cambia, il nuovo valore viene inviato alla proprietà Text del primo controllo.

La cosa interessante di quest'esempio è che il binding fa uso di un "convertitore". In .NET si tratta di una classe che ha la funzione di effettuare una conversione, appunto, di un valore che gli viene passato (il double dello Slider). Nello specifico, il controllo TextBlock visualizza qualcosa del tipo "1 ore", "2 ore", ..., "24 ore" proprio grazie al converter.

Un'altra cosa utilissima dei binding è che possono essere bidirezionali: se cambia il valore dello Slider, cambia anche quello del TextBlock (o TextBox nel caso in cui si voglia un edit text in cui l'utente immette del testo).

Questo funziona anche con le property di una classe. Esempio:

Codice: [Seleziona]

<Slider Minimum="1" Maximum="24" SmallChange="1" Value="{Binding MiaIstanza, Path=Valore, Mode=TwoWay}"/>Supponendo che MiaIstanza sia l'istanza di una classe che espone la property pubblica Valore, effettuandone il binding bidirezionale con la property Value dello Slider si verificherà, appunto, che qualunque cambiamento alle due property si rifletterà anche sull'altra.

Tornando al problema dei RadioButton, personalmente non complicherei l'implementazione del framework per tenere conto di questi casi che non sono molto diffusi. In questi casi risolvo tutto da codice: piazzo un delegate negli eventi Checked e Unchecked di tutti i controlli RadioButton, e risolvo manualmente i casi di incompatibilità.

[TheKaneB]

• 

Tornando al problema dei RadioButton, personalmente non complicherei l'implementazione del framework per tenere conto di questi casi che non sono molto diffusi. In questi casi risolvo tutto da codice: piazzo un delegate negli eventi Checked e Unchecked di tutti i controlli RadioButton, e risolvo manualmente i casi di incompatibilità.

Yes! anche perchè le regole di controllo di coerenza potrebbero essere note soltanto a runtime (ad esempio a seguito di un'interrogazione ad un DB, oppure in base al verificarsi di specifiche condizioni). Un UI toolkit non dovrebbe consentire eccessivo controllo sulle policies, ma fornire soltanto le meccaniche.

Il Binding tra due proprietà, seppur comodo, viola parzialmente la separazione tra View e Model. Questo può essere accettabile in molti casi, ma offrendo al programmatore un sistema "troppo potente" per costruire una GUI si rischia di invogliare la produzione di spaghetti-code :-)

Per questo motivo non andrei oltre il basilare data-binding.

[cdimauro]

• 

Infatti non a caso Microsoft parla di pattern (o modello) Model View ViewModel, che è diverso dal classico MVC.

Comunque questo tipo di binding avanzato ha indubbi vantaggi, anche se effettivamente lega troppo model e view. Però uno dei vantaggi è che risulta anche semplice testare la GUI, costruendo degli appositi mock. Cosa che non ho potuto sperimentare finora causa cronica mancanza di tempo.

Personalmente ho utilizzato per lo più il databinding nei miei progetti. Con WPF si può fare anche meglio (rispetto a Silverlight) per cercare di evitare legare troppo model e view, perché è possibile definire dei trigger che scattano al verificarsi di determinate condizioni, riducendo molto il "code behind".

[Allanon]

• 

Ok, credo di aver capito il punto...
perciò implementerò una classe dedicata al gruppo di opzioni, ma secondo voi l'implementazione dei Link fra oggetti è adeguata per il successivo supporto del binding con XAML? Se così fosse dovrei solo prevedere il supporto per i convertitori (me ne ero totalmente dimenticato ).

Bello questo forum  :mrgreen:

[cdimauro]

• 

Francamente non ho pensato alla possibile implementazione. So per certo che il binding altro non è che una classe in .NET, ma non so come funzioni tutto il meccanismo.

Dovrei pensarci un po', ma ho bisogno di un po' di tempo: al momento ho parecchie rogne da sistemare.

[Allanon]

• 

Non ci sono problemi, fai con calma tanto prima che arrivo all'implementazione di queste cose devo terminare tutte le classi mancanti perciò ce ne ho di codice da macinare  

[Allanon]

• 

Dopo oltre 4 anni di sviluppo sono quasi pronto per una prima release del mio framework per Hollywood chiamato HGui.
Si tratta di una libreria per creare GUI che non dipendono da nessun sistema ospite ne da librerie esterne quindi funzioneranno e saranno visualizzate su ogni sistema esattamente come sono state progettate dallo sviluppatore.

Mi farebbe piacere, per chi ne avesse voglia e tempo, di dare un'occhiata alla demo che ho rilasciato e che potete scaricare da questo link dropbox:
https://www.dropbox.com/sh/lt2cb5coa9kufzn/AACRYLwl06SSTKqM5QaB0AGta?dl=0

Ci sono tutte le versioni supportate da Hollywood, oltre all'eseguibile che vi interessa dovrete scaricare anche la cartella <HGui_ShowCaseResources> che contiene alcune immagini usate dalla demo. Le versioni MacOS non necessitano di questa cartella perchè è già inclusa nella cartella dell'app.

Se siete curiosi e volete più info qua c'è il thread che ho aperto sul forum di Hollywood -> Click.

Immagini:



Sono graditi feedback e comportamenti anomali 

[TheKaneB]

• 

Ma complimenti!

[Allanon]

• 

Grazie!
E' stata un'avventura a dir poco epica... speriamo non ci siano bachi subdoli, c'è ancora qualcosina da fixare, ma robetta di poco conto 

[schiumacal]

• 

Veramente bravo 

Io avevo gia' a suo tempo scaricato e ordinato per benino le tue Scuilib che ritengo siano molto utili per diverse applicazione sviluppate con Hollywood.

Ora con HGui e' ancora meglio.

Tienimi aggiornato 

[Allanon]

• 

Certo :-)
Continuerò a postare su questo thread 

[paolone]

• 

...però se...

1. Premo il LMB su un pulsante e mantengo premuto -> windows disegna il pulsante premuto
2. Esco dall'area sempre son il LMB premuto -> windows disegna il pulsante normale
3. Lascio il LMB, e poi lo ripremo in un'area non attiva
4. sempre mantenendo il LMB premuto entro sul pulsante del punto 1 -> windows mi disegna il pulsante evidenziato
5. Lascio il LMB -> windows lancia l'evento
A me questo comportamento non sembra proprio corretto, primo percè ho lasciato il LMB fuori dal pulsante e poi perchè mi lancia l'evento su un rilascio del LMB in seguito ad un evento di evidenziazione e non di pressione...

Ditemi voi, forse sono io che prendo un abbaglio ma se devo riprodurre questi comportamenti è bene che sappia precisamente cosa è giusto e cosa no  <!-- s:D --><!-- s:D -->

Sei tu che stai prendendo un abbaglio. Stai semplicemente unendo fra di loro due eventi separati, aspettandoti un comportamento diverso da quello che avevi già descritto in precedenza (nella parte che ho tagliato), dovuto soltanto al fatto che sei uscito e poi rientrato sullo stesso pulsante.

Modifichiamo un secondo il tuo ragionamento, ipotizzando invece che tu abbia selezionato in due tempi, due pulsanti diversi:

1. Premo il LMB su un pulsante A e mantengo premuto -> windows disegna il pulsante A premuto
2. Esco dall'area sempre son il LMB premuto -> windows disegna il pulsante A normale
3. Lascio il LMB, e poi lo ripremo in un'area non attiva
4. sempre mantenendo il LMB premuto entro sul pulsante B -> windows mi disegna il pulsante evidenziato
5. Lascio il LMB -> windows lancia l'evento "B"

Nel tuo caso, semplicemente B == A. Hai fatto due cose diverse, non una sola. Ora, dubito che Windows tenga un registro di tutti gli eventi a cui l'utente ha rinunciato (cliccare, tenere premuto e uscire dall'area del pulsante = rinunciare a premerlo), per tanto l'unica azione effettivamente compiuta nel tuo esempio è quella che hai riportato nei punti 4 e 5.

[paolone]

• 

@Allanon

Intanto ne approfitto anch'io per farti i complimenti. Spero che HGui ti permetta almeno di rientrare nell'investimento di tempo, fatica e stress che sicuramente hai dovuto affrontare per realizzarlo.

[Allanon]

• 

Mi sembra che poi venne fuori che questo comportamento lo avevo solo con PSPad

Cmq grazie per i complimenti, non ho la pretesa di riprenderci il tempo investito ma di recuperarci un paio di aggiornamenti ad Hollywood 

[Allanon]

• 

Ancora ci sto lavorando... la classe ListView è infinita 

Comunque l'ultimo problema che ho risolto riguarda la manipolazione dei valori in visualizzazione: mi spiego meglio.

Supponiamo che ho una tabella con due colonne: nomi file e dimensione file (in bytes) e voglia mostrarla in una ListView.
Tutto ok, nessun problema, però le dimensioni in byte fanno pena e voglio mostrarle in Kb come faccio?

La prima cosa che viene in mente è convertire i dati e passarli alla ListView, quindi ogni dimensione in byte la converto in Kb e aggiungo il suffisso "Kb", il valore da numerico passa inevitabilmente a stringa.

Bene, i dati sono visualizzati ma se premo il pulsante dell'intestazione della colonna per cambiare ordinamento tutto va a farsi fottere perchè adesso sono stringhe e l'ordinamento delle stringhe prevede, per esempio, che "45Kb" venga prima di "4Kb" 

Per risolvere questa zozzeria ho aggiunto la possibilità di definire dei convertitori associati alle colonne delle ListView, ossia delle funzioni che vengono invocate ogni volta che un valore di una determinata colonna deve essere visualizzato. Queste funzioni possono essere cambiate al volo e si prestano anche a dei giochetti carini per evidenziare le colonne o manipolare i dati in visualizzazione.

Quindi, ricapitolando, adesso passo i valori in byte e specifico questa funzione per la colonna delle dimensioni:

Codice: [Seleziona]

function(value) return((value/1024) .. "Kb") endfunction

E tutti vissero felici e contenti

P.S.: tra l'altro in questo modo non ho la necessità di inzozzare i dati originali per visualizzarli.