yang686526

dwg vs dxf
dwg vs dxf
is there a difference in the way these libraries process dwg and dxf files that might lead to a "was open for write" virtual method error?
my specific case involves the creation and deletion of raster attachments, as well as moving non image objects.
a hint of what kinds of things to look for in my code would be helpful (there's really too much code involved in this problem for me to post it all here)
thanks
clarification
the error only occurs when i run dwg files (and not when i run dxf files)
you may catch oderror_wasopenforwrite exception, and look what object is open via oderror_wasopenforwrite::getobjectid()
vladimir
what version has this?
indeed, it appeared to be missing in public headers.we well move it there in the next release, sorry for inconvenience.
for now you may declare this class manually somewhere in you code:
code:
class toolkit_export oderror_wasopenforwrite : public oderror
{
public:
oderror_wasopenforwrite(oddbobjectid id);
oddbobjectid getobjectid() const;
};
vladimir
am i missing something?
ok thanks, it now compiles with that addition, but now it seems to skip over the catch, and still enters the standard oderror catch:
...
catch (const oderror_wasopenforwrite& err)
{
oddbobjectid errobj = err.getobjectid();
odstring msg = errobj.gethandle().ascii();
std(cout) << "\naddimages oderror_wasopenforwrite thrown: " << msg.c_str()
<< " was still open" << std(endl);
return 1;
}
catch (oderror& err)
{
odstring msg = svcs.geterrordescription(err.code());
std(cout) << "\naddimages oderror thrown: " << msg.c_str() << std(endl);
return 1;
}
catch (...)
{
std(cout) << "\nsome general exception thrown during addimages, exiting\n";
return 1;
}
return 0;
}
is there something i'm still missing?
and what does stack trace look like, if you place break point in the second catch clause?
did you try to cast oderror& to oderror_wasopenforwrite&
if code()==ewasopenforwrite?
vladimir
found a fix
casting oderror& to oderror_wasopenforwrite& seemed to work, but only when i added this line to the temp header for oderror_wasopenforwrite:
oderror_wasopenforwrite(oderror err) : oderror(err){}
... now i just need to find out why these images are not closing
i want to add about difference between processing dwg and dxf. the only difference is that in previous dd versions the check if object is opened for write was made only while writing object to dwg file. currently the check is made while saving dxf too.
saving to file modified and not closed object may result in writing an invalid file.
sergey slezkin
thanks (dwg issue apparently resolved)
after taking a break from my dxf issues, i went ahead and resolved the issues i was having writing out to dwg files... it seems that my list object was keeping references of the images alive after i was done using them.
i had tried clearing it out before, but apparently trying to do so before the database audit caused issues.... instead i now clear out the list just before i write to file.
thanks,
~chuck