News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Win32 My First Window

Started by tda0626, April 24, 2024, 11:05:19 AM

Previous topic - Next topic

jj2007

Quote from: NoCforMe on May 06, 2024, 06:49:50 AMSure:
    XOR  ECX, ECX
    DIV  ECX

Why is there no smiley function in this forum?  :biggrin:

Quote from: tda0626 on May 06, 2024, 07:58:16 AMhow would you handle the C Break statement in assembler?

No need for action - there is no fall through in assembly. That "break;" is a horrible C abomination.

NoCforMe

There's some controversy about this (see another thread somewhere here on this topic).
However, if you read the documentation for the WM_VSCROLL message, it says:
QuoteIf an application processes this message, it should return zero.
Therefore, the right thing to do in that handler would be to return zero if you handle the message, meaning that you want no more processing done on it.
Otherwise, jump to the DefWindowProc() function.
Assembly language programming should be fun. That's why I do it.

NoCforMe

Quote from: jj2007 on May 06, 2024, 07:59:39 AM
Quote from: NoCforMe on May 06, 2024, 06:49:50 AMSure:
    XOR  ECX, ECX
    DIV  ECX

Why is there no smiley function in this forum?  :biggrin:
You know full well, Jochen, that I abhor the use of those stupid smileys and emoticons.
All they do is dumb down people's comprehension.
If someone's too dense to pick up on irony, that's their problem.
Assembly language programming should be fun. That's why I do it.

tda0626

Quote from: jj2007 on May 06, 2024, 07:59:39 AMNo need for action - there is no fall through in assembly. That "break;" is a horrible C abomination.


Got it.


Quote from: NoCforMe on May 06, 2024, 08:03:11 AMThere's some controversy about this (see another thread somewhere here on this topic).
However, if you read the documentation for the WM_VSCROLL message, it says:
QuoteIf an application processes this message, it should return zero.
Therefore, the right thing to do in that handler would be to return zero if you handle the message, meaning that you want no more processing done on it.
Otherwise, jump to the DefWindowProc() function.

Petzold had a separate switch case to process wParam that is triggered with WM_VSCROLL, which later on returns 0.

tda0626

I am doing the scroll bar part of sysmets1 program from Petzold's book and added my code to sysmets1. When I run it, the scrollbar is shown along with the thumb. However, it does not do squat. It will move the thumb up and down but does not affect the client window contents. Also when I reach verttop the thumb wraps around to vertbottom but not the other way around.

Also, how would I go about debugging these window messages? I know like the bare minimum basics when using a debugger.


My source is attached along with the inc.

Tim

jj2007

Quote from: NoCforMe on May 06, 2024, 08:05:11 AMYou know full well, Jochen, that I abhor the use of those stupid smileys and emoticons

You are a free citizen in a free land, pardon: Internet. Don't use them if you don't like them.

P.S.: Try to sue SMF for forcing 39 stupid smileys and emoticons on you :cool:

NoCforMe

