yang686526

plugin system using loadlibrary...
plugin system using loadlibrary...
hello,
i am currently working on a dll based plugin system for an application that uses opendwg. i am using loadlibrary() to load the plugin dll into the application's address space and then use getprocaddress() to access the plugin's extensions. because the plugins represent extension of the application (not only opendwg), the plugins are not derived from odrxmodule. so far the plugin loading mechanism is working as designed. now, on to the question...
at a high level, i am wanting to:
load my custom plugin and then be able to manipulate the database from within the plugin using a reference to the oddbdatabase of the active drawing.
currently i see the following behavior:
i am able to utilize the oddbdatabase reference to some extent. the first statement (executed in the plugin) succeeds, but the second fails.
code:
oddbobjectid modelspaceid = m_pdb->getmodelspaceid(); //succeeds
oddbblocktablerecordptr precord = modelspaceid.safeopenobject(oddb::kforwrite); //fails
the same sequence of calls, made in the application, succeeds. i have tried using a smart pointer and simple pointer to reference the db (in the plugin) with no change. i have implemented oddbsystemservices(ala exservices example) and used odinitialize(this)/oduninitialize() in init/exitinstance to very little result.
oddly, the exception thrown by thy safeopenobject method (oderror::`vector deleting destructor'(unsigned int)), when caught and displayed in a messagebox throws yet another exception.
code:
}
catch (oderror &e)
{
afxmessagebox(e.description());
}
the debug watch gives the following clue:
code:
odstring:perator char const * returned 0x01ab7e94 "object was erased"
the question(s) at last:
is there a smoking gun here? is there an initialization that i am missing or an assumption that is causing the problem? is there a better approach to application plugins (non .drx) that can manipulate the database?
thanks,
elliott edwards
last edited by hachiihcah; 9th august 2005 at 04:46 pmfff">.
i'm not sure what is the reason of your problems but check if your code matches requirements below.
1. all calls to dwgdirect functions must be between odinitialize() and oduninitialize().
2. storing pointer to database. it's not safe to use for m_pdb simple pointer. example:
oddbdatabase * pdb = psvs->readfile(..);
readfile() returns smart pointer.
its value is assigned to simple pointer.
smart pointer destructor (for returned object) is called. the smart pointer being destroyed is the last existing smart pointer to the loaded database so the database is destroyed.
simple pointer pdb points to released memory.
3. all dd objects must be destroyed before oduninitialize() is called else destructors may fail. that means that all smart pointers must go out of scope or zeroed before calling oduninitialize().
sergey slezkin
you say that application uses dd, so i assume odinitiaize/oduninitilize are called by the application.
what set of dd libraries do you use?
this sheme may work only if you use dlls, and link your plugin with md flag (dynamic runtime).
vladimir
md runtime, etc.
wvk - yes, both the plugin dll and the application make use of the /md[/mdd] compiler options and link against the appropriate (afaik) .lib files from dd (opendesign/lib/vc2003md[d]/*_*_dll.lib). both application and plugin use the .dlls from (opendesign/exe/vc2003/release[debug]/*.dll
odinitialize/oduninitialize are called for both in the application and the plugin
sergey - as for the pointer/smartptr issue, i started with the smartpointer and only attempted the traditional pointer to see if there was any variance in the refcounting somehow. since the database reference in this case is created and maintained in the application, there is at least one refcount for the db throughout the entirety of the plugin function scope.
today i will revisit the path that the database reference takes and see what comes up. it could very well be something else i overlooked. it sounds as if this approach should be attainable, i will attempt to iron out the details.
thanks,
elliott
and...
i will also verify that all my plugin calls fall between odinitialize/oduninitialize. i am fairly certain that it does, but *sigh* things like this are always worth retesting.
bloody underscores...
according to my compiler, there appears to be a difference between "_toolkit_in_dll" and "_toolkit_in_dll_".
...
problem solved...all good...thanks for the suggestions.