Despite all the good resources and previous posts, I admit to having some
confusion over Dpi Aware applications in the Compact Framework.

This is what I've learned so far:

1. "Normally" a Compact Framework application will look just fine, because
all the standard controls get resized automatically.
2. But custom controls, images especially, may benefit from taking advantage
3. You use res2exe -c -r hidpi.res to mark your binary as aware.

Here's my questions:

1. Is there any way to include that resource in your project instead of
using res2exe? I ask just because it is an annoyance. to run this from the
command line outside the project. Plus I don't know how I will *ever* be
able to debug it in high dpi mode, because the debugger will copy over the
unrezzed exe file.
2. Can I get the best of both worlds by allowing standard controls to resize
automatically but doing some work on my custom controls?
a). In this case, can I detect I am in a highres environment?
b). In this case, will the user still get the warning that my program is
an inferior product for an old OS (paraphrasing)?
3. Do I have to support rotation if I support high dpi?

The alternative, writing four sizing routines, is a bit overkill. I realize
this is what may be required. It will require some more time, and the
designer will cease to work, so it seems better to be done as late as
possible, at a time when one is darn sure the UI is stable and the human
factors people have no more advice to give.

Something tells me I can't be the only person who would want to leave most
standard controls to the default, yet modify some custom ones for the high
dpi. Any others have experience here?

Thanks for any advice.

Nathan

1) Unfortunately, for CFv1 there is no way to do it other than res2exe. The
good news is that I have a VS.NET macro which will run it for you from
within the IDE and then launch the debugger. See here:
http://blogs.msdn.com/windowsmobile/...03/107203.aspx

2) No - pixel-doubling can only be enabled on a per-process basis.

3) It's been a while but IIRC, if you mark your app as resolution aware but
not orientation aware we will still throw up the automatic scroll bars for
you. You'll need to modify the hidpi.res file to only specify resolution
awareness.


With CFv2, all apps will automatically be marked as resolution/orientation
aware and the docking/anchoring/rotation features in the designer will make
it super easy to implement basic resolution/orientation awareness.


--
Robert Levy
Program Manager
Mobile Devices Product Group
http://blogs.msdn.com/windowsmobile

This posting is provided "AS IS" with no warranties, and confers no
rights.

Nathan Mellor wrote:
> Despite all the good resources and previous posts, I admit to having
> some confusion over Dpi Aware applications in the Compact Framework.
>
> This is what I've learned so far:
>
> 1. "Normally" a Compact Framework application will look just fine,
> because all the standard controls get resized automatically.
> 2. But custom controls, images especially, may benefit from taking
> advantage
> 3. You use res2exe -c -r hidpi.res to mark your binary as aware.
>
> Here's my questions:
>
> 1. Is there any way to include that resource in your project instead
> of using res2exe? I ask just because it is an annoyance. to run this
> from the command line outside the project. Plus I don't know how I
> will *ever* be able to debug it in high dpi mode, because the
> debugger will copy over the unrezzed exe file.
> 2. Can I get the best of both worlds by allowing standard controls to
> resize automatically but doing some work on my custom controls?
> a). In this case, can I detect I am in a highres environment?
> b). In this case, will the user still get the warning that my
> program is an inferior product for an old OS (paraphrasing)?
> 3. Do I have to support rotation if I support high dpi?
>
> The alternative, writing four sizing routines, is a bit overkill. I
> realize this is what may be required. It will require some more time,
> and the designer will cease to work, so it seems better to be done as
> late as possible, at a time when one is darn sure the UI is stable
> and the human factors people have no more advice to give.
>
> Something tells me I can't be the only person who would want to leave
> most standard controls to the default, yet modify some custom ones
> for the high dpi. Any others have experience here?
>
> Thanks for any advice.
>
> Nathan

"Robert Levy [MS]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 1) Unfortunately, for CFv1 there is no way to do it other than res2exe.
The
> good news is that I have a VS.NET macro which will run it for you from
> within the IDE and then launch the debugger. See here:
> http://blogs.msdn.com/windowsmobile/...03/107203.aspx
>

This sounds great - but I couldn't get it to run yet. I'm not a macro ide
guru, but I suspect I may have to set up the project in a particular way. It
gets a Nullreference exception when trying to run it in the macros explorer.

