yang686526

strange behavior of the detach function on oddbdimstyletable
strange behavior of the detach function on oddbdimstyletablerecordptr
i am using dd2.1.1 for net2003 in my application. now there is a strange problem: when i export some dimensions to dwg, if i called the detach function on the oddbdimstyletablerecordptr after having exported the dimensions to dwg, then the result is good. but if i didn't call the detach function on the oddbdimstyletablerecordptr, the result is not good. here attached two dwg files for your reference: undetach.dwg is the result file without calling detach on oddbdimstyletablerecordptr, detached.dwg is the result file with calling detach on oddbdimstyletablerecordptr.
what does cause this strange behavior? how to fix this?
any help appreciated
attached files
calling detach() is incorrect. you should call pointer.release() or pointer = 0;
what do you mean by good or bad? do you create dimension blocks yourself?
sergey slezkin
if the dwg file is mostly like to my original file, it is good, otherwise it is bad. i always create the dimension block for the dimension in my application.
in fact, i always use the smart pointer in my application. so in my old code ( not call the detach function on the smart pointer of the dimstyle table record ), when out of the my export dimension function, the release has been called autocatically by the environment, but the result is not good.
actually, for this case, dd for vc6 works fine, but after i upgraded dd to net2003 2.1.1, the strange phenomena came up. i tried to fix this stange issue, and find that the call on detach can make the result good. as mentioned in my prior post, if i didn't call detach on the smart point of the dimstyle table record, the result is not good.
so, the issue is that what dd does in the detach function causes this difference?
dd performs dimension blocks recomputing if dimension entity or its dimension style is modified.
if resulting dimension block looks "incorrect" it means that dimension entity or dimension style data were set incorrectly - they do not match desired appearence. it's very easy to check if this is the case:
- open drawing in autocad. dimension blocks saved to file are displayed.
- select the dimension (or all of them) and change some property (color for example)
at this moment autocad will recalculate dimension block according to dimension entity and its style data.
if dimension appearance changes (except color) it means that dimension data/style and block did not match each other.
if dd calculates the block differently from autocad that means a bug in dd.
both your example files are not ok: select all dimensions in ac and change color for 255 - in both files acad recomputes the blocks.
some of radial ang angular dimension blocks in your sample are recomputed by dd incorrectly. we'll fix it.
btw, if you want to prevent recomputing of dimension blocks completely you can use dummyrecomputedimblock module instead of standard recomputedimblock. dummy module does perform recomputing.
sergey slezkin
some of radial ang angular dimension blocks in your sample are recomputed by dd incorrectly. we'll fix it.
for these issues, they have been fixed in the latest version 2.2.0 library?
this was not fixed in 2.2
sergey slezkin
if i rebuild the recomputedimblock dummy module, the resulting drx file does not contain any version info. this makes it difficult for my msi installation to correctly replace the standard recomputedimblock.drx on my customers' computers.
to build the dummyrecomputedimblock module, i rebuild the solution under the projectfiles\win32\msvc2003\extensions\dummyrecomp utedimblock_dll folder.
am i doing something wrong that causes the version information to be lost?
--------------------------
thanks,
bill
it appears that dummyrecomputedimblock.rc is not included into vc2003 and vc8 projects. please add it to the project.
sergey slezkin