yang686526

dimension bug i think.
dimension bug i think.
hi dwgdirect'ers,
i have a drawing (attached) that has a weird side effect when i call upgrade open and downgradeopen on a dimension.
what basically happens is if i just simply call explode on the dimension, all is good, and looks perfectly correct. however if i call upgradeopen/downgradeopen before the explode, the dimension's style is totaly different?
what should i do to stop this, or is this a bug?
cheers
jason
attached files
are you sure you call only upgrade/downgrade open and not modify the dimension?
if dimension is modified its block is recalculated.
dd performs it incorrectly in this case (do not honor dimtsz variable).
btw, if you change color of a dimension from your file in autocad the block is recalculated too and appearence changes but not so significantly.
sergey slezkin
i call the upgradeopen so i can call measurement property of the dimension, else it throws an exception on some drawings, which i assume is recalculting the dimension block. however i did not want it to change how it is displayed, this still seems like some kind of bug?
ie : i do the following :
dim->upgradeopen();
dim->measurement();
dim->downgradeopen();
i would think that the display of the dimension should not change in the process of these three calls, or am i missing something?
thanx again in advance,
jason
ps. keep up the great work, compared to the dwf toolkit discussion groups, you guys rock in support, those guys are just straight useless.
where are 2 oddbdimension functions returning measurement value:
getmeasurement() const
this one simply returns stored in dimension value.
measurement()
this one is non-const. if cached in dimension measurement value is invalid (<0) than it's recalculated, cache is updated. this also may cause some other data be adjusted. this requires the dimesion entity being opened for write and causes dimension block recalculation.
if you use const getmeasurement() method you'll prevent block recomputing but you'll get "-1" value in this case.
if this does not work for you, you have to wait for the fix. dimension blocks recomputing can be turned off but together with recalculating of measurement value.
sergey slezkin
last edited by mmuratov; 24th march 2006 at 04:57 amfff">.

sergey,
i do the following in my code
try {
pdim->setmeasurement(dimptr->measurement());
} catch( oderror &e ) {
std::string serrdesc =
cdwgio::m_dwgsvcs.geterrordescription(e.code()).c_ str();
delete pdim;
return null;
}
and calling the ->measurement throws an exception "not opened for write". how i read your previous response, calling measurement() should just block the recompute, is this correct ?
anyhow, all i really would like to know is if this is a bug( or calssified as one ) and if so when will it be fixed, else if it is not a bug, what is the best work around this problem ?
cheers and thanx again for your help
jason
in my previous post i made a typo (i edited the post already):
if you call getmeasurement() the block will not be recomputed but you'll get "-1" instead of actual value.
usually real value is stored in dimension but in your specific case -1 is stored where. thats why measurement() calculates it and updates dimension causing block recomputing.
recomputing block as a result of measurement() call in your case (-1 is stored in dimension instead of actual value) and thowing exception if entity was not open for write is correct behaviour.
incorrect block recomputing is dd bug which will be fixed in next release/update (not scheduled yet).
sergey slezkin
thank you
cheers
jason
quote:
originally posted by sergey slezkin
in my previous post i made a typo (i edited the post already):
if you call getmeasurement() the block will not be recomputed but you'll get "-1" instead of actual value.
usually real value is stored in dimension but in your specific case -1 is stored where. thats why measurement() calculates it and updates dimension causing block recomputing.
recomputing block as a result of measurement() call in your case (-1 is stored in dimension instead of actual value) and thowing exception if entity was not open for write is correct behaviour.
incorrect block recomputing is dd bug which will be fixed in next release/update (not scheduled yet).