style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<xtend> wrote in messageThank
href="news:6195068@discussion.autodesk.com">news:6195068@discussion.autodesk.com...
you. I guess I couldn't find that because I was thinking the wrong way about
it. Since AcApDocument* AcDbDatabase::document(); doesn't exist but
AcApDocument* acDocManager->document(AcDbDatabase*); does, I assume that
the AcAp pseudo-namespace is unavailable in Dbx?
this seems to be what I need - I'm trying to lock the current docuemnt in objectARX.
but I'm geting this when I include it and compile:
1>BCHF_LotObject.obj : warning LNK4248: unresolved typeref token (01000031) for 'AcDbStub'; image may not run
1>BCHF_LotObject.obj : error LNK2028: unresolved token (0A0001CA) "class AcApDocManager * __cdecl acDocManagerPtr(void)" (?acDocManagerPtr@@$$FYAPEAVAcApDocManager@@XZ) referenced in function "public: enum Acad::ErrorStatus __cdecl BCHF_LotObject::ConstructPoly(class AcDbObjectId)" (?ConstructPoly@BCHF_LotObject@@$$FQEAA?AW4ErrorStatus@Acad@@VAcDbObjectId@@@Z)
1>BCHF_LotObject.obj : error LNK2019: unresolved external symbol "class AcApDocManager * __cdecl acDocManagerPtr(void)" (?acDocManagerPtr@@$$FYAPEAVAcApDocManager@@XZ) referenced in function "public: enum Acad::ErrorStatus __cdecl BCHF_LotObject::ConstructPoly(class AcDbObjectId)" (?ConstructPoly@BCHF_LotObject@@$$FQEAA?AW4ErrorStatus@Acad@@VAcDbObjectId@@@Z)
1>U:\VisualStudio2012\Projects\BCHF V 0.0.0.1\CoreComponents\LOTtery2013\LOTtery_VBUI - V0.0.1.1\x64\Debug\BCHFLOT_DBX.dll : fatal error LNK1120: 2 unresolved externals
which looks like missing references but I've got \inc and \inc64 and \lib-64 all tagged in additional directories..... any ideas?
Hi,
Since you only posted the VS log without more detailed information, I may be wrong but I see 'BCHFLOT_DBX.dll', which seems to mean you are building a dbx project (BTW, you should rename its extension). dbx projects must not depend on AutoCAD (see "User Interface and Database Access" section of object arx documentation for instance).
In short, you are trying to use "acDocManagerPtr", this method is exported from acad.lib, which means you are trying to "depend on AutoCAD" in your dbx project.
-> In other terms, you musn't lock autocad document in your dbx application but in the arx module (usually through commands) that calls this dbx methods.
--------------------------
Details:
- dbx projects usually include "dbxHeaders.h" which auto-links (#pragma comment (lib ,"acui19.lib")) to dbx libraries ("acdbXX.lib" for instance)
- arx projects usually include "arxHeaders.h" which auto-links to arx libraries ("acad.lib" for instance).
This way, if you include "acdocman.h" in your dbx project as you surely did (compile error otherwise), it results in having the link error you got.
--------------------------
I hope this helps.
I actually found the missing library at the end of an exhausting day and then got sick 😞 I'm home now - as soon as I'm well enough I'll post the library and the precise call that needed it. worst thing is I know this happened a month ago but I just couldn't remember the reference. so frustrating....
Here is the usual list of arx libraries you mustn't link against in dbx projects:
- accore.lib
- acad.lib
- acui19.lib
- adui19.lib
There are also a couple of additional unusual libraries you can find in arxheaders.h.
doing so might work within autocad although strongly not advised but fail in any RealDWG or OEM based products. For instance, linking against acad.lib require acad.exe to be loaded in order to load your dbx, that mean that a RealDWG application won't be able to load it.
here is an article on this topic:
http://adndevblog.typepad.com/autocad/2013/01/understanding-objectdbx-and-realdwg.html
oh for @#$@!$!@ sake.
I'm implementing a project not unlike polyamp - it largely managed by vb.net - I had everything working fine then when I hooked it up to a palette interface I'm told I need to "lock" the current document no - I've done it in vb but I need to do it in objectARX as well at points. and this:
AcApDocument* pDoc=acDocManager->document(acdbHostApplicationServices()->workingDatabase());
makes a call to:
accore.lib
Surely the custom object can access the current database in some way, right????
Also it should be noted that dependency on AutoCAD is fine - this is an in - house product for a large firm, it can't be sold.
hmmm.
I'm almost afraid to ask as I'm sick to death of working out acrxEntryPoint changes, but....
does that mean my vb.net project, which calls a dbx code project, when the dbx NEEDS to do it's own calcs and database access, should ADD an arx project AS WELL to call and manage?
Please, someone say no.
We do not have psychic abilities to determine the design goals of your project, so we have no way of knowing what you *should* do. However, if you are implementing a palette, you are creating an ARX module, not a DBX module.
Fair enough...I'll elaborate a bit.
The palette is called in vb actually calling a mixed managed custom dbx object, but I want to give the dbx object it's own functionality as an object. for exampe, a derived polyline object has its defintion (polyline wise) created by passing a polyline into it (by my design) like this:
in vb.net:
dim devPoly as New devPolyObject
devPoly.ConstructPoly(somePolyineObjectID)
causes the the c++ fuction [Construct Poly] in the dbx object to suck in the vertix of the poly and then (here's the catch) delete it. I need to lock the databse to do that and hence the darned call. I can re-write to delete the poly in vb just didn't want to, though I'm begining to think if a dbx object wants to write to the database it needs an arx component to do it and make calls to functions there, or else do it through the vb.
If that made sense? I"m still home sick so may not be as clear as I think I am lol.
If by "delete it" you mean "open it for write and set its erased flag", then that is fine in a DBX, but it is then the resposibility of document-based callers to lock their document before calling the function (non-document based hosts don't have to worry about it, of course). If you have a palette UI that initiates the call into the DBX, then the palette UI must lock the document before asking the DBX to access it.
Ok...I've tried a lot of arrangements, but never that [exact] one ! 😉 thanks, I'll give it a go.
Awesome
Thanks alot , your post is helped me a lot . I was just frustrated with this error after all code changes .
Finally at last moment i found this thread and i feel greatfull to find this thread and solution you have provided .
Once again Thank you.