Hi!

In the same way as a form is language aware, will it be (or is it already in
wm6?) orientation aware? It should be possible to set up different layouts
in design mode with regards to the resolution and orientation of the screen.

This functionality already exists in the "Mobile Client Software Factory",
and it's OrientationAwareControl, but I was hoping this functionality will
be implemented in the standard form as well...

Any thoughts on that?

Regards,

Peter

On Nov 1, 10:53 am, "Peter Hartlén" <pe...@data.se> wrote:
> Hi!
>
> In the same way as a form is language aware, will it be (or is it alreadyin
> wm6?) orientation aware? It should be possible to set up different layouts
> in design mode with regards to the resolution and orientation of the screen.
>
> This functionality already exists in the "Mobile Client Software Factory",
> and it's OrientationAwareControl, but I was hoping this functionality will
> be implemented in the standard form as well...
>
> Any thoughts on that?
>
> Regards,
>
> Peter

You can already achieve most of this by using the Anchor and the Dock
properties of the controls you place on a form. In addition, you may
need to handle the Resize event for certain controls as well.

- Jin

> You can already achieve most of this by using the Anchor and the Dock
> properties of the controls you place on a form. In addition, you may
> need to handle the Resize event for certain controls as well.
>
> - Jin

Yes, _most_ of it... what if you want to move controls, and change font size
when changing from 320x240 to 640x480?

Isn't there any interest in getting a orientation/resolution aware form into
the framework?

/ P

On Nov 2, 8:25 am, "Peter Hartlén" <pe...@data.se> wrote:
> > You can already achieve most of this by using the Anchor and the Dock
> > properties of the controls you place on a form. In addition, you may
> > need to handle the Resize event for certain controls as well.
>
> > - Jin
>
> Yes, _most_ of it... what if you want to move controls, and change font size
> when changing from 320x240 to 640x480?
>
> Isn't there any interest in getting a orientation/resolution aware form into
> the framework?
>
> / P

Being resolution-aware is something different altogether. Migrating
an existing QVGA (320 x 240) application to VGA (640 x 480) is rather
difficult for several reasons. First of all, the default behavior is
"pixel-doubling," which sort of ensures that your old application will
still look ok on the higher-resolution screen. The downside is that
some of the controls do not render very well with the different font
sizes that come into play. I haven't experimented too much with the
VGA mode, so I can't point you in the right direction.

Having said all that, I'm with you in that Microsoft should better
cater to different form-factors being used in the mobile world. A
better support for higher-resolution device would be welcomed.

- Jin

On Nov 2, 6:25 am, "Peter Hartlén" <pe...@data.se> wrote:
> > You can already achieve most of this by using the Anchor and the Dock
> > properties of the controls you place on a form. In addition, you may
> > need to handle the Resize event for certain controls as well.
>
> > - Jin
>
> Yes, _most_ of it... what if you want to move controls, and change font size
> when changing from 320x240 to 640x480?
>
> Isn't there any interest in getting a orientation/resolution aware form into
> the framework?
>
> / P


Going from 320x240 to 640x480 is just a scaling matter. Why would you
move items around the screen? Auto scaling would handle the size
changes.

As for rotation, changing from 320x240 to 240x320 is a slightly
different story but it can be handled with proper docking and
anchoring as Jin stated. The larger issue regarding rotation of the
screen is that if you need to completely reorganize your layout then
you did not design your screen very well. Even in landscape it's a
very small screen and people should not be trying to force too much
into the UI. Mobile device developers should be designing and
developing with device characteristics, limitations and expectations
in mind instead of using bloated factories and framework as crutches
to get around they bad design decisions. (I'm sure that last comment
is going to get me some hate mail)

Jarod

"Jarod" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Going from 320x240 to 640x480 is just a scaling matter. Why would you
> move items around the screen? Auto scaling would handle the size
> changes.

Not neccessarily, a 640x480 screen could hold more controls than a 320x240.
I've tried the Orientation Aware Control (OAC) from MS Mobile Software
Factory. There you create your control layout for different resolution and
orientations by changing the form factor and rotating, giving you a number
of different layouts, much like you do when localizing your normal form and
changing it's language. The downside is that you have to put a extra control
ontop of your form, something I find quite unnecessary.

> As for rotation, changing from 320x240 to 240x320 is a slightly
> different story but it can be handled with proper docking and
> anchoring as Jin stated. The larger issue regarding rotation of the
> screen is that if you need to completely reorganize your layout then
> you did not design your screen very well. Even in landscape it's a
> very small screen and people should not be trying to force too much
> into the UI. Mobile device developers should be designing and
> developing with device characteristics, limitations and expectations
> in mind instead of using bloated factories and framework as crutches
> to get around they bad design decisions. (I'm sure that last comment
> is going to get me some hate mail)

