Button refusing to be disabled

[Landsfiskalen]

Changed my code to use constants for the win-controls. Still no go though.  :( The Unpack-button still refuse to be disabled. If I put in a MessageBox call I can see ALL the buttons greyed out. So feels like an update problem? But I do a call to invoke UpdateWindow,hWindow, so should work. 

I use the wNotifyCode mainly for comboboxes and other controls sometimes. You can still specify a control id when creating it using CreateWindowEx - its the third last parameter: hMenu - which can be a control id, like iDC_BtnPack or IDC_BtnUnpack or whatever.

Code Select Expand

.CONST
IDC_BtnPack EQU 1001
IDC_BtnUnpack EQU 1002

.DATA
ButtonClass db 'button',0
szPackButton db 'Pack',0
szUnpackButton db 'Unpack',0

.DATA?
hUnpackButton dd ?
hPackButton dd ?

.CODE
WndProc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

    LOCAL wNotifyCode:DWORD

    mov eax, uMsg
    .IF eax==WM_INITDIALOG
        ; do init stuff here, including possibly creating our btn controls here (or somewhere else perhaps, assuming we have hInstance already stored)
        invoke CreateWindowEx,0,ADDR ButtonClass,ADDR szPackButton,WS_CHILD or WS_VISIBLE or WS_TABSTOP or WS_DISABLED,350,169,75,24,hWin,IDC_BtnPack,hInstance,NULL
        mov hPackButton,eax
        invoke CreateWindowEx,0,ADDR ButtonClass,ADDR szUnpackButton,WS_CHILD or WS_VISIBLE or WS_TABSTOP or WS_DISABLED,350,169,75,24,hWin,IDC_BtnUnpack,hInstance,NULL
        mov hUnpackButton,eax


    .ELSEIF eax == WM_COMMAND
        mov eax, wParam
        shr eax, 16
        mov wNotifyCode, eax
        mov    eax,wParam
        and    eax,0FFFFh
        .IF eax==IDC_BtnUnpack
                ; do something here

        .ELSEIF eax==IDC_BtnPack
                ; do something else here

        .ELSEIF eax==IDC_SomeOtherControl
                ; maybe we check to enable disable controls here, like if user has succesfully opened a file - allow unpack button?

        .ENDIF
         
        ; other code here onwards
       

[dedndave]

as it happens, BN_CLICKED is 0   

so - no need to check it because if the entire dword is the control ID, then it is a BN_CLICKED notification
however, you are checking against the handle value
use the control ID's, instead

http://msdn.microsoft.com/en-us/library/windows/desktop/ms647591%28v=vs.85%29.aspx

notice that, for menu items, the wParam high word is also 0
for controls, the high word is the notification code (BN_CLICKED = 0)
just make sure to use different ID values for controls and menu items

Code Select Expand

IDC_BUTTON1   EQU 101
IDC_BUTTON2   EQU 102
IDM_MENUITEM1 EQU 103
IDM_MENUITEM2 EQU 104

Code Select Expand

    mov     eax,uMsg
    .if eax==WM_COMMAND
        mov     edx,wParam
        .if edx==IDC_BUTTON1

        .elseif edx==IDC_BUTTON2

        .elseif edx==IDC_MENUITEM1

        .elseif edx==IDC_MENUITEM2

[jj2007]

But I do a call to invoke UpdateWindow,hWindow, so should work. 

UpdateWindow is needed only on extremely rare occasions. You would have had a solution to your problem a long time ago if
a) you would do error checking, e.g. with the Masm32 macro LastError$()
b) you would post your complete code.

Guessing around like you currently do is just wasting everybody's time, including your own.

[dedndave]

Hi!
I don't user resources, I create them using CreateWindowsEx. Looks like this:

Code Select Expand


invoke CreateWindowEx,0,ADDR ButtonClass,ADDR szPackButton,WS_CHILD or WS_VISIBLE or WS_TABSTOP or WS_DISABLED,350,169,75,24,hWindow,NULL,hInst,NULL
mov hPackButton,eax


when you use CreateWindowEx, and the class pointer points to a string that defines a system-defined control,
the hMenu argument of CreateWindowEx should be the control ID
(the system class string for buttons is "button",0)

http://msdn.microsoft.com/en-us/library/windows/desktop/ms632680%28v=vs.85%29.aspx

Code Select Expand

IDC_BUTTON1   EQU 101

Code Select Expand

        invoke  CreateWindowEx,0,ADDR ButtonClass,ADDR szPackButton,
                WS_CHILD or WS_VISIBLE or WS_TABSTOP or WS_DISABLED,
                350,169,75,24,hWindow,IDC_BUTTON1,hInst,NULL

now, you can use WM_COMMAND wParam to check the control ID number   :t

[Landsfiskalen]

Hi!
I've made those changes, so I have equates for all controls. Still no go. :( Here's the code if anyone have any ideas.

Hi!
I don't user resources, I create them using CreateWindowsEx. Looks like this:

Code Select Expand


