yang686526

setupactivelayoutviews/setuplayoutviews
update error
hi, i am having trouble with both of these functions in v1.11 and it worked in v1.10/1.10update.... if i do something like... pdevice = oddbgsmanager::setupactivelayoutviews(pmydevice, pdwgcontext); it crashes on internalqueryx function at the 3rd pass cause the pointer is null... pdevice is a class type exgshyprdevice that derives
public odgsbasevectorizedevice and public odgigeometrysimplifier
is there anything that changed for both of those functions or is it somewhere else that i am having trouble... cause right now its reaally on either of these setuplayout functions that it crashes with a first chance exception
update i added the drawing that crashes the viewer i am working on... it was making v1_10update odmfcapp crash too dunno about 1.11 since it wont compile...
right now i am using v1.11 for the libs and includes, it does the same thing in both vc.net 2002 and vc++ 6
update 2
the problem seems to be more in the update... i have a repaint function that calls the update function of the device pdevice->update(); and then it loops and renders the drawing.... it passes 3 times in the view::update() function and the third time it crashes on the seteyetooutputtransform(eyetoscreenmatrix());
also using v1.11 drawings seem to have garbage or misplaced items, for example hummer elevation.dwg that is in autocad 2004 samples there is a green line passing through the drawing in v1.11 and it wasn't there in v1.10update once again since it is a shift between 2 libs, is there something that changed in the way to handle the process? or something new that needs to be implemented for rendering to work in a proper way?
thanks in advance
charles
last edited by clisk; 8th june 2004 at 12:40 pmfff">. reason: corrected the error...
hi,
yes, actually setupactivelayoutviews/setuplayoutviews are changed to return odgslayouthelperptr instead of odgsdeviceptr. result can be casted either to odgspaperlayouthelper or odgsmodellayouthelper (see dbgsmanager.h). it can be directly assigned to odgsdeviceptr or odgslayouthelperptr. these functions return wrapper object over passed-in device pointer so the result must not be passed back into them.
please, send drawings with problems to us, but just after making sure that problem occurs in odamfcapp.
>>dunno about 1.11 since it wont compile...
we'll check compilation of odamfcapp example.
last edited by dmitry a. novikov; 9th june 2004 at 04:41 amfff">.
thanks ill check that out of the setuplayout and for the odamfcapp it compiled at home and wont compile at work... so i sent myself the exe at work to try it... the app says... "regen failed invalid input" when i am opening the file with wingdi...but it seems to work in opengl... for our "viewer" we use the exgssimpledevice example right now as a starting point and implemented the functions we need... if i put a drawing in attachment is it anyone that can get it or only the soft development team that can? because its a drawing that i cant really share with everyone that causes the bug from what i've seen so far in v1_101 or v1_11
it still does the same thing, it renders to the point of the 3rd pass at the eyetoscreenmatrix for this drawing. i tried using
pdevice = oddbgsmanager::setupactivelayoutviews(pmydevice, pdwgcontext); where pdevice is a odgslayouthelperptr and when i update, it does the same crash... using pdevice->update(0); if i use pmydevice->update(0) everything renders and no crash but the rendering is all messed up, most of the rendering is alright but some of it is just way out of the track. rendering is all messed up with either pdevice (the odgslayouthelperptr) or the pmydevice... only in v1.11 in v1.10update it renders well but crash on this 1 drawing
as i mentionned previously, we based our viewer on exgssimpledevices . if i open the drawing in singledoc it works well at least it seems like it works well. in odamfcapp it works in opengl and fails in wingdi... i know in odamfcapp it finds and fix 35 errors... coult it be those that bugs up our viewer? i am lacking ideas right now to fix the problem...
is it possible to send you the drawing to check it out?
last edited by clisk; 9th june 2004 at 07:37 amfff">. reason: updated to correct error...
>>i know in odamfcapp it finds and fix 35 errors... coult it be those that bugs up our viewer?
so did you try to render file fixed by odamfcapp in your viewer ?
>>is it possible to send you the drawing to check it out?
just attach it to a forum message.
yes i did and it does the same thing, there is 1 error that seems to be "sticky" that odamfcapp doesn't seem to fix... "acdbmtext(d239) x-axis direction invalid"
the test drawing is in attachment, it is a zip because its too big to be uploaded otherwise. thanks in advance for your time
last edited by clisk; 9th june 2004 at 10:20 amfff">.
i can reproduce it in odamfcapp. bug is logged.
here is the hot fix:
code:
void yourgsview::update()
{
odgsdcrect rc;
getviewport(rc);
// check if viewport is degenerated
if(rc.m_max.x-rc.m_min.x != 0 || rc.m_max.y-rc.m_min.y != 0 )
{
odgsbasevectorizeview::update();
}
}
last edited by dmitry a. novikov; 9th june 2004 at 09:25 amfff">.
code:
void exhyprview::update()
{
device()->setdrawcontext(drawcontext());
// comment function below to get primitives in eye coordinates.
seteyetooutputtransform(eyetoscreenmatrix());
// perform viewport clipping in eye coordinates:
m_eyeclip.m_bclippingfront = isfrontclipped();
m_eyeclip.m_bclippingback = isbackclipped();
m_eyeclip.m_dfrontclipz = frontclip();
m_eyeclip.m_dbackclipz = backclip();
m_eyeclip.m_vnormal = viewdir();
m_eyeclip.m_ptpoint = target();
m_eyeclip.m_points.clear();
odgevector2d halfdiagonal(fieldwidth() / 2.0, fieldheight() / 2.0);
m_eyeclip.m_points.append(odgepoint2d::korigin - halfdiagonal);
m_eyeclip.m_points.append(odgepoint2d::korigin + halfdiagonal);
m_eyeclip.m_xtoclipspace = getworldtoeyetransform();

pushclipboundary(&m_eyeclip);
odgsbasevectorizeview::update();
popclipboundary();
} // end exhyprview::update()
that is what i had... it is basically a copy of exgssimpleview and if i put it as...
code:
void exhyprview::update()
{
odgsdcrect rc;
getviewport(rc);
// check if viewport is degenerated
if(rc.m_max.x-rc.m_min.x != 0 || rc.m_max.y-rc.m_min.y != 0 )
{
odgsbasevectorizeview::update();
}
}
it causes an access violation when it gets to odgsbasevectorizeview::update();
the issue is really when it tries tocall the function/const eyetoscreenmatrix() it crashes there with a first-chance exception
quote:
first-chance exception in viewers.exe (kernel32.dll): 0xe06d7363: microsoft c++ exception.
it is in internalqueryx that on the 3rd time it calls eyetoscreenmatrix() that the pobj is not existant so it crashes...
code:
void exhyprview::update()
{
if(rc.m_max.x-rc.m_min.x == 0 || rc.m_max.y-rc.m_min.y == 0 )
return;

device()->setdrawcontext(drawcontext());
// comment function below to get primitives in eye coordinates.
seteyetooutputtransform(eyetoscreenmatrix());
// perform viewport clipping in eye coordinates:
m_eyeclip.m_bclippingfront = isfrontclipped();
m_eyeclip.m_bclippingback = isbackclipped();
m_eyeclip.m_dfrontclipz = frontclip();
m_eyeclip.m_dbackclipz = backclip();
m_eyeclip.m_vnormal = viewdir();
m_eyeclip.m_ptpoint = target();
m_eyeclip.m_points.clear();
odgevector2d halfdiagonal(fieldwidth() / 2.0, fieldheight() / 2.0);
m_eyeclip.m_points.append(odgepoint2d::korigin - halfdiagonal);
m_eyeclip.m_points.append(odgepoint2d::korigin + halfdiagonal);
m_eyeclip.m_xtoclipspace = getworldtoeyetransform();

pushclipboundary(&m_eyeclip);
odgsbasevectorizeview::update();
popclipboundary();
} // end exhyprview::update()

gracias dmitry it doesn't crash there anymore now to more testing