Ok I have fixed the errors. It seems that I needed to pay closer attention when fiddeling with STAThread and MTAThread attributes.
The errors go away setting the creation/access threads to MTA, but ensuring all threads accessing the COM objects are MTA is tedious, as any events (OnMouseclick for instance) triggered from STA (Forms UI) required me to make worker threads that are MTA to
do the work using COM interfaces. These MTA worker threads make calls to Form UI again so again more wrappers for invoke were required.
So the original problem described at the top was caused by the fact that Control.Invoke spawned a STAThread, which caused that E_NOINTERFACE error. Therefor the mistake was made by me, or the programmer not making sure that all COM access originated from MTAThread.
The original implementation onto Windows CE Masked this problem as windows CE does not seem to have a problem with this.
The port is compete, no exceptions, but the hackinng required to make it work must have broken something. Normal controls work fine but the map drawing failes for some reason. At least I understand the COM now.
Hi guys, DISCLAIMER: for the record please accept my appology for rudely interupting to ask a pretty basic question the answer to which (of course)
may reveal my ignorance.
If you are porting to WPF, as Dexter mentioned, mostly this kind of thing is handled by the CLR, why have you not optioned to just use COM Interop and WRAP your unmanaged
code in a managed class? I may be wrong, however I think this might give you the added isolation you require.