EDN Admin
Well-known member
Hello all. Ive been reading a lot of stuff about the DrawString and MeasureString methods and their "idiosyncrasies", and Ive been wrestling with my own version of these issues.
Im using Visual Studio 2010 with c++/cli, on Windows XP. Im trying to develop a custom combo box from the ground up, inheriting from the Control class. Possibly not the most efficient approach, but its been educational and Ive come this far; Id
like to try to get it to work.
I resorted to tapping into the Windows API for the caret, and Ive been calculating its position using a trick Ive seen posted in a few places - measuring the string by drawing it onto a bitmap using DrawString, and checking the bits. This works fine
as long as the caret is at the end of the string. Right on the money every time. The problem arises when the caret in positioned mid-string, and in fact the effect can be observed while Im typing in my combo box. GDI+, apparently in its
efforts to remain device independent, does some funny things with string rendering. Specifically, the string "ABCDEF" may measure a certain number of pixels when rendered on its own, but when rendered as part of a larger string, say "ABCDEF FEDCBA",
the "ABCDEF" portion of the string no longer measures the same number of pixels as it did on its own. To put it differently, portions of the string measure differently depending on their context. Blows my measure-the-string-to-find-the-caret-position
method out of the water.
All this is to say, what a headache. The real question is: are there other, non-obsolete alternatives the DrawString and MeasureString methods? Im not worried about hardware independence - Im trying to design my class around that.
Thanks in advance to anyone taking the time to reply.
-Jeremy
<br/>
View the full article
Im using Visual Studio 2010 with c++/cli, on Windows XP. Im trying to develop a custom combo box from the ground up, inheriting from the Control class. Possibly not the most efficient approach, but its been educational and Ive come this far; Id
like to try to get it to work.
I resorted to tapping into the Windows API for the caret, and Ive been calculating its position using a trick Ive seen posted in a few places - measuring the string by drawing it onto a bitmap using DrawString, and checking the bits. This works fine
as long as the caret is at the end of the string. Right on the money every time. The problem arises when the caret in positioned mid-string, and in fact the effect can be observed while Im typing in my combo box. GDI+, apparently in its
efforts to remain device independent, does some funny things with string rendering. Specifically, the string "ABCDEF" may measure a certain number of pixels when rendered on its own, but when rendered as part of a larger string, say "ABCDEF FEDCBA",
the "ABCDEF" portion of the string no longer measures the same number of pixels as it did on its own. To put it differently, portions of the string measure differently depending on their context. Blows my measure-the-string-to-find-the-caret-position
method out of the water.
All this is to say, what a headache. The real question is: are there other, non-obsolete alternatives the DrawString and MeasureString methods? Im not worried about hardware independence - Im trying to design my class around that.
Thanks in advance to anyone taking the time to reply.
-Jeremy
<br/>
View the full article