Answers to recent questions
Had a few QFEs to install, so more down time while I create an updated image, so on to the recent questions I've gotten through feedback! The first question was from Mike Dimmick: “will the next version of MFC/CE use C++ exceptions, rather than the old MFC setjmp/longjmp version?“. The answer is yes the next version of MFC for Windows CE will use C++ exceptions instead of the old MFC setjmp/longjmp imitation exceptions.
The next question was, also from Mike, is “I guess [the question of whether the next version of MFC for Windows CE will use C++ exceptions] is a tough question, because some OEMs may not wish to include C++ exception support in their platform - but aren't C++ exceptions required for .NET CF anyway?”. The answer to this is yes, the next version of the .NET Compact Framework will require C++ exceptions, as they are utilized in the new COM interop support being provided in the next version. It's my understanding that the current version of the .NET Compact Framework does not require C++ exceptions, because it does not have the COM interop support.
The subject of the C and C++ compiler helper functions and the C Runtime being built into the OS is the subject of some debate internally here at Microsoft. Ideally, in my opinion, none of these APIs would be built into the OS, so that developers could utilize whatever the latest version is that is compatible with the version of the OS they want to target; however, because much of this is currently built into coredll.dll, there are some potential technical barriers to moving these APIs in to our standalone C/C++ runtimes. One option we are considering is including all of the C++ EH and C++ RTTI helper functions in our standalone C/C++ runtimes, but there is currently an issue of link order. If coredll.lib is first then the APIs will get imported from coredll.dll, but if msvcrt.lib is first, then the APIs will get imported from msvrt80.dll (or optionally libcmt.lib if linking statically); however, the linker may throw an error if two import libs have the same APIs, I know it’s okay for static libs, but I haven’t had a chance to check what happens for import libs.
The last question isn’t a question but rather is a technical issue from Lin Wang. It was actually addressed to one of the folks providing feedback on my blog, but since this isn’t a message board, they probably won’t respond, so I’ll give it a shot. The issue is “I have a question about CommandBar_Create. Well, I was able to add the menu bar to the commandbar created. But the menu is at the top of the screen. The menu is covered by the top of the dialog screen. Is there anyway I can move the menu to the bottom? Or is there anyway I can position the dialog screen? I tried using SetWindowPos, but it did not work, since the dialog always expand to the screen...”
The solution is to use SHCreateMenuBar instead of CommandBar_Create to create the menu bar. SHCreateMenuBar is part of the AYGSHELL APIs originally created for the Pocket PC style shell. Where as CommandBar_Create part of the original APIs provided by basic Windows CE and provides a more classic Windows look and feel.
