Orientation Aware Forms?

  • Thread starter Thread starter Peter Hartlén
  • Start date Start date
P

Peter Hartlén

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
 
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
Click to expand...

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
Click to expand...

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
 
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
Click to expand...

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
 
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
Click to expand...


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 said:
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.
Click to expand...

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)
Click to expand...

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.
Click to expand...

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


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
Click to expand...

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



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.


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
Click to expand...

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
 
Sure. The OAC is simply a Control and a Form derives from Control, so
there's no real reason the Form itself couldn't be modified appropriately.
In fact you could take a Form and add the OAC to it and then derive all app
forms from that child instead of just Form.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
 
In fact you could take a Form and add the OAC to it and then derive all
app forms from that child instead of just Form.
Click to expand...

I created a testapp with the code below. But when switching to design mode
of the test form, I get the following message:
"Visual inheritance is currently disabled because the base class references
a device-specific component or contains P/Invoke."

Any suggestions?

// The OAC main control
namespace OACFormLibrary
{
public partial class OAControl : OrientationAwareControl
{
public OAControl()
{
InitializeComponent();
}
}
}

// The form which is fully filled with a OAControl
namespace OACFormLibrary
{
public partial class OAForm : Form
{
public OAForm()
{
InitializeComponent();
}
}
}

// The testform which inherits from the OAForm
namespace OAFormTest
{
public partial class MyOAForm : OACFormLibrary.OAForm
{
public MyOAForm()
{
InitializeComponent();
}
}
}

Regards,

Peter
 
Peter Hartlén said:
I created a testapp with the code below. But when switching to design mode
of the test form, I get the following message:
"Visual inheritance is currently disabled because the base class references
a device-specific component or contains P/Invoke."

Any suggestions?
Click to expand...

Add Microsoft.Practices.Mobile.UI.OrientationAware.PocketPC.asmmeta.dll
file to catalog where your
Microsoft.Practices.Mobile.UI.OrientationAware.Designer.dll,
Microsoft.Practices.Mobile.UI.OrientationAware.dll,
Microsoft.WindowsMobile.Status.dll files are. It's solved my problems.

Directory tree example

soliution
+ libs
+ Microsoft.WindowsMobile.Status.dll
+ Microsoft.Practices.Mobile.UI.OrientationAware.dll
+ Microsoft.Practices.Mobile.UI.OrientationAware.Designer.dll
+ Microsoft.Practices.Mobile.UI.OrientationAware.PocketPC.asmmeta.dll
+ program
+ [program files]
 
Back
Top