Newsgroup: it.comp.lang.visual-basic
Titolo: [?] ridimensionamento form in base a caratteri

Ho guardato sul sito comune e ho trovato clsresize ma non credo sia quello
che cerco...
Ho sviluppato una applicazione lavorando a 1024*768 caratteri grandi;
montato su un pc che deve lavorare con caratteri piccoli ed č successo un
macello...
Ho studiato il modulo di classe sul sito comune ma non fa per me; ho provato
ad inserirlo in una delle mie mdi form e (col mio progetto originale e
impostazioni schermo originali) mi ingrandisce tutto (mentre dovrebbe
rimanere uguale)...ma forse questo modulo lavora sui ridimensionamenti di
una form e NON sul cambio di risoluzione.
La domanda č: che calcolo devo fare per fare in modo di adattare il mio
programma al cambio di risoluzione e al cambio di caratteri?
Per la risoluzione non č importante perché se ne occupa il programma di
portare lo schermo a 1024*768 e a riportarlo ai valori originali all'uscita
(so che non č bellissimo ma va bene cosě per ora), ma per i caratteri di
dimensioni diverse?
Ho visto da windows che la risoluzione denominata "caratteri grandi" č di
120 dpi mentre quella di caratteri piccoli + 96 dpi...basterebbe quindi
moltiplicare le dimensioni di ogni controllo per 120/96?
Se sě: come faccio a sapere i dpi attuali?
Grazie a tutti in anticipo, datemi una dritta che mi sta tirando scemo....

Mi rispondo da solo: 120/96 funziona e ridimensiona correttamente...
ma, senza conoscere DPI settati, non mi serve a nulla
Ho provato con enumdisplaysettings ma restituisce di tutto e di più ma NON
questo dato...
Sapete come ottenere questo valore?
Grazie a tutti in anticipo.

 Sapete come ottenere questo valore?
DPI?
Intendi i pixel per inch?
Beh, i pixel ce li hai (risoluzione schermo)
Dovresti guardare l'help di ScaleMode per sapere quanto vale un pollice.
Se non sbaglio un centimetro vale 567 twips... un pollice non ricordo.
Ciao

Non so bene cosa intendo...
pannello di controllo - schermo; impostazioni - avanzate - dimensione
caratteri.
Io ho sviluppato con "caratteri grandi" (sotto scrive "120 dpi"); se lo
setto come "caratteri piccoli" ("96 dpi") mi sballa tutto; ridimensionando i
controlli con il calcolo 120/96 si sistema tutto ma, ovviamente, sapendo che
con 120 DPI la visualizzazione č corretta mi occorre sapere come calcolare
quel 96 per conoscere il moltiplicatore (es. per ogni controllo
.left=cint(.left*120/x)).
Sai come calcolare questo valore?
Grazie

 Se sì: come faccio a sapere i dpi attuali?


Sì, dappertutto trovo come ridimensionare il base a dimensione dello
schermo, ma sembra che nessuno abbia notato che, a parità di risoluzione,
questo settaggio fa la differenza (vedi la risposta che ho dato a Zanna, c'è
scritto come vedere e modificare la dimensione del carattere).
Grazie

 ha scritto

infatti. irafnview, p.e., ha un buchino, per cui l'hscrollbar della
qualita' jpeg a caratteri grandi schizza a destra del bordo form.
col codice qui sotto vedi i tppx/y. 15 e' car piccoli, 12 grandi. non so
se funziona con caratteri settati a mano.
hth, pal
Option Explicit
Private Sub Form_Load()
Dim s As String
With Screen
s = "SW TWIPS: " & .Width & vbCrLf
s = s & "SW PX: " & .Width / .TwipsPerPixelX & vbCrLf
s = s & "SH TWIPS: " & .Height & vbCrLf
s = s & "SH PX: " & .Height / .TwipsPerPixelY & vbCrLf
s = s & "TPPX: " & .TwipsPerPixelY & vbCrLf
s = s & "TPPY: " & .TwipsPerPixelY
End With
MsgBox s
Unload Me
End Sub

mumble, mumble...
120/96=1.25
15/12 = 1.25
Dici quindi che è calcolabile dividendo il valore screen.twipsperpixelX per
12 (costante che indica con quale dimensione ho sviluppato il progetto)...
Fine settimana provo sicuramente, potrebbe essere la soluzione.
Grazie, comunicherò il risultato appena testato.

RISOLTO
Mi hanno suggerito di fare 1440/screen.twipsperpixelX ed effettivamente
ottengo il valore che mi serve.....
La curiosità però resta: che è quel 1440?????

 ha scritto nel messaggio
news:9k925a$e2n$1...@fe1.cs.interbusiness.it...

Il numero di minuti in un giorno? :)
Prova a vedere se può interessare quanto segue.
Ciao
-----------------
Creating Display-Independent Property Pages
A property page is generally developed on a single computer that always uses
the same video adapter with the same resolution and font size. When the
snap-in is distributed to customers it may run on a variety of video
adapters, resolutions, and with small or large fonts. To ensure that a
property page will always appear correctly regardless of video configuration
the following steps should be taken:
  1.. Use the property page's default ScaleMode property value of Twip.
  2.. If developing with small fonts and implementing
