Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
0 user currently in Programming. | 3 guests
Acmlm's Board - I2 Archive - Programming - Earth to keyboard... come in keyboard...
  
User name:
Password:
Reply:
 

UserPost
HyperLamer
Posts: 5397/8210
Ah, yes, it's easy enough to stop the duplicating once I actually read the article a little closer. Just need to treat press and release separately (bit 31 of lParam). Still beeps though.
sloat
Posts: 71/85
It duplicates because it calls the callback separately for keydown and keyup events. It beeps because dialog windows aren't supposed to receive keyboard input like that. I don't know how to get rid of that myself, so good luck.
HyperLamer
Posts: 5374/8210
Heh, I thought that was for global hooks.

BTW, SetBkMode did the trick for the lines.

[edit] Eh, problem. With the keyboard hook, it duplicates every keypress. And it still beeps!
sloat
Posts: 70/85
GetWindowThreadProcessId to get the thread id of the window, SetWindowsHookEx and use the WH_KEYBOARD hook with the KeyboardProc callback. And don't forget CallNextHookEx and UnhookWindowsHookEx.

Seems daunting, but it isn't really. This may help as well.
HyperLamer
Posts: 5356/8210
I don't think I've ever heard of a keyboard hook that works on all versions and doesn't trigger from other windows. What function should I be looking at?
sloat
Posts: 69/85
Originally posted by HyperHacker
But if I use a keyboard hook, it'll respond to keys pressed in other windows, and will only work in XP.


That's not entirely correct. The low-level hooks can only be used on NT based systems, and they are also system-wide hooks only. A regular keyboard hook can be used across all Win32 platforms afaik, and can also be applied to a single thread. And because the thread is in the same process, the hook callback and be in the code and doesn't need its own dll.
HyperLamer
Posts: 5346/8210
No but A, it shouldn't be necessary, and B, I would have to 'mimic' any control I add like that. Static is easy, some others aren't.

Small scrollbar problem. Whatever I set the Page value to, the maximum goes down by. Say the bar has a max of 10 and a Page of 2, it won't go past position 8. Setting Page to 0 fixes this but makes it that I can't click the bar area itself to scroll quickly.
beneficii
Posts: 229/567
Originally posted by HyperHacker
But if I use a keyboard hook, it'll respond to keys pressed in other windows, and will only work in XP.


It's not that hard to draw text onto a screen, is it?
HyperLamer
Posts: 5327/8210
But if I use a keyboard hook, it'll respond to keys pressed in other windows, and will only work in XP.
sloat
Posts: 66/85
Originally posted by HyperHacker
I really can't imagine having to not use any controls at all just to get keyboard input. There must be some focus issue I'm missing here.


SetFocus doesn't work with modal dialogs because the default dialog procedure sends the focus to the first control or something like that.

I don't think drawing fake controlls will work out very well. The best way to do it may be to set up a Keyboard Hook with SetWindowsHookEx. It may be the only way, in fact. I don't think subclassing each control and forwarding the messages would get anywhere.

Cellar Dweller
Posts: 232/269
Regarding the gaps in the line, you may want to check out the SetBkMode function. You don't need an invisible brush to make the gaps in the line invisible, but if you need one for some other use, use GetStockObject.
HyperLamer
Posts: 5323/8210
I really can't imagine having to not use any controls at all just to get keyboard input. There must be some focus issue I'm missing here.

Also how do I create an invisible brush? A pen I can do but MSDN doesn't seem to have any such information on brushes. I'm trying to draw a dashed line, so I created a dashed pen for it, but in between the dashes it draws white where I don't want it to draw at all. I assume it's using the default brush for this...
beneficii
Posts: 220/567
Originally posted by HyperHacker
By static I mean just plain Static controls. I've tried everything I could think of involving SetFocus. They all use the same message handler anyway.


Hmmm. You could try drawing the text directly onto the dialog itself. I don't know exactly how to do it, since I never did it before, but I know a source that can teach you:

http://www.winprog.org/tutorial/fonts.html

Regarding using the same message handler, not necessarily. If, say, a combobox has the focus, then the WndProc won't get WM_KEYDOWN messages during that period.
HyperLamer
Posts: 5296/8210
By static I mean just plain Static controls. I've tried everything I could think of involving SetFocus. They all use the same message handler anyway.
sloat
Posts: 65/85
I think adding any child window (except maybe static) stops the system from sending keyboard messages to a dialog. The only way I could ever get around this was with a keyboard hook.

Mouse messages are not sent to multiple windows by default. If you want to move the mouse over a child window and have the parent know about it, check out the SetCapture function.
beneficii
Posts: 216/567
Originally posted by HyperHacker
Well I created this dialog from a resource, with nothing on it, and it worked fine. Stuck in a child window (also nothing on it, but with horizontal and vertical scrollbars) and all was well. After adding some static textboxes to the main dialog, though, the windows no longer recieve WM_KEYDOWN messages. Plus even when they did, it would beep whenever I pressed a key... how do I get the keys working again and not beeping?

[edit] Also, it seems only the child window is getting WM_MOUSEMOVE messages... I don't have any need for the parent to get them yet though.


EDIT 2: By static textboxes, do you mean edit controls whose text is unchangeable?

My best guess is that you want to make sure to set focus to the parent dialog, because I don't think that WM_KEYDOWN gets sent if the focus is on an edit control.

Every time a text box comes into focus (gotten from the messages), do:

SetFocus(dialoghwnd);

That should prevent the edit boxes from staying in focus.

EDIT: I had this similar problem in my SMB3 editor, with the combobox retaining focus and preventing my WM_KEYDOWN messages from reaching the WndProc, which prevented the user from scrolling the map box, so I made so that everytime the combobox closed up, the parent window would get the focus (i.e. I wrote the SetFocus(hwnd) under CBN_CLOSEUP).
HyperLamer
Posts: 5293/8210
Well I created this dialog from a resource, with nothing on it, and it worked fine. Stuck in a child window (also nothing on it, but with horizontal and vertical scrollbars) and all was well. After adding some static textboxes to the main dialog, though, the windows no longer recieve WM_KEYDOWN messages. Plus even when they did, it would beep whenever I pressed a key... how do I get the keys working again and not beeping?

[edit] Also, it seems only the child window is getting WM_MOUSEMOVE messages... I don't have any need for the parent to get them yet though.
Acmlm's Board - I2 Archive - Programming - Earth to keyboard... come in keyboard...


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.006 seconds.