OAC control in VGA resolution does not work

Topics: Mobile Client Software Factory
Dec 13, 2006 at 10:47 AM
originally posted by: LarryBB

To start: my oh my, this MCSF thing is hard to use!

After long struggle, I seem to be able to use the Orientation Aware Control in normal resolution modes but not in VGA modes.

I've created a test project with a single form containing a single OAC. The project works for QVGA, for both regular and square screens, all rotations. (Rotating a square screen doesn't work exactly, but I'm not terribly worried about square screen rotation).

I then change the OAC's Resolution property to VGA, change the text of a label control on the OAC (so I can tell that the OAC is working), and then open my form in design mode using a VGA form factor. I may need to rotate the form left and right to see the changed label control, but eventually I can get the changed label control to display. The sizes of some of the controls and the size of the text in the controls appears smaller on the form than they do in the OAC, but that may be the way the OAC is supposed to work.

However, if I build the project, the change I made to the label control disappears (meaning, I think, that the build is using the QVGA variant of the OAC). If I deploy the project to a VGA emulator, I'm also not seeing the change I made to the label control.

Any advice?
Dec 13, 2006 at 6:23 PM
originally posted by: dcazzulino

Some ideas:
1 - Check that the AutoScaleMode on the form and control is set to None (scaling is done at design-time and saved to the resource already)
2 - Open the output assembly with Reflector, and make sure a resource with the name Control Namespace.Control Class Name.resolution-locale.resources exists. By doing that, you can make sure that the resources are being properly embeeded.
3 - Make sure you're using the very latest version of the OAC. Previous versions would not check at design-time for the proper class namespace (must match the assembly default target namespace and folder structure).

Let me know how it goes.
Dec 13, 2006 at 10:01 PM
originally posted by: LarryBB

Thank you for replying.

I have revised the test program so that the OAC is now contained in its own project. I've also changed the AutoScaleMode in the form from DPI to None, as you suggested. The OAC still does not appear correctly in a form in design mode with a VGA FormFactor. However, the OAC now appears to display correctly when deployed to the various emulators. So maybe the problem is solved. Not 100% sure yet.

I'm not sure if I've ever used Reflector before. I am guessing that the resource you're asking about would be located in the new project containing the OAC. I DO see five resources referencing different resolutions in Reflector. I don't see any locales mentioned in these references, but I haven't used the OAC to specify different locales, so this is probably OK.

I don't know how to tell if I have the latest version of the OAC.

I continue to have big big problems getting my hands around the MCSF. One problem is that I get errors when I try to open a number of the test projects, so I can't see any examples of the kinds of things I want to build. I use VS 2005 Professional, not the Team edition, and maybe this is the source of some of my problems. In any event, I'll probably need to rebuild the MCSF to restore these projects to their original states, as I've tried (unsuccessfully) to revise these projects so that I can view them.

For example: I'd like to figure out how to reference the controls in my OAC from outside of the OAC.

I'm an MCP in c# and I need to update the code of my company's mobile application, and honestly, I thought that the MCSF would speed this process. Instead, I'm completely bogged down in it.

Sorry if I'm ranting a bit.
Dec 14, 2006 at 7:23 AM
originally posted by: dcazzulino

1 - In order for the resolutions to appear on the designer of a parent form, you need to first compile the project, close the form designer, and reopen.

2 - Yes, the resources in reflector are the ones that should be there, that's OK. If you have not used locale-specific layouts, you're fine.

3 - You should be able to tell if you've installed from the MSDN download ;)

4 - Test projects where authored using VS Team Test, that's why you see the errors. But you should be perfectly able to see the source files. Maybe you would need to create a new empty C# project and add all the class files to it, but it should be pretty trivial.

5 - Referencing the controls in a control library project is something that is not MCSF-specific. Custom control authoring for mobile devices is not a trivial topic and you need to be familiar with the .xmta files, generation of design-time metadata, and the like. The OAC is not supposed to solve that platform learning curve, I'm sorry. So you should first read about general custom control development for devices (unfortunately, there isn't much information out there :().

What other areas are you struggling with?

HTH
Dec 14, 2006 at 8:39 AM
originally posted by: LarryBB

Replying to the numbered replies in your last post:

1. Sorry, I've tried compiling the project, then closing and opening the form. Most of the OAC elements (text boxes, labels) STILL do not display on the form in the right sizes when the form is in a VGA display mode (only the picture box seems to size and display correctly). The OAC displays these form elements correctly, and these elements all display correctly when deployed.

2. Good!

3. LOL.

4. I've changed a number of these test projects, mostly not for the better. To play with these projects again, I'd probably have to reinstall the MCSF.

