Newsgroup: it.comp.programmare.win32
Titolo: EditBox: Readonly di soli 3 caratteri di una stringa....

dovrei fare in modo che nella Edit Box dove sia contenuta una stringa alcune
lettere (tre per la precisione) non siano modificabili, mentre le altre
possono esserlo...conoscete un metodo?

 wrote:

beh le prime 3 lettere le metti in una label e gli fai scrivere le
altre nell'edit poi per le tue elaborazioni le unisci....
brutto ma funzionante. :D
--------------------------------------------------
Brayan Fix Kirys Solfory
E-Mail: 
Ki...@technologist.com
 
For Free Software go to: 
http://Kiryssoft.cjb.net


Direi brutto solo dal punto di vista estetico (e forse nemmeno da quello).
Cambiare il comportamento dei controlli standard può portare a complicare 
la vita dell'utente che si aspetta che i vari oggetti funzionino nello 
stesso modo in ogni applicazione.
Se l'utente vede una label non proverà mai a modificarne il valore, se vede 
i dati in un campo di edit inizierà a chiedersi perchè il programma non gli 
lascia modificare quei maledetti tre caratteri!
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)

 possono esserlo...conoscete un metodo?
Gestisci nel tuo contenitore EN_UPDATE e rimetti a posto il testo
se viene "erroneamente" alterato, ad esempio.
Alex

 lascia modificare quei maledetti tre caratteri!
