.NET Forum / .NET Framework / Compact Framework / November 2007
Orientation Aware Forms?
|
|
Thread rating:  |
Peter Hartlén - 01 Nov 2007 16:53 GMT 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
Jin Chang - 01 Nov 2007 18:15 GMT On Nov 1, 10:53 am, "Peter Hartl?n" <pe...@data.se> wrote:
> Hi! > [quoted text clipped - 11 lines] > > 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
Peter Hartlén - 02 Nov 2007 14:25 GMT > 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
Jin Chang - 03 Nov 2007 05:33 GMT 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 [quoted text clipped - 9 lines] > > / 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
Peter Hartlén - 04 Nov 2007 22:09 GMT > 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
Jarod - 03 Nov 2007 23:21 GMT 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 [quoted text clipped - 9 lines] > > / 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
Peter Hartlén - 04 Nov 2007 20:08 GMT > 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 [quoted text clipped - 7 lines] > 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
Jarod - 05 Nov 2007 10:08 GMT On Nov 4, 12:08 pm, "Peter Hartl?n" <pe...@data.se> wrote:
> > Going from 320x240 to 640x480 is just a scaling matter. Why would you > > move items around the screen? Auto scaling would handle the size [quoted text clipped - 31 lines] > > / 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
<ctacke/> - 05 Nov 2007 12:59 GMT 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.
 Signature Chris Tacke, Embedded MVP OpenNETCF Consulting Giving back to the embedded community http://community.OpenNETCF.com
On Nov 4, 12:08 pm, "Peter Hartlén" <pe...@data.se> wrote:
> "Jarod" <jarod_la...@yahoo.com> wrote in message > [quoted text clipped - 40 lines] > > / 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
Peter Hartlén - 05 Nov 2007 21:09 GMT 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
> 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 [quoted text clipped - 70 lines] > > Jarod <ctacke/> - 05 Nov 2007 23:57 GMT 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.
 Signature Chris Tacke, Embedded MVP OpenNETCF Consulting Giving back to the embedded community http://community.OpenNETCF.com
> Well some screens are physically bigger, and as you have a higher > resolution it's possible to decrease the size of the controls hence [quoted text clipped - 82 lines] >> >> Jarod Peter Hartlén - 07 Nov 2007 20:21 GMT > 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. 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
<ctacke/> - 08 Nov 2007 00:10 GMT It rings a bell as something you have to do some config to avoid. I don't recall offhand, but Google should find it.
 Signature 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. [quoted text clipped - 45 lines] > > Peter Dmitrij Orlov - 29 Nov 2007 13:01 GMT > 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? 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]
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|