|
|
Home » U++ Library support » U++ Core » Creating a com object
Creating a com object [message #32782] |
Thu, 09 June 2011 09:16 |
|
Hello All.
Now I'm trying to create a com object.
If I do not use Upp::String class then all works fine.
Midl compile without errors, the generated library loaded in other system without error and can use.
But when I try to use Upp::String then the created com object (dll) does not load into other system.
The Upp:String I use internly only:
like this:
Upp::String test("Some examples");
Any hints are welcome!
Add:
forgot to say:
I add in link option:
where .def file contains:
; AddIn.def : Declares the module parameters.
LIBRARY "1CAddIn_test.dll"
EXPORTS
DllCanUnloadNow PRIVATE
DllGetClassObject PRIVATE
DllRegisterServer PRIVATE
DllUnregisterServer PRIVATE
If I use CString or char* then it work without any problem.
[Updated on: Thu, 09 June 2011 09:35] Report message to a moderator
|
|
|
|
Re: Creating a com object [message #32791 is a reply to message #32784] |
Thu, 09 June 2011 14:10 |
|
tested ole calculator from examples and don't work.
I have been attached a simple example:
if in
void upp_test() function
or in
STDMETHODIMP CMyClass::MyMetod(BSTR *StrokaIn, BSTR *StrokaOut) method
decomment the String initialization variable line then I can't load the library in other system (www.1c.ru)
Please Help!
[Updated on: Thu, 09 June 2011 16:19] Report message to a moderator
|
|
|
Re: Creating a com object [message #32817 is a reply to message #32791] |
Sun, 12 June 2011 22:54 |
rylek
Messages: 79 Registered: November 2005
|
Member |
|
|
Hello Tojocky!
I've just had a quick look at your test example. I've tried to link it statically under VC71 and, even with the commented String lines, I'm unable to register the object using regsvr32; CComModule::RegisterServer fails here:
inline HRESULT CComModule::RegisterServer(BOOL bRegTypeLib /*= FALSE*/, const CLSID* pCLSID /*= NULL*/) throw()
{
HRESULT hr = S_OK;
_ATL_OBJMAP_ENTRY* pEntry = m_pObjMap;
if (pEntry != NULL)
Here, the m_pObjMap member is NULL and therefore registration bails out with an error code. Unfortunately I'm not a big MFC expert, I co-authored U++ among others in order not to have to become one, but it seems to me that the trouble is caused by MFC's DllMain not being called during OCX initialization (DllMainCRTStartup should invoke it through _pRawDllMain which gets initialized in MFC's atlmfc/src/mfc/dllmodul.cpp, but as I see it in the debugger it contains NULL).
Theoretically I can imagine that usage of U++ somehow brings in linking of standard C++ libraries before MFC libraries (as U++ uses standard C++ libraries but not MFC) and this causes the dummy DllMain stub from crt/src/dllmain.c to be linked into the application instead of the correct one from src/mfc/dllmodul.cpp. It might be possible to call the MFC's DllMain manually by declaring DllMain in your application and calling directly the RawDllMain function from the MFC package, but I'm afraid the obvious problem might be a mere after-effect of a deeper problem in MFC initialization in a DLL linked by U++ IDE (omission of a flag Developer Studio sets automatically or something like that); in my opinion it would be best to generate a dummy MFC OCX using Developer Studio, then try to re-build it using TheIDE and compare the linker command lines.
Regards
Tomas
|
|
|
Re: Creating a com object [message #32846 is a reply to message #32817] |
Tue, 14 June 2011 20:15 |
|
rylek wrote on Sun, 12 June 2011 23:54 | Hello Tojocky!
I've just had a quick look at your test example. I've tried to link it statically under VC71 and, even with the commented String lines, I'm unable to register the object using regsvr32; CComModule::RegisterServer fails here:
inline HRESULT CComModule::RegisterServer(BOOL bRegTypeLib /*= FALSE*/, const CLSID* pCLSID /*= NULL*/) throw()
{
HRESULT hr = S_OK;
_ATL_OBJMAP_ENTRY* pEntry = m_pObjMap;
if (pEntry != NULL)
Here, the m_pObjMap member is NULL and therefore registration bails out with an error code. Unfortunately I'm not a big MFC expert, I co-authored U++ among others in order not to have to become one, but it seems to me that the trouble is caused by MFC's DllMain not being called during OCX initialization (DllMainCRTStartup should invoke it through _pRawDllMain which gets initialized in MFC's atlmfc/src/mfc/dllmodul.cpp, but as I see it in the debugger it contains NULL).
Theoretically I can imagine that usage of U++ somehow brings in linking of standard C++ libraries before MFC libraries (as U++ uses standard C++ libraries but not MFC) and this causes the dummy DllMain stub from crt/src/dllmain.c to be linked into the application instead of the correct one from src/mfc/dllmodul.cpp. It might be possible to call the MFC's DllMain manually by declaring DllMain in your application and calling directly the RawDllMain function from the MFC package, but I'm afraid the obvious problem might be a mere after-effect of a deeper problem in MFC initialization in a DLL linked by U++ IDE (omission of a flag Developer Studio sets automatically or something like that); in my opinion it would be best to generate a dummy MFC OCX using Developer Studio, then try to re-build it using TheIDE and compare the linker command lines.
Regards
Tomas
|
Heloo Tomas,
Thank you very much for explanation.
|
|
|
Re: Creating a com object [message #55355 is a reply to message #32791] |
Mon, 02 November 2020 08:44 |
JeyCi
Messages: 50 Registered: July 2020
|
Member |
|
|
tojocky wrote on Thu, 09 June 2011 09:16But when I try to use Upp::String then the created com object (dll) does not load into other system.
BTW, I think you can try
Quote:WString -
WString implementation does not use small string optimization, first step is 23 wchars stored in 48 bytes memory block without reference counting, for larger string once again reference counting is applied. Sizes are also directly stored in "int" member variables.
it is exactly like BSTR - according to this description taken from U++ Help topics
Best regards.
[Updated on: Mon, 02 November 2020 08:46] Report message to a moderator
|
|
|
|
Goto Forum:
Current Time: Sat Apr 20 05:01:57 CEST 2024
Total time taken to generate the page: 0.03336 seconds
|
|
|