none
How can I refer EVC++4.0 COM DLL in EVB3.0 Project RRS feed

  • Question

  • Hi all,

    I am trying to develop an  evc++ 4.0 DLL using WCE ATL COM APPWizard project. My intention is to refer this dll in one of our applications running in Windows Mobile 6.0 devices.This application is written in EVB 3.0.

    I am able to create this DLL using evc++ 4.0 and i am able to register this dll in the device successfully. But when i try to refer this DLL from evb 3.0 application it is throwing an error saying that unable to create activex object. I am trying to create object of this dll using this piece of evb code.

    dim objExcel;

    Set objExcel = CreateObject("ExcelObject.Excel");

     

    But, following the same steps, when i created a DLL using evc++ 3.0 WCE ATL COM AppWizard project, i was able to refer this dll susccessfully  from an evb 3.0 project.

    My question is, Can I refer a latest version DLL (using evc++ 3.0 targetting Pocket PC 2003 devices) in EVB 3.0 projects ?

    This evb application is going to run finally in Windows Mobile 6.0 devices and above..

     

    Thanks in advance,

    Sreehari

    Friday, June 25, 2010 11:52 AM

All replies

  • Why are you using these ten-year-old tools to target a brand new device?  It seems to me that using Visual Studio 2008, with the correct SDK, and a full-featured programming language (VB.NET, for example), which eVB3 never even approached, would be a much smarter starting point for this.

    As for the question itself, COM doesn't care what version of the C compiler you are using to build a DLL, so there should not be a compatibility problem.  However, eVB 3's run-time is definitely NOT supported on Windows Mobile 6 devices.  eVB has been obsolete for something like 8 years.

    Still, there's a chance that it's not eVB's fault.  Go to the registry and make sure that the COM entries that should be there for your COM object are actually present and refer to the correct DLL, that the DLL is present in the correct location.  Finally, try creating an instance of the object from C++, rather than from eVB, to be sure that Windows Mobile isn't having a problem with COM in general.  C++ should give you a much better error code if there's a failure.

    Paul T.

    Friday, June 25, 2010 4:49 PM
  • Hi Paul,

     

    Thanks for your reply.  I know its a crazy thing to be still holding evb for targeting windows mobile devices. But we  have a product that is still in market that is developed using evb. We have an incompatible component written in evc++ 3.0  and i am rewriting it using evc++ 4.0.

     

    I checked the device registry after registering the DLL. I can see entries for this DLL under class root and also under CLSID element. Also the path of the dll is valid.

     

    I tried to refer this dll in a  C++ project.  I opened a normal WCE application and tried to refer this dll using classwizard. But it is failing to load the classes from this DLL.

    How can I move ahead?

    Thanks,

    Sreehari

     

    Friday, June 25, 2010 7:06 PM
  • You can't use Class Wizard (remember that your DLL is not compiled for an x86 processor, so desktop tools won't be able to call functions to determine the attributes of the DLL). 

    In C++, do a CoCreateInstance() with your CLSID, asking for the IDispatch interface.  That will establish the base COM functionality.  If that works (you can try calling a method or two of the control class to verify), try CLSIDFromProgID() with your ProgID, which looks to be ExcelObject.Excel.  If that also works, that's all that should be needed for eVB to create the object instance as you've described it to us.  Since it's failing, at that point, I'd have to assume that somehow eVB is preventing the load.

    Can we assume that you have successfully gotten at least a very simple eVB program running on the device?

    I'd start planning the project to drop this old application and rewrite it...

    Paul T.

     

    Friday, June 25, 2010 11:14 PM