I'm trying to incorporate something like the character picker in the Windows Character Map utility in my code. (This is from Win2K Pro.)
Can anyone take an educated guess as to what kind of control this might be? I'm referring to the large grid of characters in the scrollable box.
I can see several possibilities:
- A "list view" control, but with character glyphs instead of images (don't know if this is possible or not)
- A "pager control"
It's obviously some kind of custom control, but what's it based on?
Is it an "owner draw" control? Does the owner have to draw the grid lines and such?
How about a collection of small windows within the larger window?
I extracted the list of functions this little program uses, and it's pretty long (202 functions), so it might be a bit complicated ...
Quote from: NoCforMe on October 03, 2011, 09:27:18 PMIs it an "owner draw" control? Does the owner have to draw the grid lines and such?
yes - see attachment for a quick example
qWord
So it looks as if drawing the grid of characters is pretty easy. But what about turning the grid into a control? Seems to me it would be a minor nightmare to try to track mouse clicks on the grid manually.
How about creating little windows, one for each character? That way you'd be able to let Windows take of much of the window management.
Or are there other ways to do this?
all you have to do is handle the WM_LBUTTONDOWN message
the lParam high and low word give you cursor position
But that'll involve a lot of tedious work to determine where the user clicked. Especially since the control is scrollable. Think about it: you'd have to maintain an array of bounds, and update it every time the control gets scrolled.
I find it hard to believe there isn't a better way to do this.
Make it a popup window big enough to hold the complete grid, so that you don't have to scroll. The rest is extremely easy: Simply divide the width by MouseX and the height by MouseY.
Even scrolling is not a big deal - just add a Y offset.
the X and Y offset isn't that difficult at all - you are likely to maintain those values, anyways
however, you can put it in its' own window, as Jochen suggested to remove the offset
it does not have to be a pop-up, though - it could just be a borderless child window
after the offset is taken care of, when you divide the cursor X or Y position by the cell width or height....
if the remainder is 0, then they are on the one of the dividing lines - you could just ignore that case
In the attachment an extended example, showing all unicode char. from 0-0xffff. A left click in a cell opens a message box to show the unicode number.
Looks cute, qWord, but Avira doesnt' like your executable. If I assemble it myself, it is 4096 bytes instead of 5632, and no complaints from Avira ::)
uh oh
the one i got from qWord is only 4 kb and no problem
Quote from: jj2007 on October 04, 2011, 07:29:29 PM
Looks cute, qWord, but Avira doesnt' like your executable. If I assemble it myself, it is 4096 bytes instead of 5632, and no complaints from Avira ::)
propably the relocation data, which
link 10.x adds ... hopefully :bg
However, COMODO likes my software.
Avira says it's TR/ATRAPS.Gen, but Olly says mine and your version look pretty much the same...
a view with the CFF explores shows, that 500 bytes of relocation data are added - probably this is the problem for the AV. In the attachment the /FIXED executable.
Here are your and my versions together. For Olly, they look identically now - my first attempt was made with JWasm and showed the usual minor differences.
two main difference:
- in your executable are no relocation data
- in my exe. the import table seem to have its own, additional read-only-section (.rdata)
using the following comand line, I get also a 4K exe :bg
/SUBSYSTEM:WINDOWS /MERGE:.rdata=.data /FIXED /RELEASE ...
Quote from: qWord on October 04, 2011, 08:10:38 PM
- in my exe. the import table seem to have its own, additional read-only-section (.rdata)
I wonder if the new linker tries to protect the import table from attacks... makes no sense otherwise.
Quote from: jj2007 on October 04, 2011, 08:45:42 PM
I wonder if the new linker tries to protect the import table from attacks... makes no sense otherwise.
maybe a protection, but a weak one ...
Lausig indeed :toothy