yang686526

text position regression in dd 2.5.1
text position regression in dd 2.5.1
hello,
i'm reading and writing a text entity with a horizontal justification of ktextbottom and a vertical justification of ktextleft.
in previous versions of dwgdirect such as 2.3.1, my code was able to get the text properties from one entity and set them as the properties of another text entity. now with dd 2.5.1, when i look at the original text and the text copy that i construct using the properties, the alignment point is the same, but the position point is different in y. it is now not the same as the original.
my code does all the same things that the example dbfiller::addtextent method does, but in a slightly different order. i saw the thread about when setdatabasedefaults() is is called, but that is not the difference.
has there been some change to the calculation of the position point from the alignment point for bottom left justification?
regan
attached files
hello regan,
there is no problem with calculation text position. dwgdirect calculate its as acad. how you make copy of text (create new and copy properties or use cloning)? posible there is difference in texts properties in case you use first choice. could you attach file with both texts (source and destination)?
best regards,
sergey z.
hello,
the difficult part is that this is a regression test. the destination text was given the same properties before the dd library update, and it was positioned correctly. now after the update, the properties and code to set them are still the same, but the position point is different.
i only see three reasons why this could be:
1. our code has always been wrong, and a fix to the dd libraries has exposed this.
2. there has been a change made to the dd libraries that has created different usage expectations that our code no longer satisfies.
3. there has been a bug introduced in the updated dd library.
the file i attached last post was the source. this current attachment is the destination.
thank you for you assistance,
regan
attached files (111.6 kb, 2 views)

if you do the same as in dbfiller::addtextent, then perhaps you set 'annotative' property to the text.
annotations incorrectly work with text alignment, it is a bug in dd.
unfortunately it was discovered after releasing 2.5.2, so, the fix will be in the next release (not yet sheduled).
you may just not use annotations, if you don't need them.
vladimir
hello,
i have edited the odwriteex example, to hard-code the text properties in the order that i am setting them. i have successfully produced a text entity similar to the example that i have attached.
if i run that example built against my dd_2.3.1 libraries in release /md, the text location is correct. if i run that example built against my dd_2.5.1 libraries in release /md, the text is incorrect, just like the 'destination' sample that i already provided.
attached is my override of the text entity creation method within the dbfiller.cpp file in the odwriteex example.
i have also attached the result files from this testing.
regan
attached files (3.0 kb, 6 views)
(24.0 kb, 2 views)
(70.9 kb, 2 views)

note: the text is not annotative.
hello regan,
thank you for detail report. but i am not able to reproduce your wrong situation. so could you load your file (for example out_oda_2_5_1_bottom_left.dwg ) by odamfcapp (v2.5.1) and run command "adjusttext" (edit\register commands\drxdebug). could you report result about text position?
note. dwgdirect v2.5.2 now available. could you check your situation with this version?
best regards,
sergey z.
very insightful, the text position is fixed by this adjustment in odamfcapp.
what does this mean? is there an additional dd call to be made after text is created?
also, i have noticed dimension and dwf text have some location issues that may be related. could this be a general problem?
thanks,
regan
note: the same problem exists for me in dd 2.5.2.
i don't know much about the odamfcapp debugging tools. what does the fact that it can fix the text location mean for the usage of the dd sdk?
should i be calling another method like oddbtext::adjustalignment after i create a text entity? the documentation note for this function says 'this function is called by dwgdirect when a text entity is closed.'
hello regan,
i you shouldn't call another method like oddbtext::adjustalignment and this method really is called when a text entity is closed.
oddbtext::adjustalignment methods works correctly in case fonts is right. possible the important difference between odamfcapp and your application is fonts searching (oddbhostappservices::findfile()).
best regards,
sergey z.
hi,
the findfile function was a good idea, but mine is almost a copy of the codamfcappapp::findfile example version.
i did find out that the odamfcapp produces different text locations related to unicode support. if i build the odwriteex example app with the changes to dbfiller::addtextent that i mentioned here already, with the 'debug' or 'release' configurations the results are correct. if i build the same code with the 'debug - non unicode' or 'release - non unicode', then i get the incorrect output like out_bottomleft.dwg.
my project is build without unicode character sets, and has worked with dd versions like 2.3.1 which also have unicode support. however, the dd 2.5.1 and 2.5.2 libraries that i have tried seem to break backward compatibility with
the non unicode projects.
i have attached more results from using the modified oda example built with different configurations.
regan
attached files (37.9 kb, 4 views)
(38.3 kb, 3 views)

hello regan,
i see what file out_oda252_releasenu_bottomleft.dwg has text with wrong text position, but i am not able to reproduce wrong behavior with dwgdirect 2.5.2 (release/debug, lib/dll). could you debug writeex example and see dump findfile() calls (in unicode and non unicode configuration)? you need rewrite findfile() method in writeex by next way.
code:
odstring exhostappservices::findfile(const odstring& file,
oddbbasedatabase* pbasedb,
findfilehint hint)
{
// file ?
odstring filename = oddbhostappservices::findfile(file,pbasedb,hint);
// filename ?
return filename;
}
best regards,
sergey z.
hi,
i don't know what you mean about dump findfile. do you want me to call cobject :: dump in the findfile method?
attached is a package of from my dd 251 download, that i am using to reproduce the problem.
the odwriteex project makes use of the common exhostappservices.cpp which i have not changed. i tried redefining the findfile method in this common exhostappservices class, like you showed, but it did not fix the problem.
note: the odamfcapp program does not have the same problem as the modified odwriteex program. the modified odwriteex program works in both debug and release (unicode) configurations.
i hope that you are able to reproduce this.
regan
attached files (38.1 kb, 2 views)

quote:
originally posted by regan
i don't know what you mean about dump findfile. do you want me to call cobject :: dump in the findfile method?
i want to see value of input parameter ("file") and result value of call findfile() ("filename") in both case (right and wrong).
quote:
originally posted by regan
attached is a package of from my dd 251 download, that i am using to reproduce the problem.
i hope that you are able to reproduce this.
i still can not reproduce wrong behavior. i have done as you describe in "reproduction.txt", but i get the right value of text position in result file.
best regards,
sergey z.