yang686526

access violation loading dxf file
access violation loading dxf file
using the attached .dxf file and .shx file, i get an access violation when i open and attempt to draw. the .dxf file will display without the .shx file. i have reproduced the problem in odamfcapp. i am using version 1.13.0. most/all text should be displayed using japanese characters (with the .shx file). this does work correctly using the old opendwg viewkit, which we are replacing with dwgdirect. here is the stack:
oddbfontservices::loadstylerec(odgitextstyle & {...}, oddbdatabase * 0x05d24e20) line 188 + 20 bytes
odgitextstyle::loadstylerec(oddbdatabase * 0x05d24e20) line 48 + 32 bytes
gifromdbtextstyle(const oddbtextstyletablerecord * 0x05d2d0e0, odgitextstyle & {...}) line 97 + 25 bytes
gifromdbtextstyle(oddbobjectid {...}, odgitextstyle & {...}) line 85 + 18 bytes
oddbtextimpl::worlddraw(odgiworlddraw * 0x05c15a80, const char * 0x05d39fdc, const char * 0x00000000) line 772 + 27 bytes
oddbtext::worlddraw(odgiworlddraw * 0x05c15a80) line 766 + 29 bytes
odgibasevectorizer::dodraw(unsigned long 1, const odgidrawable * 0x05d38a70) line 810 + 17 bytes
odgsbasevectorizeview::dodraw(unsigned long 1, const odgidrawable * 0x05d38a70) line 2093
odgibasevectorizer::draw(const odgidrawable * 0x05d38a70) line 769 + 34 bytes
odgsentitynode::update(odgsbasevectorizeview & {...}, odgscontainernode * 0x05d24720) line 867 + 49 bytes
odgscontainernode::update(odgsbasevectorizeview & {...}, odgscontainernode * 0x00000000) line 605 + 21 bytes
odgsbasevectorizeview::display(unsigned char 1) line 1599 + 19 bytes
odgsbasevectorizeview::update() line 1661 + 18 bytes
exgdivectorizeview::update() line 307
odgsbasevectorizedevice::update(odgsdcrect * 0x00000000) line 193 + 16 bytes
exgsgdivectorizedevice::update(odgsdcrect * 0x00000000) line 127
odgsmodellayouthelperimpl::update(odgsdcrect * 0x00000000) line 386 + 31 bytes
cdwgviewer:aint() line 215 + 38 bytes
cdwgviewer::drawerthread() line 265
cdwgviewer::_drawerthread(void * 0x065259f0) line 204
kernel32! 7c80b50b()
attached files
i can't reproduce the situation in 1.13.0, 1.12.04, 1.14.01
does it happen always on your computer, what are exactly the steps to reproduce it in odamfcapp?
sergey slezkin
1. put the .dxf and .shx files in the same directory.
2. run odamfcapp.
3. file->open and select the .dxf file.
4. click on vectorize button. <-- crash happens here.
if i delete/move/rename the .shx file and follow the same steps, the file displays fine (after doing a zoom extents), but most of the text displays as question marks.
the same crash happens in our application when i try to use the .shx file. that is why i tried (and did) to reproduce the problem in odamfcapp.
by the way, i am using wingdi to render, if that is important.
last edited by wageoghe; 4th january 2006 at 04:16 pmfff">.
sergey, please look!
i have debugged this problem using the dwgdirect source code and here is what i have found:
there is some in dbfontservices.cpp called oddbfontservices::loadstylerec. this function tries to resolve the font information from the input odgitextstyle object (style). there is a lot of stuff about getting the preferable font and lookin for a substitute font. eventually, it starts looking for the font using findfile. finally, control gets to this code:
// big font
if (!style.bigfontfilename().isempty())
{
odstring filename = getbigfontfilepath(style, pdb);
if ( filename.isempty() )
style.setbigfont(0);
else
{
style.setbigfont(odfonttable::getfont(filename));
if ( style.getfont()->isshxfont() )
((odshxfont*)style.getbigfont())->setmainshxfont(((odshxfont*)style.getfont()));
}
}
else
style.setbigfont(0);
in my case ( land1.dxf, bigfont.shx in same directory ), style.bigfontfilename is not empty, so it goes in the if block. getbigfontfilepath does find bigfont.shx in the same directory as the dxf file, so it goes to the line that calls setbigfont. the crash is happening on the next line:
if ( style.getfont()->isshxfont() )
at this point, when i step into style.getfont(), i can see that m_pfont is not pointing to anything ( m_pobject is 0x00000000 ). control then returns to loadstylerec and the reference returned by style.getfont() tries to call isshxfont(). unfortunately, style.getfont() is not returning a reference. perhaps, in the case of a bigfont, style.getbigfont() should be used?
this is fixed in 1.14. if you need to fix 1.13 you can move the fix from your 1.14 sources to 1.13
sergey slezkin
that fixed the problem. thanks!
i really appreciate the prompt support that we usually receive in this forum.