IMMCPropertyPage_GetDialogUnitSize, leave some extra space between the
controls and the bottom of the page. This is needed because when the page is
displayed on a computer with large fonts its height will be squeezed
slightly.
  3.. If developing with large fonts and implementing
IMMCPropertyPage_GetDialogUnitSize, leave some extra space between the
controls and the right side of the page. This is needed because when the
page is displayed on a computer with small fonts its width will be squeezed
slightly.
  4.. Always test the page with both small and large fonts.
Twips are used for the ScaleMode property because they are a
device-independent measurement that also has a very fine granularity. The
word twip is a contraction of "twentieth of a point." A point is 1/72 of an
inch so a twip is 1/1440 of an inch. When printing, a point is 1/72 of a
physical inch but on the screen it represents 1/72 of a logical inch. The
physical size of a logical inch is determined by the video configuration and
it is calculated to allow smaller font sizes (for example, 8-point) to
appear in a reasonable size on the screen. If an 8-point font were displayed
on the screen using its physical size it would not be readable. The logical
inch provides the needed magnification and also allows programs to calculate
the size of their windows and controls using a device-independent
measurement.
The MMC guidelines for property page sizes, control sizes, and control
spacing are all given in dialog units. The dialog unit is also a
device-independent measurement that is based on the average height and width
of the characters in the font used in a dialog box. For vertical
measurements, a dialog unit is 1/8 of the height of the characters in the
dialog box's font. For horizontal measurements a dialog unit is 1/4 of the
average width of the characters in the dialog box's font. While dialog units
are not as granular as twips, they are sufficient for the layout of windows
containing text and controls such as property pages.
Visual Basic® does not use the dialog unit measurement, but the designer
does allow a property page to specify its size in dialog units at run time.
If a property page implements the IMMCPropertyPage interface, the designer
runtime will call IMMCPropertyPage_GetDialogUnitSize(Height, Width). If the
property page does not have code in this method then the design-time size
will be used.
To determine the size to use at design time, use the default ScaleMode of
Twip and use the dialog-unit-to-twips calculator that is available from the
context menu on the root node of the designer tree view.
As explained earlier, when moving from small fonts to large fonts, the
height of a page measured in dialog units becomes slightly smaller and the
width becomes slight larger. This may seem counterintuitive, because one
would expect that logical units should keep their proportions. Understanding
how this happens requires some additional explanation. Continue reading only
if you are interested in the theory.
Windows typically uses 96 pixels per logical inch for small fonts and 120
pixels per logical inch for large fonts. This means that a font in a given
point size in small fonts must increase its physical size by 25 percent when
moving to large fonts. Unfortunately, the system cannot always make such
exact changes. For example, on a sample small-fonts system, the MS Sans
Serif 8 font has a height of 13 pixels. When moving to large fonts, by
adding 25 percent the size should change to 16.25 pixels. Video adapters do
not allow addressing the screen in fractions of a pixel so the system rounds
it down to 16 pixels.
Consider what happens to a measurement in dialog units such as MMC's
recommended property page height of 218. A vertical dialog unit is 1/8 of
the font height, so the height of a property page in logical inches on the
sample small-fonts system is calculated as follows:
218 dlus ÷ 8 units/character = 27.25 characters
27.25 characters X 13 pixels/character = 354.25 pixels
354.25 pixels ÷ 96 pixels/logical inch = 3.69 logical inches
If we do the same calculation on a large-fonts system we find that the
property page will actually be shorter in logical inches:
218 dlus ÷ 8 units/character = 27.25 characters
27.25 characters X 16 pixels/character = 440 pixels
440 pixels ÷ 120 pixels/logical inch = 3.66 logical inches
Because the property page size in a Visual Basic snap-in is measured in
twips (1/1440 of a logical inch), the logical inch size will be the same
regardless of the font size. For property pages coded in C++, the logical
inch size will be slightly different on both systems. Using the preceding
example, if there were no rounding errors, then when moving to large fonts,
the 3.69 logical inches would be
3.69 logical inches X 120 pixels/logical inch = 442.8 pixels
Now you can see that a property page specified in twips will be about 3
pixels higher than a property page specified in dialog units when moving to
large fonts. (In practice, due to rounding, the pixel difference may be
slightly higher.) If your property page implements
IMMCPropertyPage_GetDialogUnitSize and it returns 218 for the height, then
on a large-fonts system, it will be created slightly smaller than what was
expected at design time because of the difference in calculations. This
should generally not be a problem, but pages that have controls close to the
bottom may need to be moved up to allow for the decreased height.
A similar problem occurs in the width calculations except that the page
becomes too large when moving to large fonts. On the sample system, the
average width of a character in the MS Sans Serif 8 font is 6 pixels. When
moving to large fonts, adding 25 percent would require 7.5 pixels. The
system rounds this up to 8 pixels. Because the font is too large, the size
of the horizontal dialog unit increases more than it should and the width of
the page increases. Because of this, pages designed on a large-fonts system
should leave some extra room on the right side, because the width of the
page will be squeezed when moving to small fonts.
For more information see IMMCPropertyPage.