Index
> Windows > SetWindowLong & WM_CHAR |
| Author |
|
|
LocoDelAssembly 22 Jun 2007, 17:17
As I see all you are doing is creating the windows (edits, auto-checks, etc) and then setting the style with SetWindowLong with almost the same style that you used with CreateWindowEx. If you want to trap the messages you have to change the window procedure of the window, not its style.
Here you have a full example http://win32assembly.online.fr/tut20.html |
|||
22 Jun 2007, 17:17 |
|
|
ManOfSteel 22 Jun 2007, 18:54
Hello,
my program does more than this. This is just an excerpt, hence the "...". And I'm not trying to trap messages at all. It's in my second problem that I'm trying to trap key presses in a specific edit box. In the first problem, I'm only trying to modify the controls styles. I must reuse the same styles and add the newer ones because the old styles get overwritten when using SetWindowLong, AFAIK. These are two separate problems. As I said: Quote: I have two problems |
|||
|
22 Jun 2007, 18:54 |
|
|
LocoDelAssembly 22 Jun 2007, 19:11
Quote:
How do you propose to get the key presses without getting the window messages? If you look at the example you will found exactly what you want (except that the new handler forbids non hex keys while you just want to get the keys). Sorry for the misunderstanding, I don't know why your first problem doesn't work. Try with UpdateWindow passing as paramenter the hwnd of the control but I bet it will fix only the checkbox, no the editbox problem. PS: Instead of changing the Editbox style try with EM_SETPASSWORDCHAR that seems it will do what you need. |
|||
|
22 Jun 2007, 19:11 |
|
|
handyman 23 Jun 2007, 05:40
Some thoughts here:
for problem 1 autocheckbox: You may want to check out the 'CheckDlgButton' function and associated functions listed in the Win32 programmer's reference. for problem 2: According to definition WM_CHAR is only sent to the window that has the current keyboard focus. So, does the edit window have the current keyboard focus? |
|||
|
23 Jun 2007, 05:40 |
|
|
ManOfSteel 23 Jun 2007, 06:28
LocoDelAssembly,
Quote: How do you propose to get the key presses without getting the window messages? If you look at the example you will found exactly what you want (except that the new handler forbids non hex keys while you just want to get the keys). Yes, I read it. Thank you. Iczelion's tutorials are always the best. The "I'm not trying to trap messages at all" was for my first problem actually. Of course I'll have to read Window's messages, you're right. So I'm sorry too for any confusion. Quote: Try with UpdateWindow passing as paramenter the hwnd of the control but I bet it will fix only the checkbox, no the editbox problem. It didn't work with neither of them. Quote: PS: Instead of changing the Editbox style try with EM_SETPASSWORDCHAR that seems it will do what you need. It didn't work either. What's even more incredible is that I tried creating the editbox using the ES_PASSWORD style and it showed the asterisks, but when I used EM_SETPASSWORDCHAR with no parameter it didn't reset to normal: Code: invoke SendMessage,[hKeyEdit],EM_SETPASSWORDCHAR,0,0 handyman, Quote: According to definition WM_CHAR is only sent to the window that has the current keyboard focus. It is set with SetFocus if that's what you're asking. Anyway, that problem should be resolved with the code LocoDelAssembly linked to. |
|||
|
23 Jun 2007, 06:28 |
|
|
kohlrak 23 Jun 2007, 07:20
Quote: It didn't work with neither of them. Dosn't surprise me. One thing i've learned when messing around with things is that you should never trust WM_PAINT. Though, i'm sure some one will beg to differ, my personal experience is that it's a little unpredictable. Same with WM_MOUSEMOVE. I tried once to check if my mouse moved or not, and i found out that even when my mouse isn't moving, for some reson it sends the message anyway. Another thing that i noticed is that you're doing things with +. I've seen alot of people do that and i've found that if you do that you can present the problem i'll illistrate below. FLAG1 = 1 FLAG2 = 2 FLAG1+FLAG2=3 (Works as you want.) FLAG1+FLAG1=FLAG2 (UH OH) FLAG1 or FLAG2 = 3 (Works as you want.) FLAG1 or FLAG1 = 1 (What you want) I don't know what the constants are, but you could have a few things going haywire there because some of your flags (maybe even ones already attributed to the window) may have binary values that colide, making them a hire number. EDIT: I've seen this kind of thing alot. And i've found it to be one of the biggest problems to some one who accidentally puts the same flag twice, because everything but that extra flag works. Chances are, doing this will give you the problem sooner or later, but in many situations, you're noticing you already have that style in the window and don't want to add it so doing this will be just like oring them together, but if you don't or them, a situation like this could occure. |
|||
|
23 Jun 2007, 07:20 |
|
|
ManOfSteel 23 Jun 2007, 09:27
Correction: sending the EM_SETPASSWORDCHAR message works perfectly. I was just doing the most stupid mistake after creating the editbox:
Code: invoke CreateWindowEx,WS_EX_OVERLAPPEDWINDOW,'EDIT',0,WS_CHILD+WS_VISIBLE+WS_BORDER+ES_LEFT+ES_AUTOHSCROLL+ES_AUTOVSCROLL+WS_TABSTOP,10,38,200,22,[hwnd],KeyEditID,[wc.hInstance],0 invoke SetFocus,eax mov [hKeyEdit],eax No wonder I had hard time using this "handle". One more thing, the changes only take place when I click on the editbox, so I had to add a second SetFocus right after sending the EM_SETPASSWORDCHAR message. Is that normal? |
|||
|
23 Jun 2007, 09:27 |
|
|
kohlrak 23 Jun 2007, 09:36
I never messed with it much, but it wouldn't surprise me. I've seen lots of programs having to resort to such patchwork before. The reson could be the fact that when a window (not neccessarily children) goes out of focus, it's because another window comes ontop of it. Usually those windows don't update much, so windows probably has it in implimentation that windows out of focus don't get messages immediately or at all. It might set the priority low and it's sending initialization messages (WM_SIZE, WM_PAINT, etc) to it before your message, and if it's priority's lower, it might be slowly sending each message. For that reason, i (this is purely preferencial and probably less efficient than patchwork, but i just can't stand patching) would either use sub-classing or super-classing for password input if i needed it from the start, but if i was going to use password input, i'd probably just send the message cause it'll come into focus when the user clicks the box to put input in it.
|
|||
|
23 Jun 2007, 09:36 |
|
|
ManOfSteel 23 Jun 2007, 12:54
kohlrak,
In general you only use a few flags at a time. It should be quite easy to notice that you retyped the same flag twice and see inconsistencies between what you wrote and what is displayed. But you're right it's a more proper habit to use "or" instead of "+". |
|||
|
23 Jun 2007, 12:54 |
|
|
kohlrak 23 Jun 2007, 13:19
Quite easy, but so is noticing you're using the wrong handle. Accidents happen. I'm not going to be one of them. XD
|
|||
|
23 Jun 2007, 13:19 |
|
< Last Thread | Next Thread > |
Forum Rules:
|