UI test of new coloured buttons and a test piece for entering passwords

[hutch--]

This is the second version, it uses the coloured buttons so you are free from Windows default colour schemes, it uses a couple of the WM_CTLCOLOR messages to control the colour  of the edit control and static control and it does a few of the things that make hacking a password entry window a bit harder to do. Apart from the testing of the coloured buttons, it tries to do some basic useful things as well.

[jj2007]

Did you notice the pling! a second after you hit Return? That's the reason why I use WM_CHAR

My version attached, for comparison. See next post.

[hutch--]

It does not work correctly.

### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###
### stack corruption? DefWindowProcW: retaddr 7766438Bh is above the code segment ###


And a MessageBox ->  Could not open icon.ico for Fileread$ etc.

I will give WM_CHAR a try.

Slightly later : Works fine. I have all of the Windows noises turned off so if the WM_KEYDOWN triggered a noise, I did not hear it.

[jj2007]

Thanks for the feedback. My stack macro was switched on, I've corrected that (apparently your callbacks sit in a different range), and the exe expected your icon in the same folder. I've put it in the resources, so it should work now.

So you have all Windows noises turned off centrally? Mine are on, and I fought quite a while with the WM_KEYDOWN noise. A real nuisance

[hutch--]

Yes,

second one works OK. Is it 32 bit code ?

[jj2007]

Yes it is, but I suppose 64-bit Windows behaves the same. That bing! drove me crazy.

[hutch--]

The example was in fact a 64 bit MASM test piece for coloured buttons which by the way seem to work correctly within their design parameters. If I was designing a foolproof password entry dialog or window, it would not be be published as there are too many thing that I don't want to share. Developing the 3 types of buttons I have close to finished is like picking fly sh*t out of pepper and distractions just waste my time when I face a workload that sits like Mount Everest in front of me.