5. Yes, I was afraid you'd say something like this. To be honest, I got into the MCSF based on a Series 200 (200!) webcast saying that the OAC was the simplest way to develop mobile applications that were orientation-aware. No doubt that the OAC may be the best and most sophisticated orientation-aware solution, but in hindsight it certainly seems easier to build orientation-aware functionality into each form, using form-based properties and events. At least it's easier if this is the only change you're looking to make to an existing project.

Granted, the MCSF clearly represents a set of best practices for mobile programming. No doubt, the components you've developed here are better than the ones I'm using. To be sure, it is worth my time to try and figure out what's going on in the MCSF. But the learning curve looks long and steep. I really appreciate being able to discuss this stuff with you, and you ARE a great help.

Let me ask another question. I see posts on this message board referring to what looks like a self-based tutorial. Where do I find this? I think this might be a better place for me to start.
Dec 14, 2006 at 9:16 AM
originally posted by: dcazzulino

1 - You made me remember! The actual rendering of the CHILD controls inside your custom control, at design-time and when placed on a parent Form in VGA mode, will not render properly because of the way the designer is doing auto-scaling (regardless of your form properties, I'm afraid). I couldn't fix that no matter how hard I tried. Probably, you would be better off just using QVGA for the (generally just simple OAC containers) form. At run-time, as you said, everything is figured out properly. I should have added a note about this in the Known issues section.

4 - My point is that unless you have the Team Test component on VS, you will never be able to compile the project. You will only be able to see the source.

5 - Yup, you're 100% right. Unfortunately, solving the OAC problem for any mid-to-large-size app using manual code in each form is a no-go for most shops. I'd definitely advice to spend a little more time with the custom control registration process. It will pay off pretty soon if your app has more than just a few forms. I found the following article very helpful (I was a newbie in terms of mobile development): http://symbian.sys-con.com/read/113332_1.htm. There's a fairly long article on the MSDN documentation too: http://msdn2.microsoft.com/en-us/library/aa446500.aspx.

In the downloads section, you should find the hands on labs.
Dec 15, 2006 at 4:47 PM
originally posted by: LarryBB

Sorry for the delay in responding. Your advice seems sound to me. I'm going to push forward with the MCSF and see what happens. Thanks for the terrific links on custom controls. I'll post back here as new questions arise. Thanks for all of your help, I appreciate it.
Dec 15, 2006 at 5:44 PM
originally posted by: dcazzulino

You're welcome!
Believe me, once you are over the learning curve (both on device custom controls and MCSF), you'll start enjoying it ;)
Dec 28, 2006 at 2:00 PM
originally posted by: LarryBB

Got distracted, but I'm turning back to this project now.

I'm focusing on how to set up the OAC control so that I can reach the properties, methods and events of each control within the OAC using code from outside of the OAC. It's a pretty simple matter, really. In fact, there are a lot of choices, and I'm hoping you can point me to the "best practice" here.

Let's say that I want to set up a listView control within the OAC, and I'm going to programmatically build the listView from code within the form containing the OAC. I seem to have 3 choices, somewhat inter-related:

1. I can set up a series of properties and functions within the OAC, and call these properties and functions as needed from the form containing the OAC. So, for example, I might include a property within the OAC that would get the current selected index of the listView, and a function within the OAC that would clear the listView. If I have more than one listView, I'd write separate properties and functions addressed to each listView.

2. Alternatively, I can set up a public listView property within the OAC, and set it to the listView control contained in the OAC. If I do this, I seem to be able to access the listView control directly within the form containing the OAC. This greatly simplifies the code in the OAC! (However, I suspect that if this was the "best practice", you would have built the OAC factory to automatically insert these properties in the OAC each time you create a control within the OAC).

3. There's a third alternative, somewhat in-between: you can include the functions as I described in paragraph 1, AND set up the controls within the OAC as properties as described in paragraph 2. Then when you call these functions from the form containing the OAC, you could also pass a control within the OAC as a function parameter. Say, for example, I had an OAC with more than one listView. Using this approach, I'd only have to write one set of functions to address all of the listViews in the OAC.

Which approach is the right way to go?

Larry
Dec 29, 2006 at 6:51 AM
originally posted by: dcazzulino

I'm creating a new thread for this topic, as it doesn't seem it's related to the OAC not working in VGA anymore ;)

See http://www.gotdotnet.com/codegallery/messageboard/thread.aspx?id=5bef2b5f-476a-488c-8d55-9d41666a36f3&mbid=36c8b5e8-2f1d-4955-81d1-a4fd351de974&threadid=4d548d15-c901-40c4-a214-71c3b2580d6f