Newsgroup: it.comp.lang.visual-basic
Titolo: [Etica] : Risoluzione schermo

DOpo aver mandato il post precedente,
mentre leggevo i vari post sul NG,
mi sono imbattuto in uno che mi ha fatto  venire la seguente domanda.
Dato un programma che dovra' esere distribuito, in che modo
gestire la visualizzazione da schermo a schermo ?
Cioe'....se io faccio un progrmma utilizzando 1024/768, magari un altro
utente
lo utilizzera' in 680*nonsocosa...
Quindi in questo caso, sul mio skermo il programma si vedra' bene,
mentre sul suo, risultera' tagliato o cmq deformato.....giusto?
Ok, detto questo.
mi sovvengono due soluzioni:
1) LUNGO e macchinoso ma piu bello :
Creare codice che legge la risoluzione settata e imposta i propri formini
secondo tale risoluzione.
In questo modo, l'utente non si accorge di nulla...
2) Moooolto piu sbrigativo ma meno "etico" :
Obbligare il pc a cambiare risoluzione per fare in modo che, se il programma
è stato fatto in 1024*768 , la schermata venga fuori in maniera corretta.
ma facendo in questo modo, si potrebbe incorrere anche in un riavvio della
macchina giusto ? (cioe' se l'utente ha settato "Riavvia il sistema dopo
aver cambiato risoluzione" o cqs del genere). mi sbaglio? come si procede in
questo caso ?
Sono le 2 e mezza del mattino...sto quasi svalvolando :)
Cmq la domanda credo che potrebbe aprire un thread...
se non altro...ditemi se sbaglio almeno oppure voi, come fate / fareste nel
mio caso :D

 In questo modo, l'utente non si accorge di nulla...
Io adotto questa soluzione. Da progetto 640x480 (c'è chi ha problemi di
vista), poi, in run-time, amplio tutto proporzionando (con qualche
sbavatura). Non posso imporre di andare a 800x600, tantomeno oltre. A parte
i problemi di vista, ci sono ancora in giro alcuni monitor che non reggono
risoluzioni oltre 800x600.

 ha scritto nel messaggio
news:aqn1jo$cj9$1...@lacerta.tiscalinet.it...


Idem: il programma gira a 1024, se risoluzione minore avviso (se l'utente
non accetta non può usare il programma), cambio risoluzione, al termine la
risetto.
Non è il massimo (se p.e. il programma si inchioda non risetta la
risoluzione) e dipende a chi il programma verrà fornito; se è una società o
comunque NON è un utente anonimo (cioé: se va allegato in una rivista questa
logica non è applicabile) credo sia una soluzione accettabile

Ciao, ho anche io lo stesso pbl, io ho pensato di creare il form alla
risoluzione di 800*600.
Come è stato detto nel thread la soluzione di modificare la risoluzione
video è la + veloce ma anche la meno etica, soprattutto perchè se l'utente
dovesse usare il programma tutti i giorni e + volte al giorno (come nel mio
caso), non sarebbe carino fargli riavviare continuamente il pc.
Nel mio caso specifico ho realizzato una grafica lontana dal classico stile
windows, infatti avevo pensato di creare una schermata di avvio con dei
pulsantoni per accedere alle diverse sezioni.
Questi pulsanti come ho detto prima sono stati realizzati per una
risoluzione minima di 800*600 e hanno come sfondo un'immagine.
Impostando la startup position del form su Center Screen il pbl non si pone,
a meno che non si imposti una risoluzione inferiore a 800*600.
Il pbl sorge invece quando il programma viene caricato con una impostazione
DPI (quella del menu avanzate della risoluzione schermo) diversa da quella
del mio pc, infatti le immagini che facevano da sfondo ai pulsanti rimangono
della stessa grandezza mentre i pulsanti cambiano.
Possibile che non ci sia una soluzione a questo pbl se non quella di
ridimensionare tutti gli oggetti? Io uso flash che ha la bellissima opzione
di adattare gli oggetti alla risoluzione dello schermo e alla grandezza
della finestra, possibile che Vb non abbia questa funzione?
Scusate se mi sono dilungato ma mi sono fatto prendere la mano.
Vi saluto
Ciao

 gestire la visualizzazione da schermo a schermo ?
