yang686526

debug assertion in call to odresbuf::getint16()
debug assertion in call to odresbuf::getint16()
i have recently installed the latest dwgdirect (1.13.2), and i am running into a problem when i load a dwg file. when i make the following call:
code:
m_pdwgfile->getsysvar("lwdisplay")->getint16();
the result is a debug assertion in location: resbuf.cpp, line 306
if i ignore the assertion, i get an exception:
code=42, description=invalid resbuf
i was able to reproduce the problem in the samples by adding the following line to the dbdumper::dumpheader() method in odreadexdll
code:
os << " lwdisplay: " << pdb->getsysvar("lwdisplay")->getint16() << std(endl);
this worked in my most recent builds using version 1.12.1 of dwgdirect (i haven't updated in a while.) we have our own rendering code, and this happens on the every entity in the file. the initial loading of the file seems to be fine.
can someone let me know what could cause the invalid resbuf error?
i am using vc++ 6.0 on windows xp professional.
cheers,
bob
last edited by bobc@bluemarblegeo.com; 12th september 2005 at 12:11 pmfff">. reason: added more info...
usually invalid resbuf means that it contains a value of other type. lwdisplay is boolean variable so getbool() should be used.
sergey slezkin
quote:
originally posted by sergey slezkin
usually invalid resbuf means that it contains a value of other type. lwdisplay is boolean variable so getbool() should be used.
that is interesting, because when i load a .dwg file into the mfc sample application and display the system variables, lwdisplay shows up as an int16, and getting it as an int16 worked in earlier versions of dwgdirect. i can certainly see that a boolean makes sense, given the meaning of the variable, but i would argue that since it is stored as an int16, it ought to be retrievable as an int16.
in any event, i will change my code to use getbool().
thanks for the quick reply.
bob
odamfcapp incorrectly displays all bool variables as int16.
lwdisplay is stored in dwg as bool (and is accessed so in objectarx). in dxf it is stored as int16 probably for some historical reasons.
sergey slezkin
no wonder i was confused.
thanks for the info.
bob