invoke CreateWindowEx,0,ADDR ButtonClass,ADDR szPackButton,WS_CHILD or WS_VISIBLE or WS_TABSTOP or WS_DISABLED,350,169,75,24,hWindow,NULL,hInst,NULL
mov hPackButton,eax


when you use CreateWindowEx, and the class pointer points to a string that defines a system control,
the hMenu argument of CreateWindowEx should be the control ID
(the system class string for buttons is "button",0)

http://msdn.microsoft.com/en-us/library/windows/desktop/ms632680%28v=vs.85%29.aspx

Code Select Expand

        invoke  CreateWindowEx,0,ADDR ButtonClass,ADDR szPackButton,
                WS_CHILD or WS_VISIBLE or WS_TABSTOP or WS_DISABLED,
                350,169,75,24,hWindow,IDC_BUTTON1,hInst,NULL

now, you can use WM_COMMAND wParam to check the control ID number   :t

[dedndave]

first - no need to open a ".const" section for EQUates
won't hurt anything, but EQUates are simply assemble-time constants
they don't create any run-time data

your code looks better,
however, ALL system-defined controls should have an ID
this includes edit controls and static controls (used as labels in your program)

[dedndave]

i want to clarify....

in fact, any child window (which includes controls) should probably have an ID assigned
i have seen people use 0 as an ID number, but i wouldn't do that   :P

so, the hMenu argument for CreateWindowEx....
for top-level windows, either 0 or a menu handle
for child-level windows, a unique control ID number from 1 to 65535

there is actually no rule that says they have to be unique, but it will make more sense if they are   :t
if you run out of numbers, you have too many controls - lol

[jj2007]

Still no go. :( Here's the code if anyone have any ideas.

The unpack button gets disabled or enabled, at least on my Win7-64, and I see no reason why it shouldn't. Try this:

      .if wNotifyCode == BN_CLICKED
                  .if eax == IDC_BUTTON_BROWSE
            if 1
                  .data?
                  toggle dd ?
                  .code
                  not toggle
                  invoke EnableWindow,hUnpackButton, toggle
                  invoke EnableWindow,hPackButton, toggle
            else
                  mov ofn.lStructSize,SIZEOF ofn
                  push hWnd
                  pop ofn.hwndOwner
                  push hInstance
                  pop ofn.hInstance
                  mov ofn.lpstrFilter, OFFSET szFilterString
                  mov ofn.lpstrFile, OFFSET buffer
                  mov ofn.nMaxFile,MAXSIZE
                  mov ofn.Flags, OFN_FILEMUSTEXIST or \
                  OFN_PATHMUSTEXIST or OFN_LONGNAMES or\
                  OFN_EXPLORER or OFN_HIDEREADONLY
                  mov ofn.lpstrTitle, OFFSET szOpenFileTitle
                  invoke GetOpenFileName, ADDR ofn
                  .if eax==TRUE
                        invoke SendMessage,hInputEdit,WM_SETTEXT,0,ADDR buffer
                        invoke EnableWindow,hPackButton,TRUE
                        invoke EnableWindow,hUnpackButton,TRUE
                  .endif
            endif     

[dedndave]

ok - had a little time to spend on this
cleaned up the code a bit
i also create all the controls in a PROC, and call it from WM_CREATE (and added ID's for all controls)

i think a big problem was the use of tabs - and improper indentation in WndProc
i am a bit OCD about tabs   :lol:
getting the indents to align helped me find an .endif that was out of place

Code Select Expand

       ;     .endif             this one was a mistake, removed   <------------------

            .elseif eax==IDC_COMBOBOX_PROFILE
                ;IDC_COMBOBOX_PROFILE code

            .endif  ;end of IDC tests
        .endif      ;end of BN_CLICKED - added this one   <------------------

i also modified the structure of WndProc so each WM_ message may return seperate values in EAX

there are 2 places where...

Code Select Expand

        .if eax==0
            .break
        .endif

should be replaced with...

Code Select Expand

        .break .if (!eax)

i'll let you decide on that one

i also try to avoid using locals in WndProc and WinMain (especially WndProc)
that's another discussion   :P

[Landsfiskalen]

Wow! Thanks alot! Will have a proper look at this during the weekend. Thanks again! :)

ok - had a little time to spend on this
cleaned up the code a bit
i also create all the controls in a PROC, and call it from WM_CREATE (and added ID's for all controls)

i think a big problem was the use of tabs - and improper indentation in WndProc
i am a bit OCD about tabs   :lol:
getting the indents to align helped me find an .endif that was out of place

Code Select Expand

       ;     .endif             this one was a mistake, removed   <------------------

            .elseif eax==IDC_COMBOBOX_PROFILE
                ;IDC_COMBOBOX_PROFILE code

            .endif  ;end of IDC tests
        .endif      ;end of BN_CLICKED - added this one   <------------------

i also modified the structure of WndProc so each WM_ message may return seperate values in EAX

there are 2 places where...

Code Select Expand

        .if eax==0
            .break
        .endif

should be replaced with...

Code Select Expand

        .break .if (!eax)

i'll let you decide on that one

i also try to avoid using locals in WndProc and WinMain (especially WndProc)
that's another discussion   :P