MsgBox / CONTROL DISABLE bug!

[Mike Trader]

I have been trying to figure this out for days. I have a program that calls different functions depending on whats selected.

When I use MSGBOX, the selected function changes!!!

My program is very big, so I made this example to illustrate the problem.

I have tried different values for the control and i even moved the selection to a function outside of the callback function. No difference.

Just compile and hit the Run button to see the selection changed from 7 to 2 by using MSGBOX.

#COMPILE EXE "test.exe" ' Compile file as Specified Name
#INCLUDE "WIN32API.INC" ' Win API definitions

GLOBAL hDlg AS LONG, ConvMethod AS LONG

'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤'
FUNCTION ChooseConversion() AS LONG
CONTROL DISABLE hDlg, 100
MSGBOX STR$(ConvMethod) ' value of ConvMethod is changed here ????
MSGBOX STR$(ConvMethod)
IF ConvMethod = 1 THEN MSGBOX STR$(ConvMethod)+" called"
IF ConvMethod = 2 THEN MSGBOX STR$(ConvMethod)+" called"
IF ConvMethod = 3 THEN MSGBOX STR$(ConvMethod)+" called"
IF ConvMethod = 4 THEN MSGBOX STR$(ConvMethod)+" called"
IF ConvMethod = 5 THEN MSGBOX STR$(ConvMethod)+" called"
IF ConvMethod = 6 THEN MSGBOX STR$(ConvMethod)+" called"
IF ConvMethod = 7 THEN MSGBOX STR$(ConvMethod)+" called"
CONTROL ENABLE hDlg, 100
END FUNCTION

'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤'
CALLBACK FUNCTION MainCB() AS LONG
SELECT CASE CBMSG
CASE %WM_INITDIALOG
ConvMethod = 7 ' Starting Value
CONTROL SET CHECK hDlg, 107, 1 ' Starting position
END SELECT

SELECT CASE %WM_COMMAND
SELECT CASE CBCTL
CASE 100
CALL ChooseConversion
CASE 101 : ConvMethod = 1
CASE 102 : ConvMethod = 2
CASE 103 : ConvMethod = 3
CASE 104 : ConvMethod = 4
CASE 105 : ConvMethod = 5
CASE 106 : ConvMethod = 6
CASE 107 : ConvMethod = 7
CASE 124
DIALOG END hDlg
END SELECT
END SELECT

END FUNCTION

'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤'
FUNCTION PBMAIN
DIALOG NEW 0, "Bug Demo", 100, 60, 110, 140, 0 TO hDlg
CONTROL ADD BUTTON, hDlg, 100, "Run", 04, 20, 102, 14, 0

CONTROL ADD OPTION, hDlg, 101, "1", 10, 36, 30, 12, %WS_GROUP
CONTROL ADD OPTION, hDlg, 102, "2", 10, 48, 30, 12, 0
CONTROL ADD OPTION, hDlg, 103, "2", 10, 60, 30, 12, 0
CONTROL ADD OPTION, hDlg, 104, "4", 10, 72, 30, 12, 0
CONTROL ADD OPTION, hDlg, 105, "5", 10, 84, 30, 12, 0
CONTROL ADD OPTION, hDlg, 106, "6", 10, 96, 30, 12, 0
CONTROL ADD OPTION, hDlg, 107, "7", 10, 108, 30, 12, 0

CONTROL ADD BUTTON, hDlg, 124, "&Quit", 04, 124, 102, 14, 1
DIALOG SHOW MODAL hDlg CALL MainCB
END FUNCTION
'¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤'

------------------
Kind Regards
Mike

[Borje Hagsten]

