Dialog box programming considerations

[zedd]

... and remove the Copy button ...

Not so fast. 
Use that button. In the WM_COMMAND handler for the button, use:

invoke  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. 

[NoCforMe]

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?

[...] 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?

[jj2007]

invoke  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. It's buggy.

[kkurkiewicz]

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.

[kkurkiewicz]

And regarding copying data to clipboard, is it really necessary to call Open-, Empty-, and CloseClipboard? Is the following code wrong?

Code Select Expand

; 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


[zedd]

And 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. 
I was just giving you an example of an alternative approach. 

[fearless]

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.

[jj2007]

And 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.

[NoCforMe]

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.

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".)

[NoCforMe]

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:

Code Select Expand

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


[jj2007]

Your code is in open contradiction to the Micros*t docs, though.

[TimoVJL]

If 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.

[kkurkiewicz]

Is the text fields being used like that?

It's the opposite. The program is not supposed to validate the codes but produce them

[NoCforMe]

Your 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.

[jj2007]

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.