One thing I noticed is that you created your window without the WS_VSCROLL style. (I'm looking at his SYSMETS2 program, which includes that style for the window.) But you say you see a scrollbar ...
invoke CreateWindowExA,\
WS_EX_LEFT,\
offset szAppName,\
offset win_caption,\
WS_OVERLAPPEDWINDOW  OR WS_VSCROLL,\
CW_USEDEFAULT,\
CW_USEDEFAULT,\
CW_USEDEFAULT,\
CW_USEDEFAULT,\
0,\
NULL,\
hinstance,\
NULL
Assembly language programming should be fun. That's why I do it.

NoCforMe

Couple little details:
o INVOKE doesn't need those stupid line-continuation ("\") characters, so you can lose those.
o WS_EX_LEFT is one of those stupid style constants that = 0, so does nothing, so you can lose that as well.
Assembly language programming should be fun. That's why I do it.

jj2007

Quote from: tda0626 on May 06, 2024, 09:35:49 AMAlso, how would I go about debugging these window messages? I know like the bare minimum basics when using a debugger.

Debugging the WndProc is close to impossible with a debugger - too much interaction between the debug window and the WndProc itself. Try the attached executable, built on your minimally modified source. You won't see the following messages because they appear too often:
WM_MOUSEMOVE, WM_NCHITTEST, WM_SETCURSOR, WM_GETICON, WM_NCMOUSEMOVE, WM_MOVING, WM_ENTERIDLE

NoCforMe

Quote from: tda0626 on May 06, 2024, 09:35:49 AMAlso, how would I go about debugging these window messages? I know like the bare minimum basics when using a debugger.
As JJ pointed out, a debugger is of little help here. (There are so many messages flying around that if you set a breakpoint on a window proc, you'll be there forever hitting F9 until you maybe see the message you're looking for.)

However, I have a tool I created that might be of use to you. It's called LogBuddy, and it captures messages went to a window (among other things) and displays the messages and their contents in a logging window. You can filter messages to narrow down what you're looking at.

If this sounds interesting to you I'll be happy to post the package here. It involves a little bit of adding stuff to your program to be logged, not too much, plus there's a DLL. Probably 15 minutes of work before you can see what messages are coming into your proc.
Assembly language programming should be fun. That's why I do it.

sinsi

Possibly overkill, but VS 2022 has a tool called SpyXX which lets you view all sorts of info about a window including messages.
Mine lives in C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools

NoCforMe

Well, I'd like it if the OP is curious enough about my utility to try it. I've been hoping for unsuspecting victims trial users for it.
Assembly language programming should be fun. That's why I do it.

jj2007

Quote from: sinsi on May 06, 2024, 12:49:04 PMVS 2022 has a tool called SpyXX

Unfortunately non on my machine. There is a SOF debate about that.

I am quite used to deb, which produces this kind of output (you may note gaps in the numbering, many messages are filtered):

        #  wParam  lParam      uMsg
msg    1  00000000 0019FA9C    WM_GETMINMAXINFO
msg    2  00000000 0019FA90    WM_NCCREATE
msg    3  00000000 0019FA7C    WM_NCCALCSIZE
msg    4  00000000 0019FA90    WM_CREATE
msg    5  00000000 0019F6EC    WM_WINDOWPOSCHANGING
msg    6  00000001 0019F6C4    WM_NCCALCSIZE
msg    7  00000000 0019F6EC    WM_WINDOWPOSCHANGED
msg    8  00000000 02310237    WM_SIZE
msg    12  00000001 00000000  WM_SHOWWINDOW
msg    13  00000000 0019FEC4  WM_WINDOWPOSCHANGING
msg    14  00000000 0019FEC4  WM_WINDOWPOSCHANGING
msg    15  00000001 00001C40  WM_ACTIVATEAPP
msg    16  00000001 00000000  WM_NCACTIVATE
msg    17  00000001 00000000  WM_ACTIVATE
msg    18  00000001 C000000F  WM_IME_SETCONTEXT
msg    19  00000002 00000000  WM_IME_NOTIFY
msg    20  00000000 00000000  WM_SETFOCUS
msg    21  00000001 00000000  WM_NCPAINT
msg    22  6C01156C 00000000  WM_ERASEBKGND
msg    23  00000000 0019FEC4  WM_WINDOWPOSCHANGED
msg    24  00000000 02310237  WM_SIZE
msg    25  00000000 00510260  WM_MOVE
msg    26  00000000 00000000  WM_PAINT
msg    28  00000001 00000000  WM_DWMNCRENDERINGCHANGED
msg    29  00000000 00000000  TaskbarButtonCreated
msg    30  00000000 0019FE84  WM_GETMINMAXINFO
msg    58  00000000 00000000  WM_NCMOUSELEAVE
msg    177  00000000 00000000  WM_NCMOUSELEAVE
msg    258  00000001 00E50029  WM_LBUTTONDOWN
msg    261  00000000 00E50029  WM_LBUTTONUP
msg    286  00000000 00000000  WM_NCMOUSELEAVE
msg    385  00000001 00850045  WM_LBUTTONDOWN
msg    388  00000000 00850045  WM_LBUTTONUP
msg    391  00000001 00850045  WM_LBUTTONDOWN
msg    394  00000000 00850045  WM_LBUTTONUP
msg    414  00000000 00000000  WM_NCACTIVATE
msg    415  00000000 00000000  WM_ACTIVATE
msg    416  00000000 00001C40  WM_ACTIVATEAPP
msg    417  00000000 00000000  WM_KILLFOCUS
msg    418  00000000 C000000F  WM_IME_SETCONTEXT
msg    419  00000001 00000000  WM_IME_NOTIFY
...

It's a two-liner:
WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
local    hdc:HDC
local    ps:PAINTSTRUCT   
local    tm:TEXTMETRIC
  inc msgCount
  deb 4, "msg", chg:msgCount
    SWITCH    uMsg

With NoDebMsg CATSTR NoDebMsg, <, WM_ENTERIDLE, WM_WHATEVER> you can add filters.
With NoDebMsg equ <>, you get all messages.
Use deb 5 instead of deb 4 to send all output to a DebLog.txt file in the executable's folder.

Attached an unfiltered dump, with lots of WM_GETICON, WM_NCHITTEST and WM_SETCURSOR.

Never seen WM_DWMNCRENDERINGCHANGED before :biggrin:

tda0626

Petzold has this little bit of C code in his book.

iVscrollPos = max (0, min (iVscrollPos, NUMLINES − 1))

I am assuming those are macros. Looking them up

max is defined as #define max(a, b)  (((a) > (b)) ? (a) : (b))
min is defined as #define min(a, b)  (((a) < (b)) ? (a) : (b))


So this is what I got out of it. Could someone check it and see if the logic follows the define statements above?

mov eax, NUMLINES
sub eax, 1

.if iVscrollPos < eax

mov eax, iVscrollPos

.else

mov eax, NUMLINES - 1

.endif

mov ecx, 0

.if ecx > eax

mov iVscrollPos, 0

.else

mov iVscrollPos, eax

.endif

NoCforMe

Can simplify it a bit:
mov eax, NUMLINES
sub eax, 1
.if iVscrollPos < eax
mov eax, iVscrollPos
; .else ;Not needed
; mov eax, NUMLINES - 1
.endif
because you already set EAX to NUMLINES-1.
Assembly language programming should be fun. That's why I do it.