Topics: Mobile Client Software Factory
Jun 15, 2006 at 2:39 AM
originally posted by: ThePeterNET

I now adpated the DynamicResolutionControl size on change to the panel size which is Dock filled. Works.

(I downloaded the bits during MEDC2006 Europe (Thanks to Mr. Hall and Mr. Tan). I'm trying to follow the simple example in the MobileOrientationAware_Block.pdf doc under "Creating a New Orientation Aware Control View". Everything looks quite good ... until i change orientation. All Elements are "hopping" to the defined and expected position, but the size and position nailed to in the design view of the DynamicResolutionControl does not. Hm? Any hints beside use the MobileCABHelloWorld example as base. Because there it works.)
Jun 15, 2006 at 7:50 AM
originally posted by: dcazzulino

Is that happening when you embed your OAC (it has been renamed to Orientation Aware Control) into a parent control or form?
If that is the case, yes, there are some issues with applying resources to embedded OACs at design-time. At runtime everything will work just fine.

It's quite tricky to get them at designtime when the control is embedded in another one, as VS will actually instantiate the control as if it were at run-time. I tried very hard to get this experience right at design-time, but it's being very difficult... We'll try to get it fixed by RTM, for sure.
Jun 27, 2006 at 11:46 PM
originally posted by: eekvang


I have experienced a variant of this problem when trying to follow the "Creating a new Orientation Aware Control View" from the documentation on the Orientation Aware Control Block.

I posted a message about this case yesterday under the thread "cannot run samples". My problem is that the designer view is no longer available when I change from UserControl to OrientationAwareControl. The suggestions I got involved rebuilding the solution and closing/re-opening visual studio to make the designer appear again, neither of the proposted suggestions worked.

Before changing the UserControl to OrientationAwareControl I opened the designer view in visual studio, then view code, then changed to OrientationAwareControl. As long as I do not close the designer view, it is available in VS. From here I can rotate and adjust the control as suggested in the tutorial. Still it is not possible to view the designer by right-clicking the present file in the solution explorer. Since the controller seems to work ok in the designer view, I tried deploying it both onto an emulator and a real device. In both situations it works fine while in portrait view. If I change the orientation to landscape, something very strange happens. Even though I followed the instructions and set the size to 320x188 on the control, the width of the control is automatically set to the same width as in portrait view, but the label is correctly centered and the textbox looks as it is correct. Since the control is smaller than it should, two vertical white stripes appear at both sides, with the control in the center.
Jun 28, 2006 at 7:13 AM
originally posted by: dcazzulino

I'd say you have to first get the designer issue fixed.
Try to recompile the entire OAC solution. Then close VS and open a new one for your application.
Are you using a project reference to the OAC or an assembly reference? You should use the latter.

Let me know.

Jun 28, 2006 at 9:48 PM
originally posted by: eekvang

Thanks for your tip, unfortunately it did not help me.

I recompiled the OAC solution and made sure that the dll's in the PublicAssemblies directory were up to date. In VS I then created an entirely new solution to test the OAC. As a reference I use the assembly: Micrsoft.Practices.Mobile.UI.OrientationAware.dll from the PublicAssemblies directory, and I placed "using Microsoft.Practices.Mobile.UI;" at the top of my controller file.

But again when I have changed from UserControl to OrientationAwareControl it is no longer possible to view the designer.
My Control is named OCAController.cs, if I click the + symbol on the left side of the name in the solution explorer the following files are listed below it:

- OCAController.Designer.cs
- OCAController.Resources
- OCAController.resx
Jun 29, 2006 at 7:10 AM
originally posted by: dcazzulino

I'd say you should start fresh. Starting with the latest drop, the OAC no longer goes to PublicAssemblies, and you can add a reference right from the Add Reference | .NET tab, without browsing to it.

Try deleting every OrientationAware.dll assemblies you find under \Visual Studio 8 prog. files folder. Then go recompile the OAC solution, and finally open your solution, add a reference to the assembly and try again. The OAC project should NOT be on your solution. You should use an assembly reference.

Let me know if it works.
Jun 29, 2006 at 9:12 PM
originally posted by: eekvang

The drop that I have downloaded (Community Drop 12 Feature Freeze) still copies the OrientationAware.dll to the PublicAssemblies directory, and it is not available from the Add Reference | .NET tab, I have to browse for it.
From what I can see from the download page on this site, the drop I have downloaded is the most recent one.

As you probably understand from this, my problem is not solved yet.
Jun 29, 2006 at 9:19 PM
originally posted by: dcazzulino

Ups! My apologies for that!
Ok, so it looks like the previous issue we had in that area. Can you check if the OAC has the following attribute applied?:


If that is the case, remove it and recompile.

Let me know how it goes.
Jun 29, 2006 at 10:12 PM
originally posted by: eekvang

Thank you for your time.

I found and removed DesignerCategory("Code") from within OrientationAwareControl.cs of the OAC solution, rebuilt the solution again. The solution still copies the dll's to the PublicAssemblies folder, and is not available from the Add reference | .Net tab.

I added the assembly file Microsoft.Practices.Mobile.UI.OrientationAware.dll manually by browsing to it. Then I tried changing from UserControl to OrientationAwareControl to see if the removal of DesignerCategory("Code") made any difference. It did. The View Designer option when right-clicking in the solution explorer is now available, unfortunately none of the properties of the OrientationAwareControl is available. For example when I right-click on the control in the designer, the context menu should display four new options (rotate, switch to default layout, copy text properties, pase text properties) but it does not.
Jun 30, 2006 at 7:25 AM
originally posted by: dcazzulino

Cool. Yes, in that version, I was still copying to public assemblies and it doesn't show up in Add References. In the next drop it will.

Have you recompiled the solution and re-opened VS? Do you see the Orientation property and the disabled Localizable property?
Jun 30, 2006 at 10:30 PM
originally posted by: eekvang

I recompiled the solution and restarted VS, but I cannot see the Orientation property or the disabled Localizable property.
Jul 1, 2006 at 5:48 AM
originally posted by: dcazzulino

Then it looks like the designer assembly was not located.
Make sure that the OAC assemblies exist in PublicAssemblies. Also, the following file should exist too:

C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE\DesignerMetadata\Microsoft.Practices.Mobile.UI.OrientationAware.PocketPC.asmmeta.dll

In the new upcoming version, the location of the files will be:

C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE\Microsoft.Practices.Mobile.UI.OrientationAware.dll

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\Microsoft.Practices.Mobile.UI.OrientationAware.Designer.dll

C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE\DesignerMetadata\Microsoft.Practices.Mobile.UI.OrientationAware.PocketPC.asmmeta.dll

You could try that new deployment too and see if it works for you.
Jul 3, 2006 at 10:28 PM
originally posted by: eekvang

Thank you, the application MobileCABHelloWorld seems to work now.
It turned out that the file Microsoft.Practices.Mobile.UI.OrientationAware.PocketPC.asmmeta.dll was not in its correct place, therefore I put in the folder you suggested. I also added to the implementation of OAC the attribute DesignerCategory"Component" and reinstalled it.

After restarting VS and rebuilding my copy of MobileCABHelloWorld, the OAC seems to work in its intended way.

Thank you for your help
Jul 5, 2006 at 9:37 PM
originally posted by: eekvang

Is it possible to define custom resolutions, or is it limited by vga, qvga and square?
Jul 6, 2006 at 12:47 PM
originally posted by: dcazzulino

Take a look at the following post: http://clariusconsulting.net/blogs/kzu/archive/2006/07/05/ZeroCodeAdaptiveUIs.aspx
Jul 7, 2006 at 9:37 PM
originally posted by: eekvang

We have a question about inheritance and Orientation Aware Control Block.

In our sample application we have created a MasterControl.

class MasterControl : OrientationAwareControl

When rotating the MasterControl we can adjust the appearance such that it looks appropriate when using the landscape mode.

Then we created a new control that inherits from the MasterControl.

class ChildControl : MasterControl

In default layout for the ChildControl the elements in MasterControl are visible and in correct place. But when changing the orientation, the elements are still visible but they maintain the position they had in the portrait mode. A form was then created and the ChildControl was put into it. Then we deployed the application to the emulator to see if the correct behaviour was only in the designer or runtime as well. When rotating the emulator the ChildControl behaves like the MasterControl.

It looks like what happens at designtime in Visual Studio is different from actually running the application. Our question is therefore:

Should ChildControl inherit all the properties set by the MasterControl, including the Orientation Aware properties? Or is it just a coincidence that it works as intended at runtime and not designtime?

Jul 8, 2006 at 6:36 AM
originally posted by: dcazzulino

It's more of a known issue than a coincidence ;).
At run-time everything works as expected.
At deisng-time, VS treats differently the component being designed ("root" componnet) from its base class. Basically, the design-time only features are shown for the "root" component, whereas the base class is instanciated and executed as if it were at run-time. This means that the base control is instanciated and rendered as if it were running, under the default layout and culture. I could not find a workaround so far that would tell VS to run it under an alternative layout and culture. Will keep trying, however.

If I cannot fix the feature, would you rather have the base control not render at all?