I come from C and C++, when there still wasn't much graphical design tools
out there. You made all your designing from dynamic code instead, which
meant you had full control of the layout. Now we have much better support
for designing your GUI, but there are limitations, and when you hit such
limitations you either have to go back to managing the GUI dynamically or a
mix of the two.

I only wonder if the features of the OAC will be implemented into a standard
form in the future. Are there any limitations to why it couldn't?

/ Peter

> Having said all that, I'm with you in that Microsoft should better
> cater to different form-factors being used in the mobile world. A
> better support for higher-resolution device would be welcomed.

This is what the Orientation Aware Control helps you achieve. Ýou make
inherit the form layout from a standard layout, but you can create custom
layouts for each form factor. What I want is to integrate this functionality
into the form itself.

/ Peter

On Nov 4, 12:08 pm, "Peter Hartlén" <pe...@data.se> wrote:
> "Jarod" <jarod_la...@yahoo.com> wrote in message
>
> news:(E-Mail Removed)...
>
> > Going from 320x240 to 640x480 is just a scaling matter. Why would you
> > move items around the screen? Auto scaling would handle the size
> > changes.
>
> Not neccessarily, a 640x480 screen could hold more controls than a 320x240.
> I've tried the Orientation Aware Control (OAC) from MS Mobile Software
> Factory. There you create your control layout for different resolution and
> orientations by changing the form factor and rotating, giving you a number
> of different layouts, much like you do when localizing your normal form and
> changing it's language. The downside is that you have to put a extra control
> ontop of your form, something I find quite unnecessary.
>
> > As for rotation, changing from 320x240 to 240x320 is a slightly
> > different story but it can be handled with proper docking and
> > anchoring as Jin stated. The larger issue regarding rotation of the
> > screen is that if you need to completely reorganize your layout then
> > you did not design your screen very well. Even in landscape it's a
> > very small screen and people should not be trying to force too much
> > into the UI. Mobile device developers should be designing and
> > developing with device characteristics, limitations and expectations
> > in mind instead of using bloated factories and framework as crutches
> > to get around they bad design decisions. (I'm sure that last comment
> > is going to get me some hate mail)
>
> I come from C and C++, when there still wasn't much graphical design tools
> out there. You made all your designing from dynamic code instead, which
> meant you had full control of the layout. Now we have much better support
> for designing your GUI, but there are limitations, and when you hit such
> limitations you either have to go back to managing the GUI dynamically ora
> mix of the two.
>
> I only wonder if the features of the OAC will be implemented into a standard
> form in the future. Are there any limitations to why it couldn't?
>
> / Peter

VGA devices only allow more on the screen if the devices truly support
the VGA resolution without scaling, but this is not the case. Devices
like the imate jasjar do not represent a true VGA screen because they
scale things up to twice the QVGA size to maintain the item size ratio
with the physical screen size. Otherwise things like fonts would be 1
quarter of the size they are on a QVGA device. Therefore, what fits on
the QVGA screen adapts to fit the VGA screen for the scaled up fonts,
effectively making the layout of items look the same on the VGA screen
as it did on the QVGA screen. This would be a different story if you
were talking about VGA screens that are actually physically 4 times
larger the QVGA screens, but that's not the scenario here since
devices keep their VGA screens to roughly the same physical dimensions
as a QVGA screen.

Jarod

You're incorrect. VGA devices are true 640x480 resolution, period. They can
be told to pixel-double an application to help it look right, but if you
don't have that on, your app *will* be 1/4 size. You can put more on a Form
though since the display isn't physically bigger, the items have to be
physically smaller to do that.

The general "benefit" of VGA for these devices is that you have twice as
many pixels in the same physical space, allowing for smoother and more crisp
display of graphics.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com



"Jarod" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Nov 4, 12:08 pm, "Peter Hartlén" <pe...@data.se> wrote:
> "Jarod" <jarod_la...@yahoo.com> wrote in message
>
> news:(E-Mail Removed)...
>
> > Going from 320x240 to 640x480 is just a scaling matter. Why would you
> > move items around the screen? Auto scaling would handle the size
> > changes.
>
> Not neccessarily, a 640x480 screen could hold more controls than a
> 320x240.
> I've tried the Orientation Aware Control (OAC) from MS Mobile Software
> Factory. There you create your control layout for different resolution and
> orientations by changing the form factor and rotating, giving you a number
> of different layouts, much like you do when localizing your normal form
> and
> changing it's language. The downside is that you have to put a extra
> control
> ontop of your form, something I find quite unnecessary.
>
> > As for rotation, changing from 320x240 to 240x320 is a slightly
> > different story but it can be handled with proper docking and
> > anchoring as Jin stated. The larger issue regarding rotation of the
> > screen is that if you need to completely reorganize your layout then
> > you did not design your screen very well. Even in landscape it's a
> > very small screen and people should not be trying to force too much
> > into the UI. Mobile device developers should be designing and
> > developing with device characteristics, limitations and expectations
> > in mind instead of using bloated factories and framework as crutches
> > to get around they bad design decisions. (I'm sure that last comment
> > is going to get me some hate mail)
>
> I come from C and C++, when there still wasn't much graphical design tools
> out there. You made all your designing from dynamic code instead, which
> meant you had full control of the layout. Now we have much better support
> for designing your GUI, but there are limitations, and when you hit such
> limitations you either have to go back to managing the GUI dynamically or
> a
> mix of the two.
>
> I only wonder if the features of the OAC will be implemented into a
> standard
> form in the future. Are there any limitations to why it couldn't?
>
> / Peter

