AutoScale compilation mode and external libraries

[Erel]

The new version includes an important new compilation mode: AutoScale.
Some explanation about this mode:
When the program starts it checks the device's screen dpi.
It saves these two values in two variables: screenX and screenY.
QVGA screens will return 1 for screenX and screenY.
VGA screens will return 2 for screenX and screenY.
Other values are also possible.
There are another two relevant variables: fixX and fixY.
In the regular compilation mode these variables are constants and equal 1.
In AutoScale compilation these variables are equal to screenX/Y variables.

When a control is created its location and size values will be multiplied with these values.
For example:
Button1.Width = 70 will be translated to Button1.Width = 70 * fixX.
Button1.Left = 20 will be translated to Button1.Height = 20 * fixY.

So the result is that the QVGA layout will appear identical on high resolution screens as well.

External controls libraries should also deal with the different dpis.
Simple solution (this is how ControlsEx.dll deals with it):
Mark your library by adding:

C#: public static object B4P_AutoScale = null;
VB .Net: Public Shared B4P_AutoScale As Object

Now all parameters that are named (case insensitive) width, height, left or top will automatically be converted as required.

For more complex libraries that need to deal with the different values you can access these 4 values with:

double scaleX = (double)(Thread.GetData(Thread.GetNamedDataSlot("scaleX")));
double scaleY = (double)(Thread.GetData(Thread.GetNamedDataSlot("scaleY")));
double fixX = (double)(Thread.GetData(Thread.GetNamedDataSlot("fixX")));
double fixY = (double)(Thread.GetData(Thread.GetNamedDataSlot("fixY")));

For example the TreeView controls has this code in the constructor which sets the default size of the images to look the same on VGA and QVGA:

double scaleX = (double)(Thread.GetData(Thread.GetNamedDataSlot("scaleX")));
double scaleY = (double)(Thread.GetData(Thread.GetNamedDataSlot("scaleY")));
il.ImageSize = new Size((int)(il.ImageSize.Width * scaleX), (int)(il.ImageSize.Height * scaleY));

Note that the boolean value cPPC can also be fetched in the same way.

 

[agraham]

I've started to look at this for my ControlsExDevice library and after being somewhat confused by the behaviour established the following.

When a library object has the field B4P_AutoScale defined then the compiler applies a fix to values in certain program statements as follows.

1) Values for parameters named Left, Top, Height & Width in library object constructors are fixed.

2) Values for assignment to properties named Left, Top, Height &, Width are fixed.

3) Values read back from properties named Left, Top, Height & Width are fixed.

Are there any other properties or type of statements that are fixed or are these the only circumstances where the fix is applied?

 

[manu]

Hi Erel

Does the compilation works well with "WVGA" 480 x 800?

Best Regards

 

[manu]

Hi Erel

One suggestion. Basic4ppc to work with different screen sizes The application may perform the calculation of the values of screenx and screeny as follows:

screenx = form1.width/240
screenY = form1.Height/320


-google traductor-

 

[klaus]

I can confirm that AutoSize compilation works also for 480*800 sceens with following restriction:
- ScreenScale = 2 for both sizes 480*640 and 480*800

Then it depends on what you want to do:
- do you want to stretch vertically the controls, in that case ScreenScale should be equal to 2.5 ?
- do you want to make profit of the supplementary surface of the screen ?

At the moment I am programming for my htc Touch HD and set the screen height in the FormDesigner to 400, this works well.

Best regards.

 

[manu]

Hi Klaus

exactly what I want is to optimize the display 800.

Best regards.

 

[klaus]

Hi manu,

To program for the 480*800 screen size you have 2 options.

In the FormDesigner:

- set the screen size to 240*400 and compile with AutoSize
advantage: the screen on the desktop looks similar to what you will se on the PPC
disadvantage: the images in controls are stretched

- set the screen size to 480*800 and compile with Device Exe
advantage: you take full advantage of the screen resolution and pixel size
disadvatage: on the desktop the screen looks somewhat different than on the PPC, the size is big but the font size in controls remains small.

If, in the program, you draw onto the device you take advatage of the screen resolution in both cases.

Both options work.

Best regards.

 

[manu]

thanks Klaus.

 

[Erel]

I've started to look at this for my ControlsExDevice library and after being somewhat confused by the behaviour established the following.

When a library object has the field B4P_AutoScale defined then the compiler applies a fix to values in certain program statements as follows.

1) Values for parameters named Left, Top, Height & Width in library object constructors are fixed.

2) Values for assignment to properties named Left, Top, Height &, Width are fixed.

3) Values read back from properties named Left, Top, Height & Width are fixed.

Are there any other properties or type of statements that are fixed or are these the only circumstances where the fix is applied?

These are the exact places that B4P_AutoScale fixes.
In all other cases you will need to use FixX/Y and ScaleX/Y.

 

[agraham]

:sign0060: I got HTMLPanel working with AutoScale and because it relies heavily entirely on pixel level working if I can get that working I can get anything working!

However as the Basic4ppc Form drawing functions are AutoScale aware how much should ImageLib and ImageLibEx also be made AutoScale aware? I note that ImageLib is partially aware in that the Drawer.Refresh methods use fixX/Y but none of the other Drawer methods or other ImageLib objects do. This seems a bit odd as if a Rectangle, say, is drawn under AutoScale on a VGA device and Refresh called on the same Rectangle it will invalidate an area four times that required! To use ImageLib as it presently stands a program, even when AutoScaled, needs to compensate for ScreenScaleX/Y itself when drawing so why not also Refresh

 

