vole-users Mailing List for VOLE - A Neat C++ COM/Automation Driver
Brought to you by:
matsys
You can subscribe to this list here.
2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Heiko N. <hei...@it...> - 2013-06-06 14:34:35
|
Hi together! Since I want to do some MS Word automation I want to give VOLE a try ... But just after adding the header files to my source file and doing a test compilation I get the following message from the compiler: In file included from .../vole-0.7.4/include/vole/vole.hpp:61:0, from ...: .../vole-0.7.4/include/vole/collection.hpp: In member function 'vole::collection::value_type vole::collection::operator[](const I0&) const': .../vole-0.7.4/include/vole/collection.hpp:199:50: error: there are no arguments to 'get_checked_disp_' that depend on a template parameter, so a declaration of 'get_checked_disp_' must be available [-fpermissive] .../vole-0.7.4/include/vole/collection.hpp:199:50: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) Other then adding the workaround '-fpermissive': is there any real solution for this problem? Every get_checked_disp_() method seen in the code needs a parameter. Thanks in advance! Kind regards, Heiko Nardmann |
From: Duncan M. <dwm...@gm...> - 2009-09-24 03:14:46
|
Is it true that objects returned from invoke_method function hold weak references and deallocate themselves no matter what when they go out of scope? That seemed to be my issue and I addressed it by making the object static (so it stayed in scope even outside of the function)? On Mon, Sep 21, 2009 at 7:05 AM, Duncan McQueen <dwm...@gm...> wrote: > I have an object that is return from an invoke_method that needs to be > put globalling in a dll I am working on. > > After declaring a global like this: > > object *g_pTradeDesk2a = NULL; > > > I basically do this: > > object g_pTradeDesk2 = oCore.invoke_method<object>(L"CreateTradeDesk", > L"trader"); > > g_pTradeDesk2.get()->AddRef(); // VERY IMPORTANT! > > g_pTradeDesk2a = &g_pTradeDesk2; //assign pointer > > However, future references to the g_pTradeDesk2a variable fail with an > access violation. > > From what I can gather, it seems that the objects returned from > invoke_method function hold weak references and deallocate themselves > no matter what when they go out of scope. Is there a good way around > this to keep that object allocated? > |
From: Duncan M. <dwm...@gm...> - 2009-09-21 12:06:10
|
I have an object that is return from an invoke_method that needs to be put globalling in a dll I am working on. After declaring a global like this: object *g_pTradeDesk2a = NULL; I basically do this: object g_pTradeDesk2 = oCore.invoke_method<object>(L"CreateTradeDesk", L"trader"); g_pTradeDesk2.get()->AddRef(); // VERY IMPORTANT! g_pTradeDesk2a = &g_pTradeDesk2; //assign pointer However, future references to the g_pTradeDesk2a variable fail with an access violation. >From what I can gather, it seems that the objects returned from invoke_method function hold weak references and deallocate themselves no matter what when they go out of scope. Is there a good way around this to keep that object allocated? |
From: Roel V. <ro...@st...> - 2007-05-28 11:22:17
|
Hi, I found vole by accident yesterday and I'm really excited about it, because looking at the examples, it could make my work significantly simpler. However, I can't get my simple test case to work :( I want to automate Word, so what I did is the following: comstl::com_init init; vole::object application = vole::object::create("Word.Application"); and stepping through the code, all goes well until this function from comstl/util/creation_functions.hpp: template <ss_typename_param_k I> inline HRESULT co_create_instance( REFCLSID clsid, I **ppi, DWORD dwClsContext = CLSCTX_ALL) { return ::CoCreateInstance(clsid, NULL, dwClsContext, IID_traits<I>::iid(), reinterpret_cast<void**>(ppi)); } CoCreateInstance returns E_NOINTERFACE there, which then causes a creation_exception to be thrown a bit higher in the stack. However, the OLE/COM object viewer clearly shows that Word.Application implements IDispatch. I'm not a COM guru, that's why vole would be such a great thing for me - is there anyone who can tell me what I'm doing wrong here? Thanks. cheers, roel |
From: Matthew W. <ma...@sy...> - 2007-01-16 09:38:07
|