VGA devices only allow more on the screen if the devices truly support
the VGA resolution without scaling, but this is not the case. Devices
like the imate jasjar do not represent a true VGA screen because they
scale things up to twice the QVGA size to maintain the item size ratio
with the physical screen size. Otherwise things like fonts would be 1
quarter of the size they are on a QVGA device. Therefore, what fits on
the QVGA screen adapts to fit the VGA screen for the scaled up fonts,
effectively making the layout of items look the same on the VGA screen
as it did on the QVGA screen. This would be a different story if you
were talking about VGA screens that are actually physically 4 times
larger the QVGA screens, but that's not the scenario here since
devices keep their VGA screens to roughly the same physical dimensions
as a QVGA screen.

Jarod

Well some screens are physically bigger, and as you have a higher resolution
it's possible to decrease the size of the controls hence fitting more
controls to your screen.

But if we go back to the original question, Chris, you usually have deeper
insight into what will come (or what can't come). Do you believe such a form
enhancement is achievable, i.e. will it appear in a CF form in the near
future?

/ Peter


"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
news:%(E-Mail Removed)...
> You're incorrect. VGA devices are true 640x480 resolution, period. They
> can be told to pixel-double an application to help it look right, but if
> you don't have that on, your app *will* be 1/4 size. You can put more on
> a Form though since the display isn't physically bigger, the items have to
> be physically smaller to do that.
>
> The general "benefit" of VGA for these devices is that you have twice as
> many pixels in the same physical space, allowing for smoother and more
> crisp display of graphics.
>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded community
> http://community.OpenNETCF.com
>
>
>
> "Jarod" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> On Nov 4, 12:08 pm, "Peter Hartlén" <pe...@data.se> wrote:
>> "Jarod" <jarod_la...@yahoo.com> wrote in message
>>
>> news:(E-Mail Removed)...
>>
>> > Going from 320x240 to 640x480 is just a scaling matter. Why would you
>> > move items around the screen? Auto scaling would handle the size
>> > changes.
>>
>> Not neccessarily, a 640x480 screen could hold more controls than a
>> 320x240.
>> I've tried the Orientation Aware Control (OAC) from MS Mobile Software
>> Factory. There you create your control layout for different resolution
>> and
>> orientations by changing the form factor and rotating, giving you a
>> number
>> of different layouts, much like you do when localizing your normal form
>> and
>> changing it's language. The downside is that you have to put a extra
>> control
>> ontop of your form, something I find quite unnecessary.
>>
>> > As for rotation, changing from 320x240 to 240x320 is a slightly
>> > different story but it can be handled with proper docking and
>> > anchoring as Jin stated. The larger issue regarding rotation of the
>> > screen is that if you need to completely reorganize your layout then
>> > you did not design your screen very well. Even in landscape it's a
>> > very small screen and people should not be trying to force too much
>> > into the UI. Mobile device developers should be designing and
>> > developing with device characteristics, limitations and expectations
>> > in mind instead of using bloated factories and framework as crutches
>> > to get around they bad design decisions. (I'm sure that last comment
>> > is going to get me some hate mail)
>>
>> I come from C and C++, when there still wasn't much graphical design
>> tools
>> out there. You made all your designing from dynamic code instead, which
>> meant you had full control of the layout. Now we have much better support
>> for designing your GUI, but there are limitations, and when you hit such
>> limitations you either have to go back to managing the GUI dynamically or
>> a
>> mix of the two.
>>
>> I only wonder if the features of the OAC will be implemented into a
>> standard
>> form in the future. Are there any limitations to why it couldn't?
>>
>> / Peter
>
> VGA devices only allow more on the screen if the devices truly support
> the VGA resolution without scaling, but this is not the case. Devices
> like the imate jasjar do not represent a true VGA screen because they
> scale things up to twice the QVGA size to maintain the item size ratio
> with the physical screen size. Otherwise things like fonts would be 1
> quarter of the size they are on a QVGA device. Therefore, what fits on
> the QVGA screen adapts to fit the VGA screen for the scaled up fonts,
> effectively making the layout of items look the same on the VGA screen
> as it did on the QVGA screen. This would be a different story if you
> were talking about VGA screens that are actually physically 4 times
> larger the QVGA screens, but that's not the scenario here since
> devices keep their VGA screens to roughly the same physical dimensions
> as a QVGA screen.
>
> Jarod
>
>