Today is my first day back to work after a week out of the office with the family and dog - this included hiking up Mt. Baker (which was awesome, fantastic views, great weather), visiting Vancouver (which was great, eh), and being "off the net", and here I am, first day back and I'm in the DoubleTree hotel in San Jose, getting ready to present at the Embedded Software Developers Conference tomorrow.
So, what am I doing tonight?
- Munching on some fantastic Ahi Tuna <yumm>
- Finishing slides/demos for tomorrow (CE, XPE, App-Dev)
- Working on a utility to parse eVC MFC/OCX projects and produce the right registry goo (more on this in a moment)
- Clearing up my Inbox after receiving over 2000 e-mails in a week (that'll teach me to take some time off!!)
- Playing with my new SPOT watch... <but I thought you already had a SPOT watch?> - yes, correct, but I've upgraded from the Abacus to the Suunto, it's water resistant to 100ft, looks really cool, and seems to have better battery life than the Abacus.
The DoubleTree in San Jose is pretty neat, **FREE WIRELESS ACCESS** in the lobby of the hotel, cool, eh! - the breakfast area is close to the lobby, so I will be able to sync mail, and RSS feeds, and catch up on comments to my Bolg, all while tucking into brekky, certainly beats reading a static newspaper (I wonder how much longer printed newspapers will be around with the increase of data enabled, small handheld devices [and SPOT watches]) - aren't newspapers a waste of natural resources? - anyhow, back to the plot - I seem to remember there's an omlette type thing that's a specialty in these here parts... I will have to take a look at the menu tomorrow and see if I can figure out what that is...
ok, so back to the eVC MFC/OCX problem...
Assume that you've just created an ActiveX control, written in MFC using eMbedded Visual C++, you now have a .OCX file... so now what ? - when you are testing the control from eMbedded Visual C++ the control (DLL) is downloaded to your target (typically over KITL), and then self-registers on the target device, this is cool, the control is registered, so any application that needs to use it can now do so.... BUT, what about including the OCX into the final operating system image, there are of course two steps to this.
- Add the physical OCX file to the operating system (using .BIB files)
- Have the control registered in the operating system - and this is the tricky one...
Why is this tricky ? - there are a few approaches to this (and I really don't like the first approach).
- Have a helper application register the DLL at boot time - this (IMHO) is really messy, loading the DLL, calling it's DllRegisterServer( ); function, and then releasing the DLL - why should I need to do this - it would be better to have the registry information included into the O/S image, so that when the O/S boots the OCX is available for applications to use.
- Option #2 - parse the project files .ODL and PropertyPage.cpp files to extract the GUID's needed to recreate the registry information
- The third option (also messy) is to register the DLL through eMbedded Visual C++ then using the remote registry editor extract the registry bits you need and.... (you get the idea - it's messy and prone to error - do you know the locations in the registry that are updated by registering a Windows CE .OCX file?)
Windows CE 5.0 helps with the overall process because we can now create a dummy project to hold all the information about the eVC OCX project, the BIB information (to include the binary), and the .REG information which will hold the registry information for the control - with Windows CE 4.2 we needed to update the project.reg file, and the project .bib file to include our custom binaries...
So, I've just started writing a little C# utility to parse eVC OCX projects and recreate the registry information so that this can be dropped "as is" into a .REG file to have the control pre-registered in the O/S.
I will post an update to this project once it's complete (should be sometime in the next couple of days).