yang686526

mutliple calls to findfile() when xref not found
mutliple calls to findfile() when xref not found
hi,
we've observed that during vectorization, when a xref is not found (i.e. blank string is returned from findfile()), the findfile() is called three more times, with the same filename/relative path/full path as the first time.
the call stack is different in each case, but the last callee is always oddbxrefman::load().
also if there are multiple xrefs in the drawing, the calls are intermingled. eg. a few calls for the first one comes, then for the second, then again for the first.
the problem we're facing because of this is that if the xref is not found, we're asking the user to locate it. if he can't locate it, or decides to drop it, we pass a blank odstring back from our findfile() override. but then we're given the call again and again for the same file.
can anyone explain this behavior and suggest a remedy.
thanks,
varun
forgot to mention: we use dd libs 1.14.02 for vc8 and xcode.
thanks,
varun
anyone has any suggestion regarding this? surely someone must have ran into such problems before?
thanks,
varun
someone help!
regards,
varun
would one of the dd guys venture some help?
regards,
varun
hi,
is this expected to be fixed in the next release?
as a workaround, i thought about caching the xref names whenever findfile() is called for an xref on each import and only asking the user to locate the xref if an entry is not found in the cache. but this would fail in case a single file is referred multiple times in the drawing being vectorized.
it will be most helpful if someone can suggest a good workaround for this.
regards,
varun
hi,
multiple calls of findfile() with "invalid" path when xref is not found can be a normal situation while nested xref searching.
dwgdirect uses the both host database and xref database folders for searching xref with relative path and updates the path value for xref-blocks in the host database.
to avoid an unnecessary asking the user to locate xref file you can use events of the odeditor class:
code:
virtual void odeditorreactor::beginattach(oddbdatabase* ptodb, const odchar* filename, oddbdatabase* pfromdb);
virtual void odeditorreactor::endattach(oddbdatabase* ptodb);
virtual void odeditorreactor::abortattach(oddbdatabase* pfromdb);
odxrefman::load() method do the next steps (only connected with the current task):
calls findfile() for a current xref;
fires odeditorreactor::beginattach();
performs loading of the xref <and also using findfile() for searching nested xrefs>;
fires odeditorreactor::endattach()/abortattach().
so you could ignore any calls of findfile() method between beginattach() and endattach()/abortattach() events.
regards,
sergey vishnevetsky
do i override the methods in odeditorimpl class?
regards,
varun
it needs to override methods of odeditorreactor class:
code:
class odmyeditorreactor : public odeditorreactor
{
public:
void beginattach(oddbdatabase* ptodb, const odstring& filename, oddbdatabase* pfromdb);
void abortattach(oddbdatabase* pfromdb);
void endattach(oddbdatabase* ptodb);
};
and attach the reactor to odededitor() object:
code:
odededitor()->addreactor(&editorreactor);
(don't forget to remove reactor before uninitializing dd).
regards,
sergey vishnevetsky
hi sergey,
i tried the approach, but it doesn't work.
if for an xref, i return a blank (or invalid) path, beginattach()/endattach()/abortattach() etc. are not called. instead, findfile() is called again.
when i do return the correct path for the xref, then beginattach()/endattach()/abortattach() etc. are called, but no further findfile(). this scenario was working fine before as well and did not need a workaround. we only had problem when xref was not found.
in my opinion, the steps you mentioned for odxrefman::load(), assume that the xref is found in the first step (else, what would it have to attach/detach to?) which is not our case.
in our case, if in the first call to findfile(), we're unable to locate the xref automatically, we throw up a dialog to the user asking for him to locate it. if he fails to do so, we don't want calls to findfile() again, as this would result in another dialog.
regards,
varun
hi,
yes, you are right, i described another case.
we'll add appropriate changes in 2.1 release to avoid multiple calls of findfile() when xref not found.
regards,
sergey vishnevetsky