[Erel]

This code is taken from the optimized compiled form's code (CEnhancedForm.cs) :

bitmap = new Bitmap((int)(ClientSize.Width / b4p.fixX), (int)(ClientSize.Height / b4p.fixY));

As you can see from it, the bitmap which is the drawing layer of the form is smaller than the complete form.
When the bitmap is painted on the form it is stretched to the form's size.
So all the drawings which are done on this bitmap shouldn't be scaled.
Refresh methods are scaled as these methods affect the form and not the bitmap.

 

[agraham]

I'm afraid that's not what I meant. I looked at what Form.cs does and that was why I said "Basic4ppc Form drawing functions are AutoScale aware". It's ImageLib I'm referring to which is not AutoScale aware apart from Refresh, which is odd as I pointed out.

 

[Erel]

Try the attached program.

 

[agraham]

Sorry, I'm not making myself very clear . Forget about my references to Refresh, I forgot that in ImageLib it only works on Forms and Refresh isn't really relevant to what I am trying to say. What I was really thinking about is using ImageLib to draw on a Bitmap associated with, say an Image Control in an AutoScaled app running on a VGA screen. The Image Control size will be AutoScaled, however a Bitmap (which doesn't AutoScale)created with New2(ImgCtl.Width, ImgCtl.Height) will no longer to match it and anything drawn on the Bitmap using ImageLib Drawer methods is also not rescaled. However with further investigation I see that you have fiddled the Image Paint method to do the same expansion as Form.Paint does. I hadn't thought of that and so now I've answered my own question anyway! You've obviously put a lot of thought into this :icon_clap:.

On a different topic I've noticed that Listview checkboxes and possibly Treeview (I haven't tried it) checkboxes and expansion plus signs are very small on a VGA screen and I can't immediately see a mechanism to enlarge them. Any ideas?

EDIT:- Found the checkbox sizing thingy! It servos to ImageListSize - that's intuitive (not!).

 

[Erel]

You've obviously put a lot of thought into this

.

Thanks.

EDIT:- Found the checkbox sizing thingy! It servos to ImageListSize - that's intuitive (not!).

Agreed. Took me some time to figure this.

 

[Woinowski]

Font Scaling is a real issue for me

Hi,

I tried to do something using the native resolution of a HTC Touch HD (480x800 portrait). See enclosed zip for a quick and dirty example.

Problem: In native resolution the device dpi is not known to the Desktop IDE. This works especially quirky with NumUpDown and Calendar Control, but also for ComboBox.

So, what would be required for me are the following fixes:

1. A Desktop Designer option to chose a target resolution, so that desktop design corresponds to the device w.r.t. to (relative) font sizes and control sizes (heights).

2. The possibility to set font/sizes and/or Control heights in all controls.

Best regards.
Jens

 

[Erel]

Try to set the screen size (on the desktop) to 240x400 and compile with AutoScale.

 

[agraham]

Your Screen03 looks wrong. The form looks too large. If you want AutoScaling to work then you need to layout on a form sized 240 x 400 in the IDE and it will then look OK when compiled AutoScaled on your 480 x 800 device.

You can see that in Screen02, native mode, your controls are over halfway across the screen, that is why some are off screen when AutoScaling doubles their co-ordinates and sizes.

I agree that font size is a problem if you want to layout in the IDE at the native resolution of your device. This is because fonts are specified in points which is an actual dimension on the screen whereas everything else is specified in pixels. So fonts are drawn the same size whatever the dpi of the screen whereas everything else scales. If you double the font size in the controls while laying out a native app in the IDE you will get a reasonable idea of what things will look like. You could also lay out a form in a project in the device VGA IDE and then bring it back to the desktop to add the code.

2. The possibility to set font/sizes and/or Control heights in all controls

I don't understand this I'm afraid. Which controls don't already allow this?

 

[Woinowski]

Workarounds...

Your Screen03 looks wrong. The form looks too large. If you want AutoScaling to work then you need to layout on a form sized 240 x 400 in the IDE and it will then look OK when compiled AutoScaled on your 480 x 800 device.

Actually, i DON'T want to use AutoScale but to develop for the true native 480x800. Which is not well supported by the Desktop IDE. Using 240x400 and AutoScale is a workaround but not a solution.

I agree that font size is a problem if you want to layout in the IDE at the native resolution of your device. This is because fonts are specified in points which is an actual dimension on the screen whereas everything else is specified in pixels. So fonts are drawn the same size whatever the dpi of the screen whereas everything else scales. If you double the font size in the controls while laying out a native app in the IDE you will get a reasonable idea of what things will look like. You could also lay out a form in a project in the device VGA IDE and then bring it back to the desktop to add the code.

Again, working on the device is a workaround, albeit a valid one.

I don't understand this I'm afraid. Which controls don't already allow this?

The said NupUpDown and Calendar controls for example. Maybe others, to. And NupUpDown does not allow to set your own font size. And Trees do not allow to set a font size, too.

 

[Erel]

I'm not sure what type of application you are building but in most cases AutoScale should give similar results to using the true native resolution.
Anyway the UI should not be too small or too cluttered.
Auto scaled forms also use significantly less memory which can be important if you have many forms.