Riposto una mia soluzione già postata tempo fa.
ciao
Alberto
------------------
Io mi regolo così: se le form sono molto semplici, puoi tranquillamente
sfruttare l'evento resize per ridimensionare i controlli a seconda della
dimensione della form (e quindi rendi dinamica la form anche se non è
massimizzata).
In generale, però, non si tratta di un semplice ridimensionamento. Ad
esempio, a seconda della risoluzione, può essere necessario spostare dei
controlli da una parte all'altra, o disporre le cose in modo completamente
diverso.
Io mi regolo così:
Per le form piccole e semplici (ad esempio i dialog o gli avvisi), le creo
in modo che vadano bene per il 640x480. Per le risoluzioni maggiori verranno
un po' piccole, ma fa lo stesso.
Per le form principali, quelle più complesse, creo la risoluzione dove
voglio l'effetto più bello, e ad esempio la chiamo Form1_1024. Dopodichè
creo copie delle form, con nomi Form1_800, Form1_640, Form1_1200.
Per ognuna di esse, modifico solamente la disposizione e la dimensione dei
controlli, e lascio invariato il codice.
Ovviamente sposto tutte le sub o function in un modulo esterno, riferendomi
ai controlli della form con Form1.Controllo.
Gli eventi non eseguono altro che una chiamata a Sub o Function pubbliche
definite nei moduli esterni.
All'avvio eseguo, in uno splash di benvenuto, la lettura della risoluzione
video corrente, e faccio semplicemente Set Form1=Form1_1024 (o quella che mi
serve). Poi chiamo Form1.Show. In un modulo ho definito Public Form1 as
Form.
Siccome tutti i moduli, function, sub, chiamate fra form, ecc.., fanno
riferimento sempre a Form1, semplicemente facendo puntare Form1 su
Form1_1024, Form1_800, ecc.., cambio tutto senza problemi.
L'unica cosa da ricordare è: se si aggiunge un controllo o un evento in una
form, va riportato in tutte le altre versioni. Il resto del codice resta
identico.
Ciao
Alberto

 controlli, e lascio invariato il codice.
Beh, non ci avevo mai pensato, è un ottimo metodo, anche se un po' lungo :)
ps.:Mi date un occhiata anche al post "slider colorabile?" :DDD

 Beh, non ci avevo mai pensato, è un ottimo metodo, anche se un po' lungo
:)
E' molto più lungo da descrivere che da fare.
Sinceramente avevo anche provato con il ridimensionamento proporzionale
(Lupo), ma mi ero un po' inchiodato, perchè non tutti i controlli vanno
ridimensionati allo stesso modo.
Ad esempio, i controlli picture con i logo, commandbutton con stile grafico,
potrebbero non volere o non gestire lo stretch dell'immagine, per cui a
certe risoluzioni uso il commandbutton grafico, e ad altre lo uso come solo
testo.
Inoltre, con il ridimensionamento proporzionale è molto complesso, per non
dire impossibile, gestire lo spazio libero fra un controllo e l'altro. Tale
spazio, infatti, viene ridimensionato esattamente nella stessa proporzione
dei controlli stessi. Questo potrebbe portare a spazi liberi superiori al
voluto.
Con la mia soluzione, invece, è possibile fare tutte le modifiche estetiche
che si vuole su ciascuna form/risoluzione.
Ci sono in compenso altre sfortune: sicuramente un po' di complessità in più
nel codice, gli eventi Load delle form che scattano tutti all'inizio, ecc...
Ma nel 90% delle mie applicazioni va benissimo così.
Per quanto riguarda l'imposizione di cambiare risoluzione o il cambiarla da
codice, sono due soluzioni che ritengo sbagliatissime, e da utilizzarsi
solamente come estrema risorsa:
- Esistono ancora troppi PC con risoluzione massima molto bassa
- Su molti portatili cambiare risoluzione significa fare la cornicetta nera
- Su sistemi NT l'utente potrebbe non avere il diritto di cambiare
risoluzione
- Negli applicativi che girano in Explorer, modificare la risoluzione è
generalmente inibito
- Alcuni antivirus o impostazioni di Explorer inchiodano l'applicativo
- Mentre uso un applicativo, potrei tranquillamente dover usare un altro
applicativo che, a sua volta, potrebbe richiedere una risoluzione diversa
- Se effettuo il cambio risoluzione con altre finestre già attive, esse
potrebbero non essere aggiornate, col rischio di mandare fuori dal monitor
il bordo e i pulsanti di chiusura, obbligando l'utente a 'uccidere'
l'applicativo col task manager e perdendo i dati (lo stesso Office ha questa
caratteristica).
ciao
Alberto

