【转帖】flaw in recompute dim block
 

flaw in recompute dim block?
flaw in recompute dim block?
attached are 2 autocad drawings, one modified by cad to highlight the dimension in question, and one the original unmodified output. for some reason, from time to time, the location of the dimension lines is... questionable. is this a dimension style issue, or is this an issue with the open design library? i tend to think it's the latter, because as soon as you force a regen of the dimensions anon block, it is placed correctly.
any guidance would be appreciated.
jake
attached files
hello jake,
really there is bug in recompute dimension block in dwgdirect. we will fix it in next release. thank you for report.
best regards,
sergey z.
sergey,
any estimate of when the next maint release will be that will fix this? or any chance of a dif patch that i can apply to the recomputedimblock extension for now?
thanks in advance,
jake
hello jake,
the release is planed start november. also i can send you fix by email (i think within this week).
best regards,
sergey z.
found another "quirk" of the dim block recomputing... not sure if this is the same issue, so just adding it for your opinion.
attached files (16.3 kb, 2 views)

hello jake,
unfortunately it is one more bug.-( thank you for report.
best regards,
sergey z.
sergey,
any update on the first bug?
jake
send me mail to i will replay you with fix both bugs.
best regards,
sergey z.
sergey,
the fix you provided seems to work for aligneddimensions. do you also note the same issues for rotated dimensions? (see attached)
attached files (74.3 kb, 3 views)

hello jake,
i don't find problem with your new file. the previous fix was in common code. so recompute rotated dimensions must work right too.
best regards,
sergey z.
sergey,
specifically i am looking at the dimension extension lines on the rotated dimensions.
dimension layer: "dimension"
space: model space
handle = b2c
associative: no
type: horizontal
1st extension defining point: x= 6.0000 y=-132.0000 z= 0.0000
2nd extension defining point: x= 0.0000 y= -90.0000 z= 0.0000
dimension line defining point: x= 0.0000 y=-126.0000 z= 0.0000
default text position: x= -9.8218 y=-126.0000 z= 0.0000
default text
dimension style: "gfc_capsstandard_1"
dimension style overrides:
dimadec 1
dimclrd byblock
dimclre byblock
dimclrt byblock
dimdec 1
dimtxt 3.0000
annotative: no
the dimension and text are placed proper, but the extension line is inside on one end point, and is opposing the dimension arrow head.
jake
hello jake,
i see this dimension. there is wrong dimension block in attached file (i suppose it was made before fix) but after run recompute dimension it become right.
best regards,
sergey z.
sergey,
this block was made after merging your fix and doing a complete rebuild of the recompute dim block extension, as well as all of my app.
what information do you need from me in order to create a reliable test case on your end?
jake
jake,
the first your files (410b9bce.dwg and 5aecbaf0.dwg) content only rotated
dimensions. are it ok now?
could you build odamfcapp with fix and try command "recompute dimension's block" with your file and see results?
best regards,
sergey z.
a debug build of the odamfcapp reveals this fix does in fact work.
however, at present i am unable to get a release build to work. i am in the process of doing a rebuild all, selecting every configuration of the allexamples solution for msvc 2005. hopefully this will rebuild and populate all relevant lib files.
as of right now, it seems the vc8 projects lack a "static multithread" build option.. =/
is there any reason these configurations were not included?