I hope it is not off-topic, but I have a few general questions about dialogs that may seem straightforward, but the official documentation is so lacking that I was unable to find any really useful information there. Could you please help me?
First, what's the best way of responding to button clicks if the main (and only) window of the program is a simple dialog box? Usually, all I do to determine which button raised the WM_COMMAND notification message after I receive one is inspect the value of WPARAM, but apparently, given the dialog definition shown below, checking just WPARAM is not sufficient to define the event definitely because the integer identifier of my Copy button (2) happens to have the exact same value as the constant IDCANCEL (WinUser.h), which is sent to me through WM_COMMAND every time the user presses the Esc key, as described here (https://learn.microsoft.com/en-us/windows/win32/dlgbox/dlgbox-programming-considerations#dialog-box-keyboard-interface). I tried examining the high-order word of the WPARAM parameter also for the value BN_CLICKED, but the in-memory value of the parameter seems to always be 02 00 00 00, which – at least to me – makes the messages identical. Should I simply treat all the IDs defined in the Dialog Box Command IDs section of WinUser.h (0 through 7) as system-reserved and just use some other values?
Second, according to this (https://learn.microsoft.com/en-us/windows/win32/menurc/control-control#the-edit-control-class) (official) description of the predefined edit control class, all "[e]dit controls use the fixed-pitch font", but no matter how I actually initialize the dialog, the font of my edit field is always the same as the font that's used for labels, and the only way to change it is by using LOGFONT and CreateFontIndirectA. Is this normal? And what is the default font?
Third, is it also normal that the button mnemonics "C", "N", "x" become inactive after I click somewhere inside the edit field? (Please note that the "style" argument of the edit field does not declare WS_TABSTOP.)
DIAL1 DIALOG 0, 0, 270, 100
STYLE WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX
FONT 8, "MS Sans Serif"
CAPTION "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
{
CONTROL "", 1, "edit",
ES_LEFT | ES_READONLY | WS_BORDER | WS_CHILD | WS_VISIBLE,
10, 20, 250, 12
CONTROL "&Copy", 2, "button",
BS_CENTER | BS_PUSHBUTTON | WS_CHILD | WS_TABSTOP | WS_VISIBLE,
10, 50, 40, 12
CONTROL "&New", 3, "button",
BS_CENTER | BS_PUSHBUTTON | WS_CHILD | WS_TABSTOP | WS_VISIBLE,
60, 50, 40, 12
CONTROL "E&xit", 4, "button",
BS_CENTER | BS_PUSHBUTTON | WS_CHILD | WS_TABSTOP | WS_VISIBLE,
110, 50, 40, 12
}
When creating dialog box controls, generally I try to avoid using single digit identifiers. Where you use 1, 2, 3, etc. I would use 1001, 1002, 1003, etc. for example. This may help for that part. You don't have to start with "1".
I'll get back to this, once I am back at my computer later today... right now, I have to do some work outside.
Quote from: kkurkiewicz on October 23, 2023, 02:18:34 AMThird, is it also normal that the button mnemonics "C", "N", "x" become inactive after I click somewhere inside the edit field?
What I meant was, "Third, is it also normal that the button mnemonics "C", "N", "x" become inactive after I click somewhere inside the edit field,
even if the field is declared to be read-only?"
Could try setting up accelerators to catch the ALT+key for controls then
Have to handle the loading of them first then change the message loop to catch them and process them, something like:
.code
start:
Invoke GetModuleHandle, NULL
mov hInstance, eax
invoke LoadAccelerators, hInstance, ACCTABLE
mov hAcc, eax
Invoke GetCommandLine
mov CommandLine, eax
Invoke InitCommonControls
mov icc.dwSize, sizeof INITCOMMONCONTROLSEX
mov icc.dwICC, ICC_COOL_CLASSES or ICC_STANDARD_CLASSES or ICC_WIN95_CLASSES
Invoke InitCommonControlsEx, Offset icc
Invoke WinMain, hInstance, NULL, CommandLine, SW_SHOWDEFAULT
Invoke ExitProcess, eax
then in WinMain change the loop to:
Invoke CreateDialogParam, hInstance, IDD_DIALOG, NULL, Addr WndProc, NULL
mov hWnd, eax
Invoke ShowWindow, hWnd, SW_SHOWNORMAL
Invoke UpdateWindow, hWnd
.WHILE TRUE
invoke GetMessage, addr msg, NULL, 0, 0
.BREAK .if !eax
Invoke TranslateAccelerator, hWnd, hAcc, addr msg
.IF eax == 0
Invoke IsDialogMessage, hWnd, addr msg
.IF eax == 0
Invoke TranslateMessage, addr msg
Invoke DispatchMessage, addr msg
.ENDIF
.ENDIF
.ENDW
Accelerators are defined and stored as in resource files, and processed via the WM_COMMAND just like any other dialog resource. I define mine as starting with ACC_ and react to those keypresses as if the user clicked the menu option that they correspond to (or button or other control etc)
I have an example of using them in my CD - Compress-Decompress Utility: https://github.com/mrfearless/CD/blob/main/CD.asm (https://github.com/mrfearless/CD/blob/main/CD.asm)
The problem is that the edit control keeps the focus and in modeless dialog boxes that prevents the use of the Alt-Key as long as the edit control has the focus, as it seems.
Do you need the focus (Caret) in the edit control, e.g. to select text?
Otherwise you can try to set the WS_DISABLED style for the edit control.
Or you use a static control instead of an edit control. If you need the text of a static control to be copied to the clipboard, you need Win Vista or higher and set the SS_NOTIFY style to it. Double-clicking the text copies it to the clipboard.
I actually have quite a bit of experience using dialogs, so I might be able to help out here. Just to address one of your several points:
Quote from: kkurkiewicz on October 23, 2023, 02:18:34 AMSecond, according to this (https://learn.microsoft.com/en-us/windows/win32/menurc/control-control#the-edit-control-class) (official) description of the predefined edit control class, all "[e]dit controls use the fixed-pitch font", but no matter how I actually initialize the dialog, the font of my edit field is always the same as the font that's used for labels, and the only way to change it is by using LOGFONT and CreateFontIndirectA. Is this normal? And what is the default font?
First of all, what was written about edit controls [always] using a fixed-pitch font is simply untrue. Edit controls use whatever font they are set to use. So far as the "default" font goes, that is whatever is assigned by the dialog manager when the dialog is created. That font will be used throughout the dialog, for any controls including static text ones. I'm not sure just how you're creating your dialogs (using a resource editor/compiler, which is the usual way, or creating them from an in-memory template, which is the way I do it), but one of the settable parameters of any dialog is the font to be used. This is set by including the
DS_SETFONT style in the dialog style, and specifying the font in a member of the
DLGTEMPLATE structure. (These are implementation details that you may or may not need to concern yourself with. If you're using resource files, the font will be one of the things you can set using them.)
So if you use, say Segoe UI, 9 pt. for your dialog as I do, then your edit controls will be initialized to use that font.
You can always explicitly set the font for any control using the
WS_SETFONT message, of course, but that shouldn't be necessary if you select the font you want for the dialog in the first place, unless you want different fonts for "labels" (static text controls) and other controls.
BTW, at least on my setup (Windows 7), the default font if you create an edit control (or any other control for that mattter) outside of a dialog using
CreateWindowEx() is
UGLY.
Regarding your problems determining which control sent a message, what brother Zedd said here: don't assign any control the same value as any other control in the dialog. All control IDs used in a dialog should be unique, at least within that dialog. If you assign IDOK to a control, that's it: no other control should have that same ID. That way there's no ambiguity about who sent a message; you can always rely on the control ID (in the low word of wParam for WM_COMMAND).
My convention is to start all my control IDs (at least the ones I will be checking for WM_COMMAND messages) at 1200. I use IDs starting at 100 for all my static text controls ("labels"), which I don't care about after creating them. Just make sure they're unique!
Quote from: kkurkiewicz on October 23, 2023, 02:18:34 AM...because the integer identifier of my Copy button (2) happens to have the exact same value as the constant IDCANCEL (WinUser.h), which is sent to me through WM_COMMAND every time the user presses the Esc key
This is
by design: you use IDOK for your Ok button, and IDCANCEL for your Cancel button. Pressing the Esc key is the same as clicking on the Cancel button.
Pseudocode:
DlgControl dcButton, "OK", BS_DEFPUSHBUTTON or WS_TABSTOP, ..., IDOK
DlgControl dcButton, "Quit", BS_PUSHBUTTON or WS_TABSTOP, ..., IDCANCELSorry, this is in strong contradiction to what NoCForMe wrote a minute ago, but I've tested that a hundred times...
Quote from: zedd151 on October 23, 2023, 02:40:34 AMWhen creating dialog box controls, generally I try to avoid using single digit identifiers. Where you use 1, 2, 3, etc. I would use 1001, 1002, 1003, etc.
As written above, there is no conflict: you
should use IDOK for the OK button, and IDCANCEL for the Cancel button. Besides, as a rule, IDs below 128 use much less storage in the rsrc section (for those who are code size aware :smiley: )
JJ, not sure how this contradicts what I wrote. (Not taking exception here and certainly willing to be proven wrong!) All that you wrote is true. Where's the problem?
I should have written "don't assign any control the same value as IDOK or IDCANCEL unless you want that control to have the same effect as IDOK or IDCANCEL".
Well, you wrote "don't assign any control the same value as IDOK or IDCANCEL"... perhaps you meant "don't use IDOK more than once"?
Gotcha.
To clarify: Yes, use IDOK and IDCANCEL for those two important dialog-box functions (usually the "OK" and "Cancel" buttons, though you can use these any way you like, although you might want to be careful about using them in non-standard ways for the sake of your users). Just don't use these same IDs for any non-IDOK or IDCANCEL controls.
If you do use IDOK or IDCANCEL (or any other ID for that matter) for more than one control, you're going to have a hard time determining just which control sent that message**. If you want two controls to have the same functionality as IDOK, say, but want to be able to easily tell which one sent the message, then you might want to assign a different ID to the second control but have it perform the same function as the IDOK one. Does that make sense?
BTW, I must commend you for the quality (and on-topic-ness) of your questions. Excellent questions!
** You can distinguish controls with the same ID by their control handles, which arrive in lParam for WM_COMMAND. Just get their handles in your dialog initialization (WM_INITDIALOG) handler using GetDlgItem() and store them as globals.
Aaaaargh. That won't work. What was I thinking? You can't get two different handles for two controls with the same ID. (What'll probably happen is that you'll get the handle of the first control in the dialog both times.)
Moral of this story: don't have duplicate control IDs in a dialog.
All makes sense, thank you.
When it comes to whether I use templates or RC, I habitually put all dialogs and other resources in an all-in-one resource script and then load them using functions such as DialogBoxParamA, so, as this is also how I handle the example dialog shown in my first post, I'll just leave it as it is. And regarding question three – if I don't find any way to stop the system from changing the color of the font from black to gray, I will redefine the edit box as a static control, as suggested by Greenhorn :thumbsup:
And regarding question one, I'll just go with 1001, 1002....
Static controls make good "output" (display) fields, and you can easily change the text they show with either SetDlgItemText() or SetWindowText(). Only thing I don't like about using them is that with edit controls (set to read-only), you can easily select and copy the text. There's a way to set up statics so you can copy their text by double-clicking them but it's a PITA.
Have you tried adding the WS_TABSTOP style to the edit field to fix your accelerator-prefix problem? I never use those so unfortunately can't help you much there.
Quote from: NoCforMe on October 24, 2023, 09:45:37 AMHave you tried adding the WS_TABSTOP style to the edit field to fix your accelerator-prefix problem?
I think that, at least for now, I'll just get rid of the three mnemonics and remove the Copy button because forcing the user to click a designated button just to select some text seems completely unreasonable to me now. Initially, I wanted the dialog to look like the one shown below, but I would still like the "Result" string to be selectable. Specifying WS_TABSTOP doesn't work because every time the input focus is transferred to the edit field, Windows stops interpreting the characters "C", "N", "x" as hotkeys.
(https://i.postimg.cc/ZCKB9j7J/Create-GUID-utility.png) (https://postimg.cc/ZCKB9j7J)
Quote from: kkurkiewicz on October 25, 2023, 02:39:33 AM... and remove the Copy button ...
Not so fast. :biggrin:
Use that button. In the WM_COMMAND handler for the button, use:
Quoteinvoke OpenClipboard,0 ; clear the content
invoke EmptyClipboard ; of the clipboard
invoke CloseClipboard
invoke SetClipboardText, ADDR yourbuffer ; write to the clipboard
You will have to change "yourbuffer" to the name of the buffer where the results are stored. Doing it this way, copies the text directly from the buffer into the clipboard, bypassing selecting and copying the text from the edit or static control.
I copied and pasted from an example here on the forum by Vortex: https://masm32.com/board/index.php?msg=59238
If I am right, this should help you. :cool:
I may be missing some important details here, but at first glance it looks as if you could just as easily use a static for that display field, since the user isn't copying directly out of it (by selecting text and right-clicking-->"Copy") but instead using your
Copy button. (BTW, it appears to me to be a reasonable way to accomplish this, though it's hard to tell without having the working app to play with). And using a static instead of edit would fix your focus/prefix problems, yes?
Quote[...] remove the Copy button because forcing the user to click a designated button just to select some text seems completely unreasonable to me now.
Not unreasonable at all. Think about it: one button click to copy the contents vs.:
- one click to select the control with the text
- a drag to select the text (or a double click to select all)
- (or a Ctrl-A to select all, replacing the step above, two keystrokes)
- then a right-click to get the context menu
- then another click to select "Copy"
- (or replace the last two steps with Ctrl-C, two keystrokes)
Which one is easier?
Quote from: zedd151 on October 25, 2023, 05:35:31 AMinvoke OpenClipboard,0 ; clear the content
invoke EmptyClipboard ; of the clipboard
invoke CloseClipboard
invoke SetClipboardText, ADDR yourbuffer ; write to the clipboard
See \Masm32\m32lib\setcbtxt.asm, and read this carefully (https://learn.microsoft.com/en-us/answers/questions/607541/(clipboard)-do-i-need-to-call-globalfree-when-usin). It's buggy.
Eventually, I'm going to divide the 250x12 text field into five smaller fields similarly to what's shown below, but I'm still going to treat their concatenated contents as one string – or rather, I'm going to split the string into parts only for the purpose of presenting it to the user. However, having five separate fields makes copying and pasting content really cumbersome, and that's why I created the Copy button. I don't want to use static controls because I don't like their 'unresponsiveness' either. I'll try to replace the "C", "N", "x" mnemonics with accelerators as suggested by fearless, but if this turns out too complicated, I think I'll just use one field and disable the mnemonics.
(https://i.postimg.cc/4KxfKGQZ/1000-DIALOG-0-0-221-106.png) (https://postimg.cc/4KxfKGQZ)
And regarding copying data to clipboard, is it really necessary to call Open-, Empty-, and CloseClipboard? Is the following code wrong?
; Copy?
CMP WORD PTR [EBP+10H], 1002
JNE L3
; Select all the text in the edit control
PUSH -1
PUSH 0
PUSH EM_SETSEL
PUSH 1001
PUSH DWORD PTR [EBP+08H]
CALL SendDlgItemMessageA@20
; Copy the selection to the clipboard
PUSH 0
PUSH 0
PUSH WM_COPY
PUSH 1001
PUSH DWORD PTR [EBP+08H]
CALL SendDlgItemMessageA@20
MOV EAX, 1
JMP FIN
Quote from: kkurkiewicz on October 26, 2023, 06:10:14 AMAnd regarding copying data to clipboard, is it really necessary to call Open-, Empty-, and CloseClipboard? Is the following code wrong?
If that works for you, then it should be fine. :thumbsup:
I was just giving you an example of an alternative approach. :smiley:
Looking at that dialog reminds of the entering code keys or the like. Is the text fields being used like that? if so you could probably catch the ctrl+v if you subclass some or all of the edit controls and then 'paste' parts of the string from the clipboard to each text field.
If its the opposite and your looking to copy all the contents of the text boxes together to form a long string, then catching ctrl+c via subclassing would be an option as well.
Quote from: kkurkiewicz on October 26, 2023, 06:10:14 AMAnd regarding copying data to clipboard, is it really necessary to call Open-, Empty-, and CloseClipboard?
It's a can of worms, just use the official Micros*t docs.
Quote from: kkurkiewicz on October 26, 2023, 05:58:19 AMHowever, having five separate fields makes copying and pasting content really cumbersome, and that's why I created the Copy button. I don't want to use static controls because I don't like their 'unresponsiveness' either.
My vote would still be for the Copy button and static fields. One click and it's copied. (Do users ever need to copy just one segment of that string?)
Regarding the "unresponsiveness" of statics, in this case, who cares? With a Copy button there's no need to interact with them at all. (Unless the answer to my question above is "yes".)
Regarding copying stuff to the clipboard: it ain't rocket surgery. The following code works fine for me (been using it for years), and no need to lock memory or other such nonsense:
do_copyClp:
INVOKE OpenClipboard, MainWinHandle
INVOKE HeapAlloc, HeapHandle, HEAP_NO_SERIALIZE, $textHeapSize
MOV CopyHeap, EAX
INVOKE SendMessage, EditWinHandle, WM_GETTEXT, $textHeapSize, CopyHeap
CALL EmptyClipboard
INVOKE SetClipboardData, CF_TEXT, CopyHeap
CALL CloseClipboard
Your code is in open contradiction to the Micros*t docs, though.
QuoteIf SetClipboardData succeeds, the system owns the object identified by the hMem parameter. The application may not write to or free the data once ownership has been transferred to the system, but it can lock and read from the data until the CloseClipboard function is called. (The memory must be unlocked before the Clipboard is closed.) If the hMem parameter identifies a memory object, the object must have been allocated using the function with the GMEM_MOVEABLE flag.
Quote from: fearless on October 26, 2023, 08:16:59 AMIs the text fields being used like that?
It's the opposite. The program is not supposed to validate the codes but produce them :winking:
Quote from: jj2007 on October 26, 2023, 11:51:14 PMYour code is in open contradiction to the Micros*t docs, though.
What can I tell you? It works just fine, on everything from Windoze 2000 up to 7.
Try it and see for yourself.
The OS expects a GlobalAlloc'ed object, you are passing a HeapAlloc'ed one. The OS will try to free the object next time when another program calls EmptyClipboard. What happens when you GlobalFree heap memory? I have no idea.
Hi NoCforMe,
Quoteand no need to lock memory or other such nonsense:
QuoteIf SetClipboardData succeeds, the system owns the object identified by the hMem parameter. The application may not write to or free the data once ownership has been transferred to the system, but it can lock and read from the data until the CloseClipboard function is called. (The memory must be unlocked before the Clipboard is closed.) If the hMem parameter identifies a memory object, the object must have been allocated using the function with the GMEM_MOVEABLE flag.
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setclipboarddata (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setclipboarddata)
https://learn.microsoft.com/en-us/windows/win32/dataxchg/using-the-clipboard (https://learn.microsoft.com/en-us/windows/win32/dataxchg/using-the-clipboard)
Look, all I can tell you is that my method has been working fine for me for years and has no ill effects on the operation of the clipboard at all. We all know that Micro$oft documentation is notoriously confused, deficient and, in some case, just plain wrong.
Like I said, try it and see what your results are. I'd be curious to hear what you find.
Quote from: NoCforMe on October 27, 2023, 07:40:05 AMtry it and see what your results are
To test that, you would need a setup where one program uses your method fifty-thousand times, while another program clears the clipboard immediately after. Of course, you will have no problems if you do that only a few times...
You are touching a global resource here. Yes, GlobalAlloc uses eventually the heap, but it does some tricks there. I don't know the details, but probably the OS keeps a global table where it stores the heap handles. By using GlobalFree for a heapalloc'ed block, you are bypassing that global table. Maybe it will be full after a while, who knows?
Locking the memory portion has a meaning, it protects the data and makes it consistent. The official example of MS :
// Allocate a global memory object for the text.
hglbCopy = GlobalAlloc(GMEM_MOVEABLE,
(cch + 1) * sizeof(TCHAR));
if (hglbCopy == NULL)
{
CloseClipboard();
return FALSE;
}
// Lock the handle and copy the text to the buffer.
lptstrCopy = GlobalLock(hglbCopy);
memcpy(lptstrCopy, &pbox->atchLabel[ich1],
cch * sizeof(TCHAR));
lptstrCopy[cch] = (TCHAR) 0; // null character
GlobalUnlock(hglbCopy);
// Place the handle on the clipboard.
SetClipboardData(CF_TEXT, hglbCopy); https://learn.microsoft.com/en-us/windows/win32/dataxchg/using-the-clipboard (https://learn.microsoft.com/en-us/windows/win32/dataxchg/using-the-clipboard)
You can ask ChatCPT.
me :
QuoteIn windows programming, why do I need a locked memory area while dealing with clipboard functions?
ChatGPT :
QuoteIn Windows programming, when working with clipboard functions, you may need to use locked memory for a couple of reasons:
Data Transfer Between Processes: The Windows Clipboard is used for transferring data between different processes or applications. When you copy data to the clipboard in one application and paste it into another, the data needs to be accessible to both processes. Locked memory ensures that the data remains in a consistent memory location so that it can be shared and accessed by both processes.
Data Format Stability: When you place data on the clipboard, it needs to remain in a stable format until it's pasted. This means that the data should not be moved or altered in any way. Locking the memory prevents the operating system or other processes from moving or modifying the data while it's on the clipboard. This ensures that the pasted data retains its integrity and format.
To accomplish these goals, Windows provides functions like GlobalAlloc, GlobalLock, GlobalUnlock, and related functions to allocate and lock memory for clipboard data. These functions allocate memory from the global heap and lock it in place, making it accessible and stable for clipboard operations.
Here's a typical sequence of steps for using locked memory with clipboard functions in Windows:
Allocate memory using GlobalAlloc or another appropriate function.
Lock the allocated memory with GlobalLock.
Copy or write your data into the locked memory.
Place the locked memory on the clipboard using clipboard functions like SetClipboardData.
When you're done with the clipboard data, unlock the memory using GlobalUnlock.
By following this process, you ensure that the data is locked in a stable memory area, making it safe and consistent for clipboard operations between different processes and across the clipboard's various data formats.
Quote from: jj2007 on October 27, 2023, 07:43:57 AMQuote from: NoCforMe on October 27, 2023, 07:40:05 AMtry it and see what your results are
To test that, you would need a setup where one program uses your method fifty-thousand times, while another program clears the clipboard immediately after.
Well, Jochen, nobody's stopping you from doing just that. I know with your super-duper IDE you could probably whip up a test like that in a short time. Might vindicate me, or might reveal that I'm slowly corrupting the OS by playing fast and loose with global memory ...
Hi NoCforMe,
Nobody is trying to vindicate or hurt you. Jochen is trying to explain the importance of respecting the documentation provided by the OS manufacturer. M$ may be not perfect and the documentation may be not perfect too. They write millions line of code and probably there are reasons why to follow the documentation. It's all simple, the text tells that you must provide secure and reliable data while manipulating the clipboard.
Don't worry, no hurt feelings here either way. What I do works for me, so I ain't worrying about it. (I probably wouldn't suggest that anyone use my code in their production application.) I'd be mildly curious to see if such a test would vindicate me or not, but beyond that I'm not losing any sleep over this.
Read the manual, it's as simple as that.
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-globalalloc (https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-globalalloc)
QuoteNote The global functions have greater overhead and provide fewer features than other memory management functions. New applications should use the heap functions unless documentation states that a global function should be used. For more information, see Global and Local Functions.
Quote[...]
The movable-memory flags GHND and GMEM_MOVABLE add unnecessary overhead and require locking to be used safely. They should be avoided unless documentation specifically states that they should be used.
New applications should use the heap functions to allocate and manage memory unless the documentation specifically states that a global function should be used. For example, the global functions are still used with Dynamic Data Exchange (DDE), the clipboard functions, and OLE data objects.
[...]
Be nice, guys... this IS the Campus. :smiley:
NoCforMe, I sent you a PM.
It'll work competely fine in NT windows until such time as HeapHandle is not GetProcessHeap, then it'll crash.
Can you please clarify that a bit? Not sure what you're saying here.
Quote from: adeyblue on October 27, 2023, 02:30:03 PMIt'll work competely fine in NT windows until such time as HeapHandle is not GetProcessHeap, then it'll crash.
Hi
adeyblue, nice to see you :thumbsup:
I recently re-discovered your zip post (https://masm32.com/board/index.php?topic=3215.msg34255#msg34255) - great stuff.
Here is a little test:
include \masm32\include\masm32rt.inc
.code
start:
xor ebx, ebx
.Repeat
inc ebx
print str$(ebx), " "
invoke HeapAlloc, rv(GetProcessHeap), 0, 100000
invoke GlobalFree, eax
.if rv(GetLastError)
print " error", 13, 10
.endif
.Until ebx>99
MsgBox 0, "ok", "Hi", MB_OK
exit
end startThat works fine, so the OS has no problems to free heap memory using GlobalFree. However, as mentioned above, there might be a global table (pun intended) where it keeps track of GlobalAlloc memory. So, if you do the trick a Million times, it's not clear what can happen. And of course, it's not documented :cool:
Quote from: jj2007 on October 27, 2023, 07:43:57 AMyou would need a setup where one program uses your method fifty-thousand times, while another program clears the clipboard immediately after. Of course, you will have no problems if you do that only a few times...
You are touching a global resource here. Yes, GlobalAlloc uses eventually the heap, but it does some tricks there. I don't know the details, but probably the OS keeps a global table where it stores the heap handles. By using GlobalFree for a heapalloc'ed block, you are bypassing that global table. Maybe it will be full after a while, who knows?
Quote from: NoCforMe on October 27, 2023, 03:11:30 PMCan you please clarify that a bit? Not sure what you're saying here.
QuoteMore on the Global Heap Manager (https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/july/under-the-hood-happy-10th-anniversary-windows)
To allocate memory directly from the global heap, Windows 3.0-based programs called the GlobalAlloc API. GlobalAlloc still exists in Win32, but only to ease porting of Win16 code. Under the hood, GlobalAlloc is just a layer over the same heap manager used by HeapAlloc, which allocates memory visible only to the calling process. Thus, GlobalAlloc memory in Win32 is local to its allocating process, and not really global.
So if I read that last part correctly, doesn't that make what I'm doing (using HeapAlloc() ) OK? No matter what else they (MS) say you need to do to use the clipboard?
The only thing that is clear is that nothing is clear: it's not documented. The clipboard is information exchanged between processes, not within one process. So it must use some global resource (same for SendMessage to other processes btw).
Wellll, it could be a global resource; or maybe it could be a shared local resource? ISTR there are such things within Win32.
Where is Raymond Chen when you need him?
See Memory Leaks 'r Us' Started by Raistlin, May 31, 2018 (https://masm32.com/board/index.php?topic=7190.0)
Interesting (https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-globalalloc):
QuoteThe following values are obsolete, but are provided for compatibility with 16-bit Windows. They are ignored.
...
GMEM_DDESHARE
GMEM_SHARE
SetClipboardData (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setclipboarddata):
QuoteIf SetClipboardData succeeds, the system owns the object identified by the hMem parameter. The application may not write to or free the data once ownership has been transferred to the system, but it can lock and read from the data until the CloseClipboard function is called. (The memory must be unlocked before the Clipboard is closed.) If the hMem parameter identifies a memory object, the object must have been allocated using the function with the GMEM_MOVEABLE flag.
Re "the clipboard is a can of worms":
QuoteBOOL OpenClipboard (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-openclipboard)(
[in, optional] HWND hWndNewOwner
);
hWndNewOwner: A handle to the window to be associated with the open clipboard. If this parameter is NULL, the open clipboard is associated with the current task.
...
If an application calls OpenClipboard with hwnd set to NULL, EmptyClipboard sets the clipboard owner to NULL; this causes SetClipboardData to fail.
caesay (https://stackoverflow.com/questions/43195256/whats-the-point-of-openclipboard-api):
QuoteThere is lots of mis-information here. If you are reading from the clipboard, you can provide an empty handle to OpenClipboard, but if you intend to write (ex, SetClipboardData) then you must open the clipboard with a handle to a window you own.
I'm a firm believer in the way of Win32 programming that Hutch apparently hated. Even more firm after re-reading some of R. Chen's comments on this topic in those posts you linked.
Look, the guy said: when your program exits, it basically frees everything that it allocated. So stop being so anal about unwinding every little allocation you made. If he said it, it's like the word of God, right?
I do do deallocation of GDI objects in my WM_PAINT handlers, just to keep the number of objects flying around in my program's space to a minimum. But even this isn't necessary.
https://devblogs.microsoft.com/oldnewthing/20041101-00/?p=37433 (https://devblogs.microsoft.com/oldnewthing/20041101-00/?p=37433)
QuoteEven in Win32, you have to be careful not to confuse the local heap from the global heap. Memory allocated from one cannot be freed on the other. The functional differences have largely disappeared; the semantics are pretty much identical by this point. All the weirdness about near and far pointers disappeared with the transition to Win32. But the local heap functions and the global heap functions are nevertheless two distinct heap interfaces.
Quote from: NoCforMe on October 28, 2023, 11:56:42 AMLook, the guy said: when your program exits, it basically frees everything that it allocated. So stop being so anal about unwinding every little allocation you made.
Correct, but check for global resources, such as atoms.
QuoteI do do deallocation of GDI objects in my WM_PAINT handlers, just to keep the number of objects flying around in my program's space to a minimum. But even this isn't necessary.
If you think it isn't necessary in a WM_PAINT handler, then don't do it. You will have unpleasant surprises, though :biggrin:
From Petzold's "Windows Progamming":
https://www-user.tu-chemnitz.de/~heha/petzold/ch12b.htm (https://www-user.tu-chemnitz.de/~heha/petzold/ch12b.htm)
QuoteSimple Use of the Clipboard
(...)
Memory Allocation
When your program transfers something to the clipboard, it must allocate a memory block and essentially hand it over to the clipboard. When we've needed to allocate memory in earlier programs in this book, we've simply used the malloc function that is supported by the standard C run-time library. However, because the memory blocks stored by the clipboard must be shared among applications running under Windows, the malloc function is inadequate for this task.
Instead, we must dredge up memory allocation functions that were designed back in the dark ages of Windows, in the days when the operating system ran in a 16-bit real-mode memory architecture. These functions are still supported and you can still use them, but they are not often needed.
To allocate a memory block using the Windows API, you can call
hGlobal = GlobalAlloc (uiFlags, dwSize) ;
The function takes two parameters: a possible series of flags and a size in bytes of the allocated block. The function returns a handle of type HGLOBAL, called a "handle to a global memory block" or a "global handle." A NULL return value indicates that sufficient memory was not available for the allocation.
Although the two parameters to GlobalAlloc are defined a bit differently, they are both 32-bit unsigned integers. If you set the first parameter to zero, you effectively use the flag GMEM_FIXED. In this case, the global handle that GlobalAlloc returns is actually a pointer to the allocated memory block.
You can also use the flag GMEM_ZEROINIT if you'd like every byte in the memory block to be initially set to zero. The succinct GPTR flag combines the GMEM_FIXED and GMEM_ZEROINIT flags as defined in the Windows header files:
#define GPTR (GMEM_FIXED | GMEM_ZEROINIT)
There is also a reallocation function:
hGlobal = GlobalReAlloc (hGlobal, dwSize, uiFlags) ;
You can use the GMEM_ZEROINIT flag to zero out the new bytes if the memory block is being enlarged.
Here's the function to obtain the size of the memory block:
dwSize = GlobalSize (hGlobal) ;
and the function to free it:
GlobalFree (hGlobal) ;
In the early 16-bit versions of Windows, the GMEM_FIXED flag was strongly discouraged because Windows could not move the block in physical memory. In the 32-bit versions of Windows, the GMEM_FIXED flag is normal because it returns a virtual address and the operating system can move the block in physical memory by altering the page table. When programming for the 16-bit versions of Windows, using the flag GMEM_MOVEABLE in GlobalAlloc was instead recommended. (Note that most dictionaries prefer the spelling "movable" over "moveable," so that's how I'll spell the word otherwise.) There's also a shorthand identifier identified in the Windows header files to additionally zero out the movable memory:
#define GHND (GMEM_MOVEABLE | GMEM_ZEROINIT)
The GMEM_MOVEABLE flag allows Windows to move a memory block in virtual memory. This doesn't necessarily mean that the memory block will be moved in physical memory, but the address that the application uses to read and write to the block can change.
Although GMEM_MOVEABLE was the rule in 16-bit versions of Windows, it is generally less useful now. However, if your application frequently allocates, reallocates, and frees memory blocks of various sizes, the virtual address space of your application can become fragmented. Conceivably, you could run out of virtual memory addresses. If this is a potential problem, then you'll want to use movable memory, and here's how to do it.
First define a pointer (for example, to an int type) and a variable of type GLOBALHANDLE:
int * p ;
GLOBALHANDLE hGlobal ;
Then allocate the memory. For example:
hGlobal = GlobalAlloc (GHND, 1024) ;
As with any Windows handle, don't worry too much about what the number really means. Just store it. When you need to access that memory block, call
p = (int *) GlobalLock (hGlobal) ;
This translates the handle into a pointer. During the time that the block is locked, Windows will fix the address in virtual memory. It will not move. When you are finished accessing the block, call
GlobalUnlock (hGlobal) ;
This gives Windows the freedom to move the block in virtual memory. To be really compulsively correct about this process (and to experience the torments of early Windows programmers), you should lock and unlock the memory block in the course of a single message.
When you want to free the memory, call GlobalFree with the handle rather than the pointer. If you don't currently have access to the handle, use the function
hGlobal = GlobalHandle (p) ;
You can lock a memory block multiple times before unlocking it. Windows maintains a lock count, and each lock requires a corresponding unlock before the block is free to be moved. When Windows moves a block in virtual memory, it doesn't need to copy the bytes from one location to another—it needs only manipulate the page tables. In general, in the 32-bit versions of Windows the only real reason for allocating a movable block for your own program's use is to prevent fragmentation of virtual memory. When using the clipboard, you should also use movable memory.
When allocating memory for the clipboard, you should use the GlobalAlloc function with both the GMEM_MOVEABLE and the GMEM_SHARE flags. The GMEM_SHARE flag makes the block available to other Windows applications.
(...)
Quote from: Greenhorn on October 28, 2023, 11:42:52 PMAlthough GMEM_MOVEABLE was the rule in 16-bit versions of Windows, it is generally less useful now. However, if your application frequently allocates, reallocates, and frees memory blocks of various sizes, the virtual address space of your application can become fragmented.
Good find :thumbsup:
I know it has been almost two weeks, but—can I have a follow-up question? After going through the source of fearless' CD utility, I tried implementing the accelerators in the same way, but no matter what I do, I can't even implement (or enable) the processing for TAB. Everything works fine when the application window is a modal dialog, but as soon as I switch from DialogBoxParamA to CreateDialogParamA, all the 'bundled' navigation keys, such as TAB or ENTER, basically become dead. I'm fully aware that in the case of modeless dialogs, the keys will not work unless the application calls IsDialogMessage, but it seems to me that they simply generate no messages. Following this (https://devblogs.microsoft.com/oldnewthing/20160818-00/?p=94115) blog post, I call the IsDialogMessage function as soon as I check the return value of GetMessage, and my message dispatch looks as follows, but it doesn't work. Please, do you notice anything wrong with this code? (Full code in attachment.)
; Get the application descriptor
PUSH 0
CALL GetModuleHandleA@4
MOV HINST, EAX
;-----------------------------------
PUSH 0
PUSH OFFSET DLGPROC
PUSH 0
PUSH OFFSET PA
PUSH HINST
CALL CreateDialogParamA@20
MOV NEWHWND, EAX
; Message-processing loop
MSG_LOOP:
PUSH 0
PUSH 0
PUSH 0
PUSH OFFSET MSG
CALL GetMessageA@16
CMP EAX, 0
JE END_LOOP
; Call IsDialogMessageA
PUSH OFFSET MSG
PUSH NEWHWND
CALL IsDialogMessageA@8
CMP EAX, 0
JNE MSG_LOOP
PUSH OFFSET MSG
CALL TranslateMessage@4
PUSH OFFSET MSG
CALL DispatchMessageA@4
JMP MSG_LOOP
END_LOOP:
PUSH 0
CALL ExitProcess@4
Quote from: kkurkiewicz on November 13, 2023, 05:34:39 AMI can't even implement (or enable) the processing for TAB
Where exactly do you process for TAB? File, line number?
Quote from: jj2007 on November 13, 2023, 08:03:58 AMWhere exactly do you process for TAB?
Isn't it enough to specify WS_TABSTOP in a resource script?
Right, I had not opened all your files. Btw prog1.asm builds fine and works fine when pressing TAB. In contrast, prog2.asm doesn't.
To find out why, check the differences, see attachment. I am not eager to read code that makes no use of the invoke macro, but don't take that personally, please :thup:
P.S.: Can you explain what you are doing here?
PUSH 0
PUSH OFFSET DLGPROC
PUSH 0
PUSH OFFSET PA
PUSH [HINST]
CALL DialogBoxParamA@20
CMP EAX, -1
JNE KOL
KOL:
...
No. That only applies to tabbing behavior within the dialog, and not to any special handling of tabs. In other words, WS_TABSTOP when applied to a control in a dialog just tells the dialog manager that that control should be moved to in sequence when the user presses the Tab key. It doesn't allow for any other function of the tab key.
I know a lot about dialogs and have been able to make them do several non-standard tricks, but unfortunately I don't have an answer to your problem of handling tabs. If I discover anything I'll let you know.
Quote from: jj2007 on November 13, 2023, 11:05:00 AMI am not eager to read code that makes no use of the invoke macro, but don't take that personally, please :thup:
What JJ said. That was my reaction on glancing at your code. Please learn to use INVOKE instead of push-push-call. It makes your code SO much more readable and generates exactly the same code. (And likewise, no disrespect intended.)
Maybe handle the WM_GETDLGCODE message and return:
mov eax, DLGC_WANTTAB or DLGC_WANTALLKEYS
ret
https://learn.microsoft.com/en-us/windows/win32/dlgbox/wm-getdlgcode (https://learn.microsoft.com/en-us/windows/win32/dlgbox/wm-getdlgcode)
I should also add and echo what was mentioned above, that I found it difficult to read and go through the code, I was attempting to add in the WM_GETDLGCODE check but found that its just too awkward to insert it without having to change many other labels.
From a code maintenance point of view for your own future reference and readability it might be handier to use the .IF .ELSE .ELSEIF and .ENDIF when processing the messages. The assembler will automatically create the appropriate low level code to handle those conditional branching statements, which makes it easier to read and to modify at a later stage.
Similarly the use of parameters in the procedure instead of manually referring to stack or base pointer offsets makes it easier to deal with variables and parameter values.
Its too easy to accidentally supply the wrong value and spend ages trying to debug something that is a typo or user provided error (wrong offset etc). Something to think about, and you dont need to change everything all at once, but you may find that it speeds up your development when its easier to read and maintain.
Quote from: jj2007 on November 13, 2023, 11:05:00 AMCan you explain what you are doing here?
PUSH 0
PUSH OFFSET DLGPROC
PUSH 0
PUSH OFFSET PA
PUSH [HINST]
CALL DialogBoxParamA@20
CMP EAX, -1
JNE KOL
KOL:
...
Just instantiating the dialog... From the bottom up—HINST is the application descriptor retrieved by calling GetModuleHandleA, PA the identifier of the dialog, 0 a handle to the window that owns the dialog box (there isn't any), DLGPROC the dialog procedure, and the second 0 the pointer to be passed to the dialog box in the lParam parameter of the WM_INITDIALOG message (also NULL).
Quote from: NoCforMe on November 13, 2023, 11:05:23 AMNo. That only applies to tabbing behavior within the dialog, and not to any special handling of tabs. In other words, WS_TABSTOP when applied to a control in a dialog just tells the dialog manager that that control should be moved to in sequence when the user presses the Tab key. It doesn't allow for any other function of the tab key.
All I want to do is to modify the prog1 version of the dialog so that it is modeless and enable the buttons to be tabbed to with the tabulator key, but please note that in the prog2 program, all the buttons also specify mnemonics—they don't work either. It seems to me that I just need to enable the system-provided dialog box keyboard interface (https://learn.microsoft.com/en-us/windows/win32/dlgbox/dlgbox-programming-considerations#dialog-box-keyboard-interface), but there's simply something wrong with it (I even tried creating a custom control class).
And regarding the style of the code, I'm just not that used to programming in pure assembly as I am to using disassemblers.
I got prog2 to work with tab navigation by moving variable NEWHWND to another place:
HFONT DD 0
HINST DD 0 ; Application descriptor
NEWHWND DD 0
KEY DB 19 DUP (?)
LG LOGFONT <?>
MSG MSGSTRUCT <?>
NEXT DD 0
NFONT DB 'Lucida Console', 0
I didn't elaborate the problem further - perhaps the MSGSTRUCT structure you've defined is too short?
Quote from: kkurkiewicz on November 14, 2023, 04:27:44 AMAnd regarding the style of the code, I'm just not that used to programming in pure assembly as I am to using disassemblers.
I understand; one does what one is used to doing. But I think you'd benefit greatly from changing your style just a little bit. Not only would
we be able to understand your code better, you yourself would as well. And it would be much more maintainable (just imagine coming back to something you wrote a year or two ago and trying to make heads or tails of what it does).
Code disassembly is a terrible template for a coding style. And coding has changed from, say, 20 years ago:
PUSH TheOther
PUSH That
PUSH This
CALL Function | INVOKE Function, This, That, TheOther |
| MOV [ESP+24], EAX | MOV Variable, EAX |
| MOV [Variable], EAX | MOV Variable, EAX |
(This was my attempt to use this forum's "table" formatting tag. Conclusion: it sucks.)
Oh, and one more thing: I noticed you had to define a bunch of Win32 constants in your code:
; Selects a range of characters in an edit control
EM_SETSEL EQU 0B1h
; Tells the target window to shut down
WM_CLOSE EQU 10h
WM_COMMAND EQU 111h
; Sent to an edit control to copy the current selection to the clipboard
WM_COPY EQU 301h
WM_INITDIALOG EQU 110h
; Used to set the font that is to be used when displaying text
WM_SETFONT EQU 30h
WM_SETTEXT EQU 0Ch
etc., etc.
This is totally pointless and needless work on your part. All of these constants as well as (almost) all of the structures and other elements used in Win32 are already defined in the MASM32 project (most of it in a file called
windows.inc). People have toiled and slaved for years to distill all this stuff out of all those C header files; why not take advantage of it, instead of totally reinventing the wheel as you're doing here?
Quote from: _japheth on November 14, 2023, 06:13:52 AMI didn't elaborate the problem further - perhaps the MSGSTRUCT structure you've defined is too short?
Yes, it is. Should look like this:
; Message structure
MSGSTRUCT STRUC
MSHWND DD ?
MSMESSAGE DD ?
MSWPARAM DD ?
MSLPARAM DD ?
MSTIME DD ?
MSPT DQ ?
LRSVD DD ?
MSGSTRUCT ENDS
And prog2 is the way to go. With calling CreateDialogParam the function returns a window handle and you can create and execute a message loop.
In prog1 you call DialogBoxParam which not returns before closing the Diallog Box. So, here a message loop would be useless.
QuoteNovember 13, 2023, 11:09:02 AM
Quote from: jj2007 on November 13, 2023, 11:05:00 AM
I am not eager to read code that makes no use of the invoke macro, but don't take that personally, please :thup:
Quote from: NoCforMe
What JJ said. That was my reaction on glancing at your code.
Please learn to use INVOKE instead of push-push-call.
It makes your code SO much more readable and generates exactly the same code.
(And likewise, no disrespect intended.)
I recommend using clean and fast assembly code without the annoying and incomprehensible macros written at a "high" level.
This is according to the new MS rules for working without macros for masm64.
If you want to share code with Masm32 people like
JJ or
NoCforMe who don't want and can't accept the new rules, add the version with "invoke" as a comment.
Example:
mov qword ptr [rsp+10*8],0
mov qword ptr [rsp+9*8], 0
mov qword ptr [rsp+8*8], FILE_SYNCHRONOUS_IO_NONALERT or FILE_NON_DIRECTORY_FILE
mov qword ptr [rsp+7*8], FILE_OVERWRITE_IF
mov qword ptr [rsp+6*8], FILE_SHARE_READ or FILE_SHARE_WRITE
mov qword ptr [rsp+5*8], FILE_ATTRIBUTE_NORMAL
mov qword ptr [rsp+4*8], 0
lea r9, sb
lea r8, oa
mov edx, FILE_GENERIC_WRITE or SYNCHRONIZE or FILE_GENERIC_READ or FILE_NO_INTERMEDIATE_BUFFERING
lea rcx, hFileWW ; invoke NtCreateFile, addr hFileWW, FILE_GENERIC_WRITE or SYNCHRONIZE or FILE_GENERIC_READ or \
call NtCreateFile ; FILE_NO_INTERMEDIATE_BUFFERING, addr oa, addr sb, 0, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ or \
; FILE_SHARE_WRITE, FILE_OVERWRITE_IF,FILE_SYNCHRONOUS_IO_NONALERT or FILE_NON_DIRECTORY_FILE, 0, 0
or
mov eax, rcNum.bottom
mov rcx, numDC
mov qword ptr [rsp+8*8], SRCCOPY
mov qword ptr[rsp+7*8], 0
mov qword ptr[rsp+6*8], 0
mov [rsp+5*8], rcx
mov [rsp+4*8], rax
mov r9d, rcNum.right
xor r8d, r8d
xor edx, edx
mov rcx, hdc
call BitBlt ; invoke BitBlt, hdc, 0, 0, rcNum.right, rcNum.bottom, numDC, 0, 0, SRCCOPY
The old has a hard time accepting the new... :badgrin: :biggrin:
Quote from: lingo on November 14, 2023, 12:34:27 PMI recommend using clean and fast assembly code without the annoying and incomprehensible macros written at a "high" level.
This is according to the new MS rules for working without macros for masm64.
Lingo, you forgot the irony tags :bgrin:
One "advantage" of the 64-bit ABI is that people who cannot count to 12 (CreateWindowEx) or to 14 (CreateFontA) are not immediately being punished with an imbalanced stack; so the crash may happen a bit later :bgrin:
Quote from: _japheth on November 14, 2023, 06:13:52 AMperhaps the MSGSTRUCT structure you've defined is too short?
Good find. What the OP wanted is the MSG structure...
His version:
MSGSTRUCT STRUC
MSHWND DD ?
MSMESSAGE DD ?
MSWPARAM DD ?
MSLPARAM DD ?
MSTIME DD ?
MSPT DD ?
MSGSTRUCT ENDSMasm32 SDK version (Windows.inc):
MSG STRUCT
hwnd DWORD ?
message DWORD ?
wParam DWORD ?
lParam DWORD ?
time DWORD ?
pt POINT <>
MSG ENDSA POINT is composed of
two DWORDs.
Btw there is no MSGSTRUCT in the Windows documentation, but it pops up in an old TASM post (http://computer-programming-forum.com/46-asm/44121c3abb136f03.htm); and it's wrong, with a dd instead of the POINT:
QuoteI have been trying to make the switch from Dos to Win32 asm. I am using
Barry Kauler's Win32 asm book and Tom Swan's Mastering Turbo Asm. I am
working with the Whello.asm example in MTA. When I assemble using tasm32,
I get 'Symbol already different kind: MSGSTRUCT' then an error for each
use of msg saying it is an undefined symbol.
The MSGSTRUCT looks like this in WINDOWS.inc
MSGSTRUCT struc
msHWND dw ?
msMESSAGE dw ?
msWPARAM dw ?
msLPARAM dd ?
msTIME dd ?
msPT dd ?
MSGSTRUCT ends
Quote from: lingo on November 14, 2023, 12:34:27 PMIf you want to share code with Masm32 people like JJ or NoCforMe who don't want and can't accept the new rules, add the version with "invoke" as a comment.
Wait, wut? What are the "new rules"?
Must admit your irony is kinda whizzing several levels over my head. Must be a slow day.
Quote from: jj2007 on November 14, 2023, 12:45:05 PMMasm32 SDK version (Windows.inc):
MSG STRUCT
hwnd DWORD ?
message DWORD ?
wParam DWORD ?
lParam DWORD ?
time DWORD ?
pt POINT <>
MSG ENDS
Gotta admit I much prefer our (MASM32) versions like this one you posted, since they match (for the most part
**) what you'll find on what's now called "Microsoft Learn", the big document repository. You can just copy the names directly out of the web pages without having to retype them. The folks who created these took pains to use the same names you'd find in a
.h header file.
** With a couple exceptions where names had to be changed because they conflicted with MASM keywords.
JJ, QuoteOne "advantage" of the 64-bit ABI is that people who cannot count to 12 (CreateWindowEx) or to 14 (CreateFontA) are not immediately being punished with an imbalanced stack; so the crash may happen a bit later :bgrin:
The big advantage is that at the beginning of the program I free enough space on the stack for the arguments of the functions via
sub rsp,256 and before the end of the program I restore the stack by
add rsp, 256.This is enough to forget about the stack when calling a functions with more arguments.
JJ, you forgot the irony tags :bgrin:
You'd be better off stopping with masm32 examples and moving to masm64 if you want to stay up to date.
Soon masm32 will be only history just like 16 bit DOS Programming.
I use:
MSG64 STRUCT
hwnd QWORD ?
message QWORD ?
wParam QWORD ?
lParam QWORD ?
time DWORD ?
ptX DWORD ?
ptY DWORD ?
DWORD ? ; Align to 8 struc MSG64
MSG64 ENDS
Total: 4*8 + 4*4 = 48 bytes
from MS:typedef struct tagMSG { HWND hwnd;
UINT message;
WPARAM wParam;
LPARAM lParam;
DWORD time;
POINT pt;
DWORD lPrivate; !!!
} MSG, *PMSG, *NPMSG, *LPMSG;
POINT STRUCT
x DWORD ?
y DWORD ?
POINT ENDS
:skrewy: :biggrin:
x64 MSG
POINT struct
x dd ?
y dd ?
POINT ends
MSG struct
hwnd dq ?
message dd ?
padding1 dd ? ; padding
wParam dq ?
lParam dq ?
time dd ?
pt POINT <>
padding2 dd ? ; padding
MSG ends
/*
* Message structure
*/
typedef struct tagMSG {
HWND hwnd;
UINT message;
WPARAM wParam;
LPARAM lParam;
DWORD time;
POINT pt;
#ifdef _MAC
DWORD lPrivate;
#endif
} MSG, *PMSG, NEAR *NPMSG, FAR *LPMSG;
:biggrin: 9/5/2012 :biggrin:
MSG structure
Applies to: desktop apps | Windows Store apps
Contains message information from a thread's message queue.
Syntax
typedef struct tagMSG {
HWND hwnd;
UINT message;
WPARAM wParam;
LPARAM lParam;
DWORD time;
POINT pt;
} MSG, *PMSG, *LPMSG;
Members
hwnd
Type: HWND
A handle to the window whose window procedure receives the message. This member is NULL when the message is a thread message.
message
Type: UINT
The message identifier. Applications can only use the low word; the high word is reserved by the system.
wParam
Type: WPARAM
Additional information about the message. The exact meaning depends on the value of the message member.
lParam
Type: LPARAM
Additional information about the message. The exact meaning depends on the value of the message member.
time
Type: DWORD
The time at which the message was posted.
pt
Type: POINT
The cursor position, in screen coordinates, when the message was posted.
Requirements
Minimum supported client
Windows 2000 Professional
Minimum supported server
Windows 2000 Server
Header
Winuser.h (include Windows.h)
See also
Reference
GetMessage
PeekMessage
PostThreadMessage
Conceptual
Messages and Message Queues
Send comments about this topic to Microsoft
Build date: 9/5/2012
:biggrin: :biggrin: :biggrin:
MSG structure (winuser.h)
Article
11/19/2022
In this article
Syntax
Members
Requirements
See also
Contains message information from a thread's message queue.
Syntax
C++
Copy
typedef struct tagMSG {
HWND hwnd;
UINT message;
WPARAM wParam;
LPARAM lParam;
DWORD time;
POINT pt;
DWORD lPrivate;
} MSG, *PMSG, *NPMSG, *LPMSG;MSG structure (winuser.h) (https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-msg)
Quote from: lingo on November 14, 2023, 03:06:29 PMJJ,
QuoteOne "advantage" of the 64-bit ABI is that people who cannot count to 12 (CreateWindowEx) or to 14 (CreateFontA) are not immediately being punished with an imbalanced stack; so the crash may happen a bit later :bgrin:
The big advantage is that at the beginning of the program I free enough space on the stack for the arguments of the functions via sub rsp,256 and before the end of the program I restore the stack by add rsp, 256.
This is enough to forget about the stack when calling a functions with more arguments.
JJ, you forgot the irony tags :bgrin:
You'd be better off stopping with masm32 examples and moving to masm64 if you want to stay up to date.
You are confused, Lingo :biggrin:
No sane programmer does a
sub rsp, 256 just for fun. The PROLOGUE macro can handle that perfectly.
Truth is, however, that MASM handles the MSG structure wrongly:
WinMain proc
LOCAL before, msg:MSG, after
Print Str$("MSG=%i bytes\n", MSG)44 bytes with a recent (2021) ML64.exe, despite the /Zp8 option set.
UAsm and AsmC do it correctly, with 48 bytes.
Re the lPrivate member, see WinUser.h:
typedef struct tagMSG {
HWND hwnd;
UINT message;
WPARAM wParam;
LPARAM lParam;
DWORD time;
POINT pt;
#ifdef _MAC
DWORD lPrivate;
#endif
} MSG, *PMSG, NEAR *NPMSG, FAR *LPMSG;It's an old MacIntosh thing (https://stackoverflow.com/questions/2376478/whats-with-ifdef-mac-in-windows-header-files), and if Micros*t ever decided to let
Windows write to that member (what for?), it would break tons of "professional" software, including MS Office.
JJ asks:
QuoteOne "advantage" of the 64-bit ABI is that people who cannot count to 12 (CreateWindowEx) or to 14 (CreateFontA) are not immediately being punished with an imbalanced stack; so the crash may happen a bit later :bgrin:
JJ answers himself:
QuoteNo sane programmer does a sub rsp, 256 just for fun. The PROLOGUE macro can handle that perfectly.
Your confused answers are just blah,blah... and not related to the main question of switching from masm32 to masm64 and to use clean code without macros :sad:
It works!!
Thank you, _japheth - I'm obliged :winking:
Quote from: lingo on November 14, 2023, 03:06:29 PMYou'd be better off stopping with masm32 examples and moving to masm64 if you want to stay up to date.
Soon masm32 will be only history just like 16 bit DOS Programming.
One small thing, and this is admittedly a side issue: like the song says, it ain't necessarily so (what you said about the obsolescence of 32-bit programming).
Specific example: I worked for two companies that sold media-conversion systems for PCs. One thing they both offered were 8-inch floppy systems, so you could read, f'rinstance, a disk from a Wang word processor on your PC. (I wonder how many folks here remember those big ol' floppies, or even the later 5-1/4" ones?)
The conventional wisdom in the industry was that these disks would become totally obsolete somewhere in the early 1990s. Guess what? We were still selling those systems well into the 2000s. (Some of the biggest users were video production houses that were still using DEC PDP-11 systems for their edit lists, stored on 8" floppy.)
We also sold lots of 9-track tape systems for PC well into the 2000s.
So be careful when you claim that something is about to become a dinosaur ...
I remember one thing about those 8" floppies was just how bulletproof they were. Once when we were doing development on a system we wanted to see how the disk drive would respond to read errors. My job was to take a floppy and mutilate it. I put it on the carpet and ran the casters of my office chair over it a bunch of times. When we went to read it, there were still zero errors. Those things were amazing. (Probably because they were so low density compared to later floppies.)
I understand your memories of youth which are so far away from today's dynamics. :undecided:
https://www.youtube.com/watch?v=mrvuLFTRlVA (https://www.youtube.com/watch?v=mrvuLFTRlVA)
https://www.youtube.com/watch?v=med9jOQ3j-w (https://www.youtube.com/watch?v=med9jOQ3j-w)
Nothing like a backhanded insult, eh? But no problemo, I don't take it personally.
BTW, that second video you posted was the first time I ever saw an actual Wang word processor. We just made the conversion stuff--8" diskette drive, PC adapter board and software.
If I were a betting man I'd wager that 32-bit Windows programming will survive well into the 2030s (assuming there's anything resembling a planet by then).
Hello
I hope I don't bother you too much, but I have one more problem. When creating a new dialog box class, when should my window procedure call the function DefDlgProc? If it mustn't be called by a dialog box procedure (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-defdlgprocw), how can it be fine to use it to provide default processing for any messages that a custom dialog box does not process, which Microsoft suggests here (https://learn.microsoft.com/en-us/windows/win32/dlgbox/dlgbox-programming-considerations#custom-dialog-boxes) (paragraph 4, sentence 2)? I'd like to rewrite PROG2.ASM to define a custom icon, but, after registering a custom dialog box class and rewriting my dialog procedure to make it look more like the WndProc function shown below, I cannot get anything to work because – depending on whether I call DefDlgProc – my main window is now either not displayed at all, or the program doesn't even start. When the function is not called, it looks like the program processes only the messages WM_GETMINMAXINFO, WM_NCCRERATE, WM_NCCALCSIZE, WM_CREATE, and then enters an infinite loop trying to process the message WM_SETFONT. When the function is invoked, however, the whole program simply crashes with the error "A new guard page for the stack cannot be created", which seems to prove that the function really is run recursively until it overflows the stack. However, if instead of calling DefDlgProc, I call DefWindowProc, everything works as expected. So, if the CLASS statement is said to convert a dialog to a window (https://learn.microsoft.com/en-us/windows/win32/menurc/class-statement#remarks), how should I (semantically) interpret Microsoft's recommendations such as this (https://learn.microsoft.com/en-us/windows/win32/dlgbox/dlgbox-programming-considerations#custom-dialog-boxes) one? That is, in the sentence "The application-defined window class allows the application to define a window procedure for the dialog box and process messages before sending them to the dialog box procedure", what is the dialog box procedure? And lastly, is it really necessary for the WndProc procedure to process the WM_DESTROY command?
WndProc PROC hWin:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
mov eax, uMsg
.IF eax == WM_INITDIALOG
Invoke InitGUI, hWin
.ELSEIF eax == WM_COMMAND...
.ELSEIF eax == WM_CLOSE
Invoke CDCloseFile
Invoke DestroyWindow, hWin
.ELSEIF eax == WM_DESTROY
Invoke PostQuitMessage, NULL
.ELSE
Invoke DefWindowProc, hWin, uMsg, wParam, lParam
ret
.ENDIF
xor eax, eax
ret
WndProc ENDP
WM_INITDIALOG should return TRUE
I know
Quote from: kkurkiewicz on December 03, 2023, 12:32:51 AMis it really necessary for the WndProc procedure to process the WM_DESTROY command?
If you don't, you will never exit your message loop:
.While 1
invoke GetMessage, addr msg, 0, 0, 0
inc eax
shr eax, 1
.Break .if Zero? ; 0 (OK) or -1 (error)
invoke TranslateMessage, addr msg
invoke DispatchMessage, addr msg
.EndwCheck the attachment, line 69.
Re other questions, I've always avoided dialogs. They work, but a regular window is hardly more complicated, and much more controllable.
But shouldn't the PostQuitMessage function be invoked only as a response to receiving WM_CLOSE?
No. You can handle WM_CLOSE but you don't have to. If you don't handle WM_DESTROY, your program will be stuck, and only Task Manager or Ctrl C can end it.
Quote from: jj2007 on December 03, 2023, 07:38:49 AMNo. You can handle WM_CLOSE but you don't have to. If you don't handle WM_DESTROY, your program will be stuck, and only Task Manager or Ctrl C can end it.
My programs (dialog-based) never handle
WM_DESTROY and yet they never get "stuck". They work just fine.
Unless I'm missing something here.
My typical message handling for closing time is this:
MOV EAX, uMsg
CMP EAX, WM_CLOSE
JE do_close
. . . . .
do_close:
INVOKE PostQuitMessage, NULL
MOV EAX, TRUE
RET
which works in all cases.
(This is assuming I want to end the program here. If I just want to close the dialog, I call
EndDialog() instead,)
Quote from: TimoVJL on December 03, 2023, 12:41:49 AMWM_INITDIALOG should return TRUE
That only affects how the dialog manager sets the keyboard focus:
QuoteThe dialog box procedure should return TRUE to direct the system to set the keyboard focus to the control specified by wParam. Otherwise, it should return FALSE to prevent the system from setting the default keyboard focus.
If dialog have message loop, DefWindowProc is useless ?
Those are not used same time ?
Very good question. Don't know the answer.
One thing: in my dialog-based programs (where the dialog is the main program window and there's no message loop), I simply return zero rather than call DefDlgProc() for any unhandled messages. This seems to work fine, although I'm quite willing to admit that this may not be the right thing to do under all circumstances ...
TimoVJL—the point is that DefWindowProc should apparently never be used as the default message-processing method when the window is a dialog box with a private window class. From the second article I linked:
QuoteThe window procedure for the custom dialog box has the same parameters and requirements as any other window procedure. Unlike other window procedures, however, the window procedure for this dialog box should call the DefDlgProc function instead of the DefWindowProc function for any messages it does not process. DefDlgProc carries out the same default message processing as the window procedure for the predefined dialog box, which includes calling the dialog box procedure.
Note, however, that what they refer to as "window procedure" is the callback function that you pass to CreateDialog. So, the question is: Should this function still process the messages WM_INITDIALOG and WM_CLOSE, or should it only process the messages WM_CREATE and WM_DESTROY?
Yes; that window procedure (the dialog is in fact a window, with a HWND and all that) is your dialog procedure, which is a standard Windows callback procedure:
TheDialogProc PROC hWin:HWND, uMsg:DWORD, wParam:DWORD, lParam:DWORD
except that it is a special window proc, one which is controlled by the "dialog manager" rather than just running from a user's message loop. Which is why you're spozed to use DefDlgProc() instead of DefWindowProc(), and some other variations from the regular window procedure handling.
And of course it should process all those dialog-related messages, like WM_INITDIALOG. As well as any other message you need handled, like any messages from child windows (controls) (and certainly WM_CLOSE).
So how to explain that the only way to get it to work is to call DefWindowProc? (Please note that the WndProc procedure I included in my question comes from fearless' CD utility, which is also "just" a dialog with a custom window class.)
Quote from: kkurkiewicz on December 03, 2023, 12:32:51 AM[...] I'd like to rewrite PROG2.ASM to define a custom icon, but, after registering a custom dialog box class and rewriting my dialog procedure to make it look more like the WndProc function shown below, I cannot get anything to work because – depending on whether I call DefDlgProc – my main window is now either not displayed at all, or the program doesn't even start. [...]
Question for you: why are you registering a custom dialog box class? I think that may be the source of your problems.
Unless you have some legitimate need to do this, I would try just creating a standard dialog and seeing if that works.
I don't know if it's related or not, but I do know from experience working with dialogs that if I have a child window (control) in the dialog that's user-defined (i.e., not one of the standard Windows classes), the dialog won't work if I don't register the class for that control
before invoking the dialog. I wonder if this is the same problem you might be having.
Quote from: NoCforMe on December 03, 2023, 08:53:58 AMMy programs (dialog-based) never handle WM_DESTROY and yet they never get "stuck". They work just fine.
Unless I'm missing something here.
My typical message handling for closing time is this:
Code Select Expand
MOV EAX, uMsg
CMP EAX, WM_CLOSE
JE do_close
. . . . .
do_close:
INVOKE PostQuitMessage, NULL
MOV EAX, TRUE
RET
which works in all cases.
You can send the PostQuitMessage also in the WM_CREATE handler, and it will work fine :thumbsup:
Quote from: NoCforMe on December 03, 2023, 10:06:15 AMAnd of course it should process all those dialog-related messages, like WM_INITDIALOG. As well as any other message you need handled, like any messages from child windows (controls) (and certainly WM_CLOSE).
Handling WM_CLOSE is optional, handling WM_DESTROY isn't.
Quote from: jj2007 on December 03, 2023, 11:18:58 AMHandling WM_CLOSE is optional, handling WM_DESTROY isn't.
Hate to argue the point w/you, but how is it that
none of my dialog-based programs even mention
WM_DESTROY and yet they work fine?
So far as I know, if
you don't handle it and if you pass it back to the dialog manager, they'll take care of it for you with its default processing.
Experiment: try commenting out your
WM_DESTROY handler in one of your programs and see if it still works (assuming that your handler for that message doesn't do something crucial to your program).
Quote from: NoCforMe on December 03, 2023, 12:31:17 PMnone of my dialog-based programs even mention WM_DESTROY and yet they work fine
These are the subtle differences between dialogs and real windows.
P.S., Raymond Chen: Sending a window a WM_DESTROY message is like prank calling somebody pretending to be the police (https://devblogs.microsoft.com/oldnewthing/20110926-00/?p=9553)
But none of my non-dialog windowed programs mention
WM_DESTROY either, and they too work fine ...
As usual, excellent explanation by R. Chen in that article you linked to. What he writes at the end convinces me that you do not need to handle WM_DESTROY explicitly:
QuoteYou can invent a private message for this, or you can take advantage of the fact that the default behavior of the WM_CLOSE message is to destroy the window. Since our window procedure doesn't override WM_CLOSE, the message will fall through to DefWindowProc which will convert the WM_CLOSE into a DestroyWindow.
This tells me that you can just let WM_CLOSE take care of WM_DESTROY by dropping through to DefXXXProc().
Quote from: NoCforMe on December 03, 2023, 12:39:43 PMBut none of my non-dialog windowed programs mention WM_DESTROY either, and they too work fine ...
Sure :thumbsup:
Quote from: jj2007 on December 03, 2023, 11:18:58 AMYou can send the PostQuitMessage also in the WM_CREATE handler, and it will work fine :thumbsup:
Btw you can also use
invoke ExitProcess, 0 in your WM_CLOSE handler, and it will work fine :thumbsup:
P.S. this is what happens
after the WM_CLOSE message:
# wParam lParam uMsg
msg 476 A080F060 0001038B WM_MENUSELECT
msg 490 0001038B 20000000 WM_UNINITMENUPOPUP
msg 491 00000000 00000000 WM_CAPTURECHANGED
msg 492 FFFF0000 00000000 WM_MENUSELECT
msg 493 00000000 00000000 WM_EXITMENULOOP
msg 494 0000F060 013B029E WM_SYSCOMMAND
msg 495 00000000 00000000 WM_CLOSE <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
msg 496 00000000 00000000 WM_UAHDESTROYWINDOW
msg 497 00000000 0019F8C4 WM_WINDOWPOSCHANGING
msg 498 00000000 0019F8C4 WM_WINDOWPOSCHANGED
msg 499 00000000 00000000 WM_NCACTIVATE
msg 500 00000000 0019F1D4 WM_UAHINITMENU
msg 501 00000000 0019F4EC WM_UAHINITMENU
msg 502 00000000 0019F4EC WM_UAHDRAWMENU
msg 503 00000000 0019F484 WM_UAHDRAWMENUITEM
msg 504 00000000 00000000 WM_ACTIVATE
msg 505 00000000 00001DAC WM_ACTIVATEAPP
msg 506 02000067 0070026C WM_COMMAND: 00000200h ID 103
msg 507 00000000 00000000 WM_DESTROY
msg 508 00000000 00000000 WM_NCDESTROYLots of totally useless stuff ;-)
Quote from: NoCforMe on December 03, 2023, 11:08:39 AM[W]hy are you registering a custom dialog box class?
I know that in order to define a custom icon, I could simply load the icon from my exe file and set it by then sending WM_SETICON to the dialog, but I'd still like to understand what the purpose of DefDlgProc is. At the time when I was typing my new question, I was still convinced that it is necessary for my callback function to invoke DefDlgProc, and I only realized that fearless' WndProc uses DefWindowProc when I included it in my question, but is solved my problem right away.
So you're using
DefWindowProc() in your
dialog procedure, is that correct? You're not supposed to do that; you should use
DefDlgProc() instead (the different flavor is on account of the dialog manager). But did you try that and it didn't work? That probably points to some other problem with your code. At least that's my guess ...
I don't use either of those in my dialog procedures; I just return zero for any unhandled messages. Seems to work fine. Have you tried that?
Sorry: what I just told you about using
DefDlgProc() was wrong. From Microsoft Learn (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-defdlgproca):
QuoteThe DefDlgProc function must not be called by a dialog box procedure; doing so results in recursive execution.
(I just discovered this the hard way: stack overflow.)
Fearless was 100% right. I just put
DefWindowProc() in another program where I was having severe problems with a listbox in a dialog, and it solved them.
So, now, how on earth should we adjust our programs to make them conform with this (https://learn.microsoft.com/en-us/windows/win32/dlgbox/dlgbox-programming-considerations#custom-dialog-boxes)? From paragraph 4:
QuoteThe window procedure for the custom dialog box has the same parameters and requirements as any other window procedure. Unlike other window procedures, however, the window procedure for this dialog box should call the DefDlgProc function instead of the DefWindowProc function for any messages it does not process. DefDlgProc carries out the same default message processing as the window procedure for the predefined dialog box, which includes calling the dialog box procedure.
Hi Kamil
Can you post some test project? to know where you are.
HSE
prog--without class
prog (2)--with class
Quote from: kkurkiewicz on December 05, 2023, 05:50:47 AMSo, now, how on earth should we adjust our programs to make them conform with this (https://learn.microsoft.com/en-us/windows/win32/dlgbox/dlgbox-programming-considerations#custom-dialog-boxes)? From paragraph 4:
QuoteThe window procedure for the custom dialog box has the same parameters and requirements as any other window procedure. Unlike other window procedures, however, the window procedure for this dialog box should call the DefDlgProc function instead of the DefWindowProc function for any messages it does not process. DefDlgProc carries out the same default message processing as the window procedure for the predefined dialog box, which includes calling the dialog box procedure.
I do not understand this at all, as it's completely contradictory with the statement I posted which tells us
not to ever use
DefDlgProc() in a dialog procedure.
So don't use it. I don't think you need it. I'm still unclear as to why you're creating a custom dialog class here.
DefWindowProc() works well in a dialog procedure. Use it.
Which one of the programs you posted works?
Quote from: NoCforMe on December 05, 2023, 08:31:22 AMWhich one of the programs you posted works?
They both work.
Wow :cool:
DLGPROC PROC
PUSH EBP
MOV EBP, ESP
PUSH EBX
PUSH ESI
PUSH EDI
;-----------------------------------
CMP DWORD PTR [EBP+0CH], WM_CLOSE
JE WMCLOSE
CMP DWORD PTR [EBP+0CH], WM_INITDIALOG
JE WMINITDIALOG
Quote from: kkurkiewicz on December 05, 2023, 07:42:26 AMprog--without class
prog (2)--with class
So far I understand you cant' use CreateDialog variations without a parent window.
You must try with DialogBox variations (don't needed any additional message loop).
Quote from: HSE on December 05, 2023, 09:22:02 AMQuote from: kkurkiewicz on December 05, 2023, 07:42:26 AMprog--without class
prog (2)--with class
So far I understand you cant' use CreateDialog variations without a parent window.
Well, he's using
CreateDialogParam() with no parent window, and JJ says the programs work, so ...
QuoteYou must try with DialogBox variations (don't needed any additional message loop).
That's what I use (
DialogBoxIndirectParam() ).
Is it true that the CreateDialogXXX() functions require a message loop and the DialogBoxXXX() ones don't?
Damn Micro$oft for so poorly naming the dialog functions. The CreateXXX ones are non-modal while the DialogXXX ones are modal. Why couldn't they have used the term "modal" and "nonModal" to distinguish the two?
Quote from: NoCforMe on December 05, 2023, 09:32:59 AMWell, he's using CreateDialogParam() with no parent window, and JJ says the programs work, so ...
Yes, my mistake, is working :eusa_boohoo:
OK. The confusion level here is decreasing! Nice.
Apparently DefDlgProc is very specific for DialogBox variations, not for CreateDialog variations.
Or is used when Dialog have a parent window ¿?
Quote from: NoCforMe on December 05, 2023, 10:25:38 AMThe confusion level here is decreasing!
Just read the remarks section of DefDlgProc (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-defdlgprocw#remarks), and your confusion level will rise to record highs :cool:
Yes, indeed, Jochen. Guiness-book-of-world record highs.
Does anyone here know when (and where) one
should use
DefDlgProc()? For sure?
All that they (Microsoft Learn) write implies that it's to be used (only?) with custom dialog classes. But it should be emphasized again that they write
QuoteThe DefDlgProc function must not be called by a dialog box procedure; doing so results in recursive execution.
So if you can't use it an a dialog procedure (including, I'm assuming, a custom dialog proc), then where the hell would you use it?
Raymond Chen addresses this issue here (https://devblogs.microsoft.com/oldnewthing/20031113-00/?p=41843), here (https://devblogs.microsoft.com/oldnewthing/20031112-00/?p=41863), here (https://devblogs.microsoft.com/oldnewthing/20031107-00/?p=41923), and here (https://devblogs.microsoft.com/oldnewthing/20100215-00/?p=14943). I haven't had time to go through all these and digest them, but I'm sure the answer to our confusion is in there somewhere ...
Check out that first linked article. I'm pretty sure the answers to our questions are all in there. (A 20-year old post!)
Quote from: NoCforMe on December 05, 2023, 11:33:12 AMDoes anyone here know when (and where) one should use DefDlgProc()
Actually, I don't know. What I
do know is that under the hood of my dialog macros (https://www.jj2007.eu/MasmBasicQuickReference.htm#Mb1012) there is not a trace of DefDlgProc, DefWndProc or CallWindowProc. They just
return (and have done so successfully for many years).
invoke DialogBoxIndirectParamW, rv(GetModuleHandle, 0), [esi], DlgOwner, MbDlgP, esi
...
MbDlgP proc hDlg, uMsg, wParam, lParam
...
xor eax, eax
xchg eax, [esi.MbDLG.dlgRetEax]
pop ebx ; uses esi edi ebx
pop edi
pop esi
leave
retn 4*4 ; no DefWindowProc, DefDlgPoc or CallWindowProc...
MbDlgP endpSee DialogBoxIndirectParam (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-dialogboxindirectparama) and DlgProc (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nc-winuser-dlgproc):
QuoteTypically, the dialog box procedure should return TRUE if it processed the message, and FALSE if it did not. If the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message.
If the dialog box procedure processes a message that requires a specific return value, the dialog box procedure should set the desired return value by calling SetWindowLong(hwndDlg, DWL_MSGRESULT, lResult) immediately before returning TRUE. Note that you must call SetWindowLong immediately before returning TRUE; doing so earlier may result in the DWL_MSGRESULT value being overwritten by a nested dialog box message.
JJ, I can't tell from that fragment whether that code is for a handled message or an unhandled one.
I think we established (maybe in my other thread about listbox problems) that one should use DefWindowProc() for unhandled messages, correct? After all, that's exactly what cured the problem I was having with that listbox not working correctly.
Quote from: NoCforMe on December 05, 2023, 02:33:58 PMI think we established (maybe in my other thread about listbox problems) that one should use DefWindowProc() for unhandled messages, correct?
I don't know what "we" established, but Microsoft says (see above) you should return zero if you don't handle the message.
Quote from: NoCforMe on December 05, 2023, 02:33:58 PMI can't tell from that fragment whether that code is for a handled message or an unhandled one
See dlgRetEax
Not being a MasmBasic user, I have no idea what [esi.MbDLG.dlgRetEax] means.
Quote from: NoCforMe on December 05, 2023, 06:11:37 PMNot being a MasmBasic user, I have no idea what [esi.MbDLG.dlgRetEax] means.
While I am an avid MasmBasic user, I also had no idea what
[esi.MbDLG.dlgRetEax] means (I wrote this code over 10 years ago (https://masm32.com/board/index.php?msg=6464)). My best guess would be that
dlgRetEax has something to do with Microsoft's idea on how to handle dialog messages :cool:
Quote from: jj2007 on December 05, 2023, 02:12:27 PMSee DialogBoxIndirectParam (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-dialogboxindirectparama) and DlgProc (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nc-winuser-dlgproc):
QuoteTypically, the dialog box procedure should return TRUE if it processed the message, and FALSE if it did not. If the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message.
Quote from: kkurkiewicz on December 05, 2023, 05:50:47 AMSo, now, how on earth should we adjust our programs to make them conform with this (https://learn.microsoft.com/en-us/windows/win32/dlgbox/dlgbox-programming-considerations#custom-dialog-boxes)? From paragraph 4:
QuoteThe window procedure for the custom dialog box has the same parameters and requirements as any other window procedure. Unlike other window procedures, however, the window procedure for this dialog box should call the DefDlgProc function instead of the DefWindowProc function for any messages it does not process. DefDlgProc carries out the same default message processing as the window procedure for the predefined dialog box, which includes calling the dialog box procedure.
There's quite a bit confusion here. Actually, it's quite simple - that's why I remember this stuff although I didn't do any serious Windows programming in the last 10 years.
If you're defining a custom dialog box window class, you'll have to provide a window proc for it. This proc is NOT to be confused with a "dialog proc" - you still have to provide such a dialog proc as a parameter for the DialogBoxXXX() or CreateDialogXXX() functions. Instead, the address of your window proc ( of your custom dialog box window class ) is delivered in the WNDCLASS.lpfnWndProc struct member, and the struct itself is - of course - the parameter for a RegisterClass() function call.
In the simplest case, your custom dialog box window proc does nothing but calling DefDlgProc():
MyPreciousCustomDialogWndProc PROC hWnd:dword, uMsg:dword, wParam:dword, lParam:dword
invoke DefDlgProc, hWnd, uMsg, wParam, lParam
ret
MyPreciousCustomDialogWndProc ENDP
Of course you can handle some messages in this proc - but, for example, you cannot handle WM_INITDIALOG here, because that message is created inside DefDlgProc() and then routed to YOUR dialog proc.
:thumbsup:
It's working with DefWindowProc (and all messages process) in the CLASS proc, and DefDlgProc (alone) in the DLG proc.
I know this isn't easy to understand. Microsoft (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nc-winuser-dlgproc) says "DLGPROC callback function: Application-defined callback function used with the CreateDialog and DialogBox families of functions".
"Family" includes the CALL CreateDialogParamA@20 used by the OP.DLGPROC Dlgproc;
INT_PTR Dlgproc(
HWND unnamedParam1,
UINT unnamedParam2,
WPARAM unnamedParam3,
LPARAM unnamedParam4
)Looks like an ordinary WndProc, right? But it isn't. You get the params but you are
not supposed to pass them on to DefDlgProc, DefWindowProc or CallWindowProc.
If you want to react to a message, there are two ways to do so:
1. tell Windows that you did your own processing:
QuoteTypically, the dialog box procedure should return TRUE if it processed the message, and FALSE if it did not. If the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message.
2. tell Windows that you did your own processing
and want to return a value:
QuoteIf the dialog box procedure processes a message that requires a specific return value, the dialog box procedure should set the desired return value by calling SetWindowLong(hwndDlg, DWL_MSGRESULT, lResult) immediately before returning TRUE.
See
Remarks:
QuoteAlthough the dialog box procedure is similar to a window procedure, it must not call the DefWindowProc function to process unwanted messages. Unwanted messages are processed internally by the dialog box window procedure.
Meaning that dialogs do have their own WndProc, but you won't see them, and you shouldn't use them. On entry to that invisible WndProc, Windows calls your DLGPROC, and if it returns FALSE (eax==0), it jumps straight to its own, private
invoke DefWindowProc. You are not supposed to intervene.
It just struck me—DefDlgProc must be the system predefined procedure for the standard dialog box class, as alluded to in the last paragraph of When to Use a Dialog Box (https://learn.microsoft.com/en-us/windows/win32/dlgbox/about-dialog-boxes#when-to-use-a-dialog-box) and clearly [sic] stated here (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-defdlgprocw#remarks). _japheth—I think you are right :thumbsup:
Quote from: kkurkiewicz on December 06, 2023, 06:34:12 AMDefDlgProc must be the system predefined procedure for the standard dialog box class
Yes.
Quote from: jj2007 on December 06, 2023, 03:31:52 AMIf the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message.
QuoteThe DefDlgProc function (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-defdlgprocw#remarks) is the window procedure for the predefined class of dialog box. This procedure provides internal processing for the dialog box by forwarding messages to the dialog box procedure and carrying out default processing for any messages that the dialog box procedure returns as FALSE.
Those who use message loop, IsDialogMessage() is usefull for input.
So to summarize, when something happens to the dialog, the message is first sent to the internal procedure, and only then the processing is delegated to the function defined in the program. If the application-defined procedure returns 0, the message is processed by the internal procedure; otherwise, the internal procedure doesn't handle the message.
Quote from: kkurkiewicz on December 06, 2023, 06:56:35 AMthe processing is delegated to the function defined in the program
More precisely, "delegated" means that in the invisible internal WndProc you would find at the very beginning an
invoke UserDefinedDlgProc, hWnd, uMsg, wParam, lParamThat proc (your proc) is not supposed to call DefDlgProc or DefWindowProc; instead, it just returns FALSE (=do default processing) or TRUE (=user had a handler, don't process).
For a few messages where returning something concrete (e.g. a brush handle) makes sense, you can do that with an
invoke SetWindowLong, hwndDlg, DWL_MSGRESULT, hBrush immediately before returning TRUE.