[OFF Thread] Non hai mai sentito parlare di slider su cui si possa settare
il colore di background? :DD

 ha scritto> Idem: il

numero speciale di focus in edicola, su roma antica: contiene cd rom,
con belle animazioni.
si vede bene, a tutto monitor.
peccato che un alt-tab sul 18", che di suo sarebbe a 1280, mi mostri
le cartelline gialle di gestione risorse grandi mezzo schermo...
e nessuno mi ha chiesto niente...
detto questo, se a qualcuno l'argomento interessa, il  cd rom e'
discreto.
--
ciao, j.
www.sundaysw.com

 caratteristica).
Quoto volutamente anche questo elenco, perchè perfetto. E se anche fosse
perfettibile, direi che queste motivazioni sono più che sufficienti per non
essere "invasivi" sul sistema dell'utente.

 essere "invasivi" sul sistema dell'utente.
gia' e poi come al solito dico la mia da niubbo :
dopo aver creato il programma e fatta una parte del debug comincio a
scervellarmi per il resize , io appllico il metodo ALBE V dalla sua uscita
( ricordo il post tipo 5-6 mesi fa ) ottimizzato per quelle macchine strane
con risoluzioni assurde , in pratica aggiungo un controllo per le
risoluzioni non standard come 960x720 se non ricordo male , in pratica
faccio le 3 form 640 , 800 e 1024 , quando leggo la risoluzione applico la
form presente o quella inferiore se non presente . poi per il resto l'unica
form che riscrivo e' quella da 640x480 , in quanto la 800 la prendo come
"standard" e la 1024 non faccio altro che dare + spazio tra i frame , avevo
provato a gestirlo automaticamente ma mi si sfasava tutto quando si scendeva
sotto i 800 e cmq molte volte evito il "tutto schermo" e lo applico solo nei
MDI dove evito il caricamento dei child a tutto schermo : /

 MDI dove evito il caricamento dei child a tutto schermo : /
Ecco. La domanda sorge spontanea: E se l'utente allarga la finestra, in
altezza e/o in larghezza (o a tutto schermo)? I controlli restano come sono,
mi par d'aver capito, e quella griglia in cui non si vede giusto l'ultima
colonna (o l'ultima riga)? L'utente resterà un po' deluso nel vedere che
quella zona grigia che lui ha creato ... resta grigia.

 massimizzata).
Io ho affrontato il problema del resize scrivendomi una classe che si occupa
di gestire lo spostamento di ciascun oggetto sulla form in base a poche
informazioni salvate nel tag dell'oggetto stesso.
In pratica esistono 2 castiche base e una derivata: centratura e ancoraggio
sono le due casistiche base, e l'allargamento (o restringimento) è derivata
dall'ancoraggio.
In pratica la mia classe si salva la posizione e la dimensione di ciascun
oggetto rispetto alla form alla risoluzione base. Poi durante il resize, in
base alle casistiche sopra descritte, modifica la dimensione/posizione di
ciascun controllo.
In realtà bastano 4 cifre per evidenziare ciascuna casistica. ognuna delle 4
cifre può valere 0 (neutro) 1 (ancoraggio) o 2 (centratura) e le 4 cifre
riguardano nell'ordine Nord-Est-Sud-Ovest.
Ad esempio un valore di 0212 significa che il controllo deve mantenere la
sua distanza dal lato sud del container, mentre deve centrarsi rispetto al
lato est ed ovest. 1111 invece significa che l'oggetto deve stretcharsi
(ovvero ingrandirsi o rimpicciolirsi) in modo da mantenere fissa la distanza
dai 4 lati del container.
Il bello di questo metodo è che permette di gestire in modo quasi automatico
la maggior parte delle form "standard" delle applicazioni. Ci sono problemi
solo in caso di controlli affiancati che devono dividersi in parti uguali lo
spazio della form, ma si tratta di casi davvero rari, e diventa comunque
facile isolare i due controlli in questione non scrivendo nulla nel loro
tag, e gestendone lo spostamento nel normale evento resize della form.
Il caso più normale, ovvero una form con una toolbar allineata in alto e
stirata ai lati, una griglia che occupa buona parte della form, e alcuni
pulsanti allineati in basso a destra, si gestisce così:
Tollbar con tag 1202 - Griglia con tag 2222 - Picturebox con tag 0110 che
contiene i tutti pulsanti che servono.
Ciao
*Roby*

 quella zona grigia che lui ha creato ... resta grigia.
