AutoScale compilation mode and external libraries

[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 .

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]

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]

Originally Posted by 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.

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.

Originally Posted by agraham

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.

Originally Posted by agraham

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.