E` normale che un campo di edit sia arricchito di funzioni di validazione:
ad
esempio, che verifichi se il valore che l'utente sta editando e` un valido
numero,
e` una valida data, ecc, ecc.  Questo e` solo un caso particolare in cui i
valori validi per il campo iniziano tutti con XYZ.  No problem.
Problema separato e` quello di UI, di fornire all'utente un buon feedback se
e quando gli si impedisce di effettuare un cambiamento non-valido.  Un breve
e modesto segnale acustico (facoltativamente disabilitabile), un campo di
status ove appare il messaggio (meglio dirlo in positivo: "Il valore del
campo
PIPPO deve sempre iniziare coi caratteri XYZ"), indizi cromatici, indizi
sinergici (impedire al caret di entrare nella zona non-davvero-editabile),
e via sciorinando le mille mirabilie che gli ergonomisti inventano ad ogni
pie` sospinto.
Ma il controllo-di-edit-infurbito-per-essere-validante non e` idea da
rigettare!
Alex


Non sono a priori contro i controlli di edit infurbitovalidanti, ma credo 
che in questo caso se ne possa tranquillamente fare a meno.
La reazione dell'utente tipo al messaggio che riporti sarà un: "stupida 
macchina! Se devo sempre inserire XYZ non potresti sobbarcarti tu questo 
lavoro stupido e ripetitivo e lasciare a me solo la parte che richiede 
capacita umane!" (ovviamente con livelli di torpiloquio e accento regionale 
differenziati). Altro caso è quello di un campo di edit che valida dati più 
complessi (codice fiscale, numero di carta di credito, codici 
complessi...).
Spesso poi questi meccanismi di validazione tendono a "incepparsi" se si 
cancellano dei caratteri, se si fa del taglia-incolla, se si passa ad un 
altro campo senza completare l'inserimento (magari perchè è balzato 
all'occhio un errore in un altro campo non validato... ecc..) aggravando il 
livello di frustrazione.
Un tipico esempio di interfaccia frustrante che mi viene in mente è 
l'editor di VB. 
Per mia (forse deviante) abitudine, mi muovo spesso tra le righe senza 
completare quello che stò scrivendo, magari per aggiungere la dichiarazione 
di una variabile che mi serve proprio nell'istruzione che stò scrivendo, 
per dichiarare un parametro in più nella funzione che stò utilizzando, per 
cercare come diavolo si chiama quel datamember a cui avevo dato un nome 
chiaro e intuitivo.... 
Nell'editor di VC++ (quello che utilizzo per il 95% del tempo) o in un 
qualsiasi editor di testo (altro 4,99999% del tempo) questo non comporta 
nessun problema... in VB vengo continuamente massacrato da message box che 
rivendicano supposti errori di sintassi causati dal mancato completamento 
della riga su cui stò lavorando (oltre a quelli dovuti all'abitudine di 
terminare le righe con un ; :)).
Oltre al feedback (molto importante) è anche da considerare il fatto che 
continui messaggi di avvertimento (soprattutto se inutili o, peggio, 
tendenti a incolpare sempre l'utente dei problemi, come tu giustamente hai 
sottolineato) genera un senso di frustrazione nell'utente e, di 
conseguenza, anche repulsione verso il programma "tiranno".
Diminuire la quantità di informazioni che l'utente è costretto a ricordarsi 
(ad esempio il fatto che il codice deve iniziare con "XYZ") e lasciare 
queste informazioni in vista all'interno dell'ambiente di lavoro riduce di 
molto i tempi di apprendimento e aumenta la facilità d'uso delle 
applicazioni (soprattutto quelle che non prevedono un utilizzo intenso e 
quotidiano).
Giusto per cercare di "sdebitarmi" per gli ottimi libri che consigli, ti 
invito a dare un'occhiata a "The Design of Everyday Things" di Donald 
Norman. Tratta di design in generale (non strettamente orientato al 
sofware), ma riporta parecchi spunti che possono essere interessanti per 
chi deve sviluppare UI.


 chi deve sviluppare UI.
E` un ottimo testo.  Norman ne ha poi scritti altri, meno eccellenti in
generale ma spesso piu` mirati al nostro campo.
Alex


Però per capire che i caratteri non sono modificabili l'utente ci deve 
"litigare" almeno una volta, mentre dovrebbe essere chiaro a chiunque abbia 
un minimo di pratica nell'uso del PC che i caratteri di una label non sono 
modificabili.
Per fare un esempio sul genere, mi pare di ricordare che il setup di 
windows '95 OSR2 presenti la stinga OEM (che è fissa all'interno del codice 
prodotto) come label, dividendo il resto del codice su più edit (con la 
stessa struttura visiva che il codice stesso ha sulla custodia del CD di 
installazione).
Il discorso cambia se lo stesso problema si presenta per parecchi campi di 
input (nel caso di un applicazione di data-entry, per esempio), in questo 
caso l'utente dovrebbe imparare a distinguere quelle particolari tipologie 
di campi, ma, in compenso, avrebbe a disposizione un'interfaccia utente più 
"compatta" visivamente e quindi più comoda da utilizzare (meno schermate, 
dialog meno "incasinate" dal punto di vista visivo...).


generale ma spesso piu` mirati al nostro campo.
Beh nessuno si scarica? :D
Ciao
Kirys


 Beh nessuno si scarica? :D
Non credo, comunque da' un occhio ai motori di ricerca.
Alex

questo linguaggio, mediamente.
Non per sapere se si possono fare ma come.
In alcuni linguaggi si usano certi metodi in altri altri
ad esempio usa un linguaggio visuale tipo visualbasic o delphi allora
gli divevo nell'evento eccc. fai questo ecc..
Mica volevo fare polemica :D
Non avevo molto tempo per fare una cosa generale :D


 gli divevo nell'evento eccc. fai questo ecc..
Con le API si fa praticamente tutto da qualsiasi linguaggio,
volendo.  Visual Basic e Delphi incluse.  Certo, non vale
la pena se il linguaggio ti offre gia` un modo piu` semplice,
ma quello, certamente, dipende dal linguaggio (e non solo:
anche dal framework che usi, e/o dai controlli che usi, se
il linguaggio permette di usarne diversi intercambiabili).
Alex

 wrote:

per quello non mi ci sono buttato se io gli davo na sfilza di righe di
api poi nel suo ambiente di sviluppo si fa con 2  :D
Ciao
PS in vb5 ad esempio non tutte le api sono possibili
questo melo ricordo bene. Mi sembra non si possa ad esempio sublassare
oggetti. :D