I'd like to do it for normal deploy steps as well - didn't there used to be
post-build or pre-deploy steps in VS projects.

> 2) No - pixel-doubling can only be enabled on a per-process basis.
;( Ok. Any device capabilities, registry flags, etc that a "non dpi-aware"
appplication could use to detect a hires device. OK, this is is a bit
tricky, but so is cutting and pasting layout code.

> 3) It's been a while but IIRC, if you mark your app as resolution aware
but
> not orientation aware we will still throw up the automatic scroll bars for
> you. You'll need to modify the hidpi.res file to only specify resolution
> awareness.

Ok. Is the highdpi.res used to specify orientation awareness? I thought
there was something in the .inf file for that. Of course that could be for

And if I specify hires but not orientation aware, will you tell the user
that my app was designed for a previous OS?

> With CFv2, all apps will automatically be marked as resolution/orientation
> aware and the docking/anchoring/rotation features in the designer will
make
> it super easy to implement basic resolution/orientation awareness.
>

So what will CF2 run on and when? I assume you will need VS 2005 and it will
run on Pocket PC 2005 and above. I haven't heard much about CF2, so I have
assumed it is farther in the future, not appropriate for a product released
in a few months.

Nathan

..NETCF 2.0 will ship with Visual Studio 2005 during 2005. It will run on
Pocket PC 2003 and higher and all future generation Windows Mobile devices.
A list of new features is available here:-
http://msdn2.microsoft.com/library/w8xd02k7.aspx

Peter

--
Peter Foot
Windows Embedded MVP
www.inthehand.com | www.opennetcf.org

"Nathan Mellor" <nmNOSPAMXX$$@hp.com> wrote in message
news:(E-Mail Removed)...
>
> "Robert Levy [MS]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 1) Unfortunately, for CFv1 there is no way to do it other than res2exe.
> The
>> good news is that I have a VS.NET macro which will run it for you from
>> within the IDE and then launch the debugger. See here:
>> http://blogs.msdn.com/windowsmobile/...03/107203.aspx
>>
>
> This sounds great - but I couldn't get it to run yet. I'm not a macro ide
> guru, but I suspect I may have to set up the project in a particular way.
> It
> gets a Nullreference exception when trying to run it in the macros
> explorer.
>
> I'd like to do it for normal deploy steps as well - didn't there used to
> be
> post-build or pre-deploy steps in VS projects.
>
>> 2) No - pixel-doubling can only be enabled on a per-process basis.
> ;( Ok. Any device capabilities, registry flags, etc that a "non dpi-aware"
> appplication could use to detect a hires device. OK, this is is a bit
> tricky, but so is cutting and pasting layout code.
>
>> 3) It's been a while but IIRC, if you mark your app as resolution aware
> but
>> not orientation aware we will still throw up the automatic scroll bars
>> for
>> you. You'll need to modify the hidpi.res file to only specify resolution
>> awareness.
>
> Ok. Is the highdpi.res used to specify orientation awareness? I thought
> there was something in the .inf file for that. Of course that could be for
>
> And if I specify hires but not orientation aware, will you tell the user
> that my app was designed for a previous OS?
>
>> With CFv2, all apps will automatically be marked as
>> resolution/orientation
>> aware and the docking/anchoring/rotation features in the designer will
> make
>> it super easy to implement basic resolution/orientation awareness.
>>
>
> So what will CF2 run on and when? I assume you will need VS 2005 and it
> will
> run on Pocket PC 2005 and above. I haven't heard much about CF2, so I have
> assumed it is farther in the future, not appropriate for a product
> released
> in a few months.
>
> Nathan
>
>

inline below

--
Robert Levy
Program Manager
Mobile Devices Product Group
http://blogs.msdn.com/windowsmobile

This posting is provided "AS IS" with no warranties, and confers no
rights.

Nathan Mellor wrote:
> "Robert Levy [MS]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 1) Unfortunately, for CFv1 there is no way to do it other than
>> res2exe. The good news is that I have a VS.NET macro which will run
>> it for you from within the IDE and then launch the debugger. See
>> here:
>> http://blogs.msdn.com/windowsmobile/...03/107203.aspx
>>
>
> This sounds great - but I couldn't get it to run yet. I'm not a macro
> ide guru, but I suspect I may have to set up the project in a
> particular way. It gets a Nullreference exception when trying to run
> it in the macros explorer.
>
> I'd like to do it for normal deploy steps as well - didn't there used
> to be post-build or pre-deploy steps in VS projects.