bhe no aspe' , se non carico a tutto schermo e' perche' sono gia'
dimensionate e siccome nell'ultimo anno sto sviluppando prevcalentemente
diversi progetti in mdi a finestre fisse ( si lo so, e' una grezzoneria ma
prima o poi mi vedo quel coso li il set parent .. insomma quella cosa che mi
permette l'include delle finestre ! ) in pratica essendo programmi per le pa
di una semplicita' immensa , se un utente prova a ridimensionare una
finestra ho la sub "Elastic(myForm)"  che mi riposiziona tutto com'era ,
come dire : " io ho detto e scelto che deve stare cosi , se non ti piace, ti
attacchi ^_^ "

 [...] "se non ti piace, ti attacchi ^_^ "
Meno male che il topic parlava di "Etica"...
Prova a metterti per un po' nei panni del tuo utente, e vedrai che dopo aver
avuto a che fare con un po' con l'Elastic ti verranno in mente posti
fantasiosi a cui attaccarti per poi tirare con tutte le tue forze. :-)
Ciao
*Roby*

discreto.
ROTFL

 fantasiosi a cui attaccarti per poi tirare con tutte le tue forze. :-)
gia', mi so accorto che ero di poco OT ^_^
purtroppo i miei utenti so quello che sono
io so quello che sono , la ditta richiede programmi stile :
1 button che fa "solo" questo , le immaginine non ci interessano !

Scusate ma mi ripropongo visto che non ho visto nessun thread in riguardo.
Nel mio caso specifico ho realizzato una grafica lontana dal classico stile
windows, infatti avevo pensato di creare una schermata di avvio con dei
pulsantoni per accedere alle diverse sezioni.
Questi pulsanti come ho detto prima sono stati realizzati per una
risoluzione minima di 800*600 e hanno come sfondo un'immagine.
Il pbl sorge invece quando il programma viene caricato con una impostazione
DPI (quella del menu avanzate della risoluzione schermo) diversa da quella
del mio pc, infatti le immagini che facevano da sfondo ai pulsanti rimangono
della stessa grandezza mentre i pulsanti cambiano.
La domanda è questa, con i metodi da voi elencati (+ precisamente quello di
creare + copie dello stesso form per ogni risoluzione) si risolverebbe il
mio pbl?
Io penso di no.
Vi saluto
Ciao

 della stessa grandezza mentre i pulsanti cambiano.
Perchè cambia la grandezza dei pulsanti?
Il fatto che cambino i DotPerInch non dovrebbe essere significativo se
dentro ai pulsanti hai solo delle immagini e non ci scrivi nulla.
Ad occhio il problema potrebbe dipendere dal fatto che la dimensione del
pulsante viene modificata da codice lavorando in Twips, e la modifica dei
DPI comporta quindi una differente dimensione a video. Se il problema è
questo, lo risolvi lavorando direttamente in pixel e settando a VbPixel la
scala usata dalle tue form.
Se invece il problema è un altro, prova a postare un breve pezzo di codice
che esemplifichi l'inconveniente.
Ciao
*Roby*