Don't remember exactly, but think it is Windows "feature". When
setting Option control by code, all controls has to be set, even
if only one can be "TRUE". So you need to set the others to zero.

        CONTROL SET CHECK hDlg, 101, 0 ' Starting position
        CONTROL SET CHECK hDlg, 102, 0 ' Starting position
        CONTROL SET CHECK hDlg, 103, 0 ' Starting position
        CONTROL SET CHECK hDlg, 104, 0 ' Starting position
        CONTROL SET CHECK hDlg, 105, 0 ' Starting position
        CONTROL SET CHECK hDlg, 106, 0 ' Starting position
        CONTROL SET CHECK hDlg, 107, 1 ' Starting position

"Interesting" effect if one forget to set all controls when doing
it by code: try setting two of them with value 1.. (yes, you'll get
two marked Options..

Why this shows up on disabling ctl 100? Think it has to do with zorder.
Button with id 100 was first, but when disabled, next in line is 101,
which is first in WM_GROUP, so it passes on to next, 102 - Option 2..


------------------

[Mike Trader]

This is a Multi-legged "hidden" feature i take it!

Well your fix works. thx
Spent 3hrs on that. now Wheres the e-mail address for that anti-trust lobby ...

------------------
Kind Regards
Mike

[Borje Hagsten]

Yes, Windows has many legs to stumble upon. Far too many, IMHO..

Maybe PB can make sure CONTROL ADD OPTION/CHECKBOX also initiates
the controls to unselected status? Or at least include info about
this issue in next update of the documentation?

Otherwise, easy to forget when coding, with unpredictable and often
very hard-to-find errors as result, as we just have seen..


------------------

[Lance Edmonds]

Duely noted... thanks!

PS: I've asked for this to be built into DDT, but you can set the state for all radio OPTION buttons in a group with one call to the CheckRadioButton() api.

In the above code, the 7 lines of CONTROL SET CHECK could be replaced with

CALL CheckRadioButton(CBHNDL, 101, 107, 107)

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Bern Ertl]

Is it just me or is Mike's callback function structured strangely?
The way I read it, every call to the callback will trigger a check
of the SELECT CASE CBCTL structure even if the message is not
WM_COMMAND....

'Mike's original code
CALLBACK FUNCTION MainCB() AS LONG
SELECT CASE CBMSG
    CASE %WM_INITDIALOG
        ConvMethod = 7   ' Starting Value
        CONTROL SET CHECK hDlg, 107, 1 ' Starting position
END SELECT

SELECT CASE %WM_COMMAND
    SELECT CASE CBCTL
        CASE 100
             CALL ChooseConversion
        CASE 101 : ConvMethod = 1
        CASE 102 : ConvMethod = 2
        CASE 103 : ConvMethod = 3
        CASE 104 : ConvMethod = 4
        CASE 105 : ConvMethod = 5
        CASE 106 : ConvMethod = 6
        CASE 107 : ConvMethod = 7
        CASE 124
            DIALOG END hDlg
    END SELECT
END SELECT

shouldn't it be....

CALLBACK FUNCTION MainCB() AS LONG
SELECT CASE CBMSG
    CASE %WM_INITDIALOG
        ConvMethod = 7   ' Starting Value
        CONTROL SET CHECK hDlg, 107, 1 ' Starting position
    CASE %WM_COMMAND
        SELECT CASE CBCTL
            CASE 100 : CALL ChooseConversion
            CASE 101 : ConvMethod = 1
            CASE 102 : ConvMethod = 2
            CASE 103 : ConvMethod = 3
            CASE 104 : ConvMethod = 4
            CASE 105 : ConvMethod = 5
            CASE 106 : ConvMethod = 6
            CASE 107 : ConvMethod = 7
            CASE 124 : DIALOG END hDlg
        END SELECT
END SELECT

------------------
Bernard Ertl

[Lance Edmonds]

Yes Bern, you are correct... in his code, the SELECT CASE %WM_COMMAND statement is effectively redundant, exposing the SELECT CASE CBCTL block to be executed for every single message (ie, without regard to the %WM_COMMAND message or any notification message). Not good.

It probably would have been easier to spot if Mike used the [ code] and [ /code] UUB tages when posting his source code (as long as he maintains indentation in the code to start with, of course!)



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>