几何尺寸与公差论坛------致力于产品几何量公差标准GD&T (GDT:ASME)|New GPS(ISO)研究/CAD设计/CAM加工/CMM测量  


返回   几何尺寸与公差论坛------致力于产品几何量公差标准GD&T (GDT:ASME)|New GPS(ISO)研究/CAD设计/CAM加工/CMM测量 » 仿射空间:CAX软件开发(三)二次开发与程序设计 » CAD二次开发 » AutoCAD二次开发 » DirectDWG
用户名
密码
注册 帮助 会员 日历 银行 搜索 今日新帖 标记论坛为已读


 
 
主题工具 搜索本主题 显示模式
旧 2009-05-06, 08:52 PM   #1
yang686526
高级会员
 
注册日期: 06-11
帖子: 14579
精华: 1
现金: 224494 标准币
资产: 234494 标准币
yang686526 向着好的方向发展
默认 【转帖】odgsbasemodelonmodified9odgidrawable pmodified, oddbstub

odgsbasemodel:nmodified(odgidrawable* pmodified, oddbstub*
odgsbasemodel:nmodified(odgidrawable* pmodified, oddbstub* parentid)
what does this function do? how is it implemented? can i get the source for this function?
it doesn't actually crash here... however if i avoid invalidating the gs cache then i don't get my crash in device::update where my call stack has the spatial index dll at the top.
nearer!
wvk,
thanks for the code.
commenting this line:
pcache->invalidate(pparentcache, 0,0);
alleviates my crash. so...now what is the odgscache::invalidate doing? i'm assuming its using polymorphism to call the odgsentitynode::invalidate. somehow... this code does something different (than an add) which causes the device::update to crash.
tyler
i've noticed that the extents call on the odgientitynode returns a different value than that of the getgeomextents call on the odgidrawable. i'm wondering if that is somehow fouling up the spatialindexing (each odgientitynode is spatialindexed). any idea how they would become out of synch... or how to synchronize them?
wvk,
after doing some further research... im pretty sure the crash occurs deep in the odgsbasevectorizedevice::update call. im sure that it has to do with spatialindexing of the odgsentitynode that i've called invalidate on.
questions:
1. does the odgsentitynode::invalidate just set a flag? or does it do some calculation?
2. what is the difference between the odgsnode extents and the odgidrawable extents? is the odgsnode extents calculated in the update?
3. can i get the odgsbasevectorizedevice::update code?
vladimir,
i've done more investigation into this issue.
it consistently reproduces itself in dd_spatialindex.2.04_8. dll. it appears to get caught in either an infinite loop or a recursive function that allocates 12 bytes per iteration. im able to set a break point in _heap_alloc_dbg, and by watching the call stack i see two function addresses toggle back and forth.
i've tried everything i can think of as a work around using the odgsnode and odgidrawable ptrs from the onmodified function...but can't seem to hack around this issue.
i'd really appreciate the odgsbasevectorizedevice::update source and the spatial indexing dll source so that i can trace the issue in code. let me know if you can provide them to me... or who i should be asking this for.
thanks,
tyler
tillerstarredwards
yang686526离线中   回复时引用此帖
GDT自动化论坛(仅游客可见)
 


主题工具 搜索本主题
搜索本主题:

高级搜索
显示模式

发帖规则
不可以发表新主题
不可以回复主题
不可以上传附件
不可以编辑您的帖子

vB 代码开启
[IMG]代码开启
HTML代码关闭

相似的主题
主题 主题发起者 论坛 回复 最后发表
【转帖】from oddbstub to layer number yang686526 DirectDWG 0 2009-05-05 11:08 AM


所有的时间均为北京时间。 现在的时间是 10:51 PM.


于2004年创办,几何尺寸与公差论坛"致力于产品几何量公差标准GD&T | GPS研究/CAD设计/CAM加工/CMM测量"。免责声明:论坛严禁发布色情反动言论及有关违反国家法律法规内容!情节严重者提供其IP,并配合相关部门进行严厉查处,若內容有涉及侵权,请立即联系我们QQ:44671734。注:此论坛须管理员验证方可发帖。
沪ICP备06057009号-2
更多