AutoScale compilation mode and external libraries

[Woinowski]

Hi,

it might be that I'm slightly to critical in this matter, but all in all the magic of AutoScale is to intransparent for adressing all programming issues.

W.r.t to Erel's question, which kind of application, see the first file in the attachment (Tracker). Problem with that one is that the NumUpDown controls o the Editform do not have the same font size. That makes it awkward to use with only your fingers (target device: HTC Touch HD). please make all Control's font size user definable, to circumvent this.

Besides, I tried a workaround (second upload): A screen width of 160 in the hope that Scale factors will be 3 instead of 2. Which is not the case.

So, for a really good AutoScale feature I would wish:

Think "User Screen Size vs. native Screen" Size (not "320x240/QVGA vs. 640x480") - if Win Mobile/.net can handle that, of course.

Fuzzy fonts are really not acceptable for serious programs. If one does not want this, B4PPC needs native screen resolution. Which means, again: All control properties with effect on screen size/font size must be user definable (again: is this possible with .net)?

Best regards

[agraham]

Originally Posted by Woinowski

Fuzzy fonts are really not acceptable for serious programs. If one does not want this, B4PPC needs native screen resolution.

Fonts are only fuzzy if drawn as graphics with DrawString when AutoScaled. Fonts in controls should be OK. I have a solution ready for native mode graphics when AutoScaled. Preliminary help here but subject to radical change as I keep rewriting it make it easier to understand. http://www.basic4ppc.com/forum/beta-...html#post24927

[Erel]

You should not use DrawString with AutoScale. That is the reason that the Label control was updated to support transparency. So if possible you should use a label instead of drawstring.
If you must use DrawString then you shouldn't use AutoScale.

The native NumUpDown control doesn't support changing fonts.