Do you know which line the exception is occuring on?

Unfortunately, pre- and post-build steps are avaiable for non-device
projects. VS2005 will add that support for devices.

>> 2) No - pixel-doubling can only be enabled on a per-process basis.
> ;( Ok. Any device capabilities, registry flags, etc that a "non
> dpi-aware" appplication could use to detect a hires device. OK, this
> is is a bit tricky, but so is cutting and pasting layout code.

Not that I know of... but even if there was, I don't think it solve your
problem since the non-aware app would still only be able to draw to a
320x240 pixel-doubled screen

>> 3) It's been a while but IIRC, if you mark your app as resolution
>> aware but not orientation aware we will still throw up the automatic
>> scroll bars for you. You'll need to modify the hidpi.res file to
>> only specify resolution awareness.
>
> Ok. Is the highdpi.res used to specify orientation awareness? I
> thought there was something in the .inf file for that. Of course that
> could be for

The flags in the inf file are only used to pop up the warning message during
installation

The native resource linked into the executable (via res2exe for managed
apps) is what tells the OS whether to turn off the legacy mode features

> And if I specify hires but not orientation aware, will you tell the
> user that my app was designed for a previous OS?

The flags in the executable (to turn off legacy mode features) are
independent from flags in the inf (to turn off the warning)

>> With CFv2, all apps will automatically be marked as
>> resolution/orientation aware and the docking/anchoring/rotation
>> features in the designer will make it super easy to implement basic
>> resolution/orientation awareness.
>>
>
> So what will CF2 run on and when? I assume you will need VS 2005 and
> it will run on Pocket PC 2005 and above. I haven't heard much about
> CF2, so I have assumed it is farther in the future, not appropriate
> for a product released in a few months.
>
> Nathan

Peter is correct - CFv2 is included in the VS 2005 beta and supports Pocket
PC 2003 and later. Depending on the timeline for your project, you may want
to go with this since orientation/resolution awareness are much much easier
to do with docking/anchoring support and a rotatable designer.

"Robert Levy [MS]" <(E-Mail Removed)> wrote in message
news:OcNV%(E-Mail Removed)...
>
> Do you know which line the exception is occuring on?
>

Nope - it won't tell me that. But I found that it did run from a keyboard
shortcut if my cursor was in an editor.

However, when it runs to completion my application is not displaying in
highres. If it does not run to completion, (if I cancel or put some bad
print statement in there), it will never stop. Clicking the spinning candy
icon doesn't stop it. Developer Studio is left in a bad state and I have to
reboot the machine. I have little experience with macros so this might be
par for the course.

> > ;( Ok. Any device capabilities, registry flags, etc that a "non
> > dpi-aware" appplication could use to detect a hires device. OK, this
> > is is a bit tricky, but so is cutting and pasting layout code.
>
> Not that I know of... but even if there was, I don't think it solve your
> problem since the non-aware app would still only be able to draw to a
> 320x240 pixel-doubled screen

Okay, maybe not. I can't find it now, but I thought I saw something that
implied that Graphics.DrawImage would use all of the pixels in the source
image. There is a point in my application where I draw to the screen and I
believe that this is happening. However, as soon as I refresh from my
OffScreenBitmap, it looks pixelated. I could at least adjust the size of the
buffer. But if what you say is true, this is unlikely to work.

> The flags in the inf file are only used to pop up the warning message
during
> installation
>
> The flags in the executable (to turn off legacy mode features) are
> independent from flags in the inf (to turn off the warning)
>

Ok. What flags do I put in the .inf If I am not orientation aware but wish
to turn off the warning? I couldn't find that anywhere. VersionMax doesn't
seem to do anything and BuildMax seems to specify orientation awareness.

>
> Peter is correct - CFv2 is included in the VS 2005 beta and supports
Pocket
> PC 2003 and later. Depending on the timeline for your project, you may
want
> to go with this since orientation/resolution awareness are much much
easier
> to do with docking/anchoring support and a rotatable designer.

It's certainly a possibility, since the work required for enhanced
functionality in 2003SE has delayed it by at least, say, a week. If it
delays much further, I may have to decide whether I have any Pocket PC
2000-2002 customers that I like. ;?

Nathan