Announcement

**Rodney Hicks** · 22 Jul 2008, 07:41 PM

See
CONTROL GET CHECK

This is not the same as button check, it doesn't send messages to the cue, haven't used it for a while, so I don't have any handy code to display it.

Rod

PS You might check in the PB/Samples directory for a good example.

**Gösta H. Lovgren-2** · 22 Jul 2008, 08:02 PM

Charles,

To make the Dialog show, change the Option Id to 202 (from 102). Only change I made and it shows here. Strange {grin}.

{a few mins later}
Actually any id number other than 102 seems to work. (Strangerous and strangerouser)

=================================
"A witty saying proves nothing."
Voltaire (1694-1778)
=================================

**Charles Dietz** · 22 Jul 2008, 08:10 PM

That's it, Rod. Thank you. The following callback works as I wanted.

Code:

CALLBACK FUNCTION dialogProc()
   LOCAL n1, n2 AS LONG
   SELECT CASE CBMSG 
   CASE %WM_COMMAND
      IF CBCTLMSG = %BN_CLICKED THEN
         CONTROL GET CHECK CBHNDL, 101 TO n1
         CONTROL GET CHECK CBHNDL, 102 TO n2
         IF n1 THEN 
            DIALOG END CBHNDL, 1
         ELSEIF n2 THEN 
            DIALOG END CBHNDL, 2
         END IF  
      END IF
   END SELECT   
END FUNCTION

**Charles Dietz** · 22 Jul 2008, 08:24 PM

Gösta, I think you must have changed 102 to 202 in PBMAIN, without changing it in the callback.

**Gösta H. Lovgren-2** · 22 Jul 2008, 08:35 PM

Originally posted by Charles Dietz View Post

Gösta, I think you must have changed 102 to 202 in PBMAIN, without changing it in the callback.

That's right Charles. It's a mystery why it would have to be addressed in the CallBack to display the dialog. Or why the dialog would display with the id any number BUT 102.

Just a curiosity. Just for fun, try it yourself. The way I found it was changing both Option control ids and displayed them alongside the Buttons (after adding 100 to the hoirizontals). When I commented out the buttons, the options still displayed. After that it was just a matter of fooling around to find that 102 wouldn't display but anything else would.

Again, just a curiosity. Not bringing up "insects" or anything of that nature {grin}.

==========================================
"I loathe people who keep dogs.
They are cowards who haven't got the guts
to bite people themselves."
August Strindberg
==========================================

**Fred Buffington** · 22 Jul 2008, 09:17 PM

Originally posted by Gösta
After that it was just a matter of fooling around to find that 102 wouldn't display but anything else would.

Strange. The following works fine

Code:

#COMPILE EXE
#INCLUDE "win32api.inc"

FUNCTION PBMAIN()
   LOCAL hDlg, n AS LONG
   DIALOG NEW 0,"Print Reminders",,, 190, 100, %WS_SYSMENU TO hDlg
'   CONTROL ADD BUTTON, hDlg, 101, "Print number 1", 20, 10, 100, 25
'   CONTROL ADD BUTTON, hDlg, 102, "Print number 2", 20, 50, 100, 25
CONTROL ADD OPTION, hDlg, 101, "Print number 1", 20, 10, 100, 25, %WS_GROUP
CONTROL ADD OPTION, hDlg, 102, "Print number 2", 20, 50, 100, 25
   DIALOG SHOW MODAL hDlg, CALL dialogProc TO n
   MSGBOX STR$(n)
END FUNCTION

CALLBACK FUNCTION dialogProc()
   LOCAL lStatus&
   SELECT CASE CBMSG
   CASE %WM_COMMAND
'      IF CBCTLMSG = %BN_CLICKED THEN
'         IF CBCTL = 101 THEN
'            DIALOG END CBHNDL, 1
'         ELSEIF CBCTL = 102 THEN
'            DIALOG END CBHNDL, 2
'         END IF
'      END IF
       SELECT CASE CBCTL
         CASE 101
           CONTROL GET CHECK CBHNDL,101 TO lStatus&
           IF lStatus& THEN DIALOG END CBHNDL,1
         CASE 102
           CONTROL GET CHECK CBHNDL,102 TO lStatus&
           IF lStatus& THEN DIALOG END CBHNDL,2
       END SELECT
   END SELECT
END FUNCTION

**Dave Biggs** · 22 Jul 2008, 09:44 PM

Charles,

If you explicitly set one of the options your original code will work.

Code:

 
   CONTROL ADD OPTION, hDlg, 102, "Print number 2", 20, 30, 100, 25
   CONTROL SET OPTION hDlg, 102, 101, 102

%BN_CLICKED is sent by the option controls when they are clicked..

Code:

 
      IF CBCTLMSG = %BN_CLICKED THEN
         IF CBCTL = 101 THEN 
            'DIALOG END CBHNDL, 1
            Dialog Set Text CbHndl, Format$(CbCtl) + " Clicked!"
         ELSEIF CBCTL = 102 THEN 
            'DIALOG END CBHNDL, 2
            Dialog Set Text CbHndl, Format$(CbCtl) + " Clicked!"

But if there is no option set when the dialog is created %BN_CLICKED is sent from one or other of the controls (variable - depends where %WS_GROUP is placed???) by the system before any user action occurs

**Gösta H. Lovgren-2** · 22 Jul 2008, 10:15 PM

Fred, I note you commented out stuff in the CallBack. Your code runs as expected (displays). BUT if you unrem that section, it does NOT display. Weird?

This code does NOT display the dialog (have to close with Task Mgr)

Code:

#Compile Exe
#Include "win32api.inc"
 
Function PBMain()
Local hDlg, n As Long
Dialog New 0,"Print Reminders",,, 190, 100, %WS_SYSMENU To hDlg
'Control Add Button, hDlg, 101, "Print number 1", 20, 10, 100, 25
'Control Add Button, hDlg, 102, "Print number 2", 20, 50, 100, 25
Control Add Option, hDlg, 101, "Print number 1", 20, 10, 100, 25, %WS_GROUP
Control Add Option, hDlg, 102, "Print number 2", 20, 50, 100, 25
Dialog Show Modal hDlg, Call dialogProc To n
MsgBox Str$(n)
End Function
 
CallBack Function dialogProc()
Select Case CbMsg
Case %WM_COMMAND
If CbCtlMsg = %BN_CLICKED Then
If CbCtl = 101 Then 
Dialog End CbHndl, 1
ElseIf CbCtl = 102 Then 
Dialog End CbHndl, 2
End If 
End If
End Select 
End Function

but this code DOES display (as expected)

Code:

#Compile Exe
#Include "win32api.inc"
 
Function PBMain()
   Local hDlg, n As Long
   Dialog New 0,"Print Reminders",,, 190, 100, %WS_SYSMENU To hDlg
   'Control Add Button, hDlg, 101, "Print number 1", 20, 10, 100, 25
   'Control Add Button, hDlg, 102, "Print number 2", 20, 50, 100, 25
   Control Add Option, hDlg, 101, "Print number 1", 20, 10, 100, 25, %WS_GROUP
   Control Add Option, hDlg, 99, "Print number 2", 20, 50, 100, 25
   Dialog Show Modal hDlg, Call dialogProc To n
   MsgBox Str$(n)
End Function
 
CallBack Function dialogProc()
   Select Case CbMsg
   Case %WM_COMMAND
      If CbCtlMsg = %BN_CLICKED Then
         If CbCtl = 101 Then 
            Dialog End CbHndl, 1
         ElseIf CbCtl = 102 Then 
            Dialog End CbHndl, 2
         End If  
      End If
   End Select   
End Function

Note the ONLY difference between the two examples is the id of Option 2.

**Dave Biggs** · 22 Jul 2008, 10:43 PM

Gösta,

The system is generating a %BN_CLICKED msg from the second option button when the dialog is created (see my post just above).

In your second code you don't have a case statement for the ID of that control...

**Gösta H. Lovgren-2** · 22 Jul 2008, 11:36 PM

Originally posted by Dave Biggs View Post

Gösta,

The system is generating a %BN_CLICKED msg from the second option button when the dialog is created (see my post just above).

In your second code you don't have a case statement for the ID of that control...

Dave, we are not on the same page here. Or you are saying something I'm not understanding. Between the last 2 code examples I posted, the ONLY ONLY ONLY difference is the id number for option 2. When the id is 102, the dialog runs but does not display and has to be shut down externally (Task Mgr). When the id is any number other than 102, the dialog behaves properly (displays).

Try each code I posted to see for yourself. Or unrem the code in the callback in Fred's example and you'll see the same behavior.

Weird......
===========================================================
"The mistakes are all waiting to be made."
chessmaster Savielly Grigorievitch Tartakower (1887-1956)
on the game's opening position
===========================================================

**Charles Dietz** · 22 Jul 2008, 11:43 PM

I want to thank all you guys for your help. The code I have decided to go with is the following:

Code:

#COMPILE EXE
#INCLUDE "win32api.inc"

FUNCTION PBMAIN()
   LOCAL hDlg, n AS LONG
   DIALOG NEW 0,"Print Reminders",,, 190, 100, %WS_SYSMENU TO hDlg
   'CONTROL ADD BUTTON, hDlg, 101, "Print number 1", 20, 10, 100, 25
   'CONTROL ADD BUTTON, hDlg, 102, "Print number 2", 20, 50, 100, 25
   CONTROL ADD OPTION, hDlg, 101, "Print number 1", 20, 10, 100, 25, %WS_GROUP
   CONTROL ADD OPTION, hDlg, 102, "Print number 2", 20, 50, 100, 25
   DIALOG SHOW MODAL hDlg, CALL dialogProc TO n
   MSGBOX STR$(n)
END FUNCTION

CALLBACK FUNCTION dialogProc()
   LOCAL lStatus&
   SELECT CASE CBMSG
   CASE %WM_COMMAND
      IF SendMessage(GetDlgItem(CBHNDL, 101), %BM_GETCHECK, 0, 0) THEN DIALOG END CBHNDL, 1 
      IF SendMessage(GetDlgItem(CBHNDL, 102), %BM_GETCHECK, 0, 0) THEN DIALOG END CBHNDL, 2
   END SELECT   
END FUNCTION

**Dave Biggs** · 23 Jul 2008, 12:21 AM

Charles,
Glad you have a solution

Gösta,
It seems that what is happening is that the system generates a %BN_CLICKED message for the second of the two Option controls as the Dialog is being created.

If you have a case statement that responds to that eventuality - has the ID number of the control that is identified in the unexpected message - it will fire.

Code:

         ElseIf CbCtl = 102 Then  ' < - doesn't fire if control ID is 99
            Dialog End CbHndl, 2

So "Dialog End CbHndl, 2" is being acted upon at the same time as the dialog is being created - it doesn't show (and doesn't properly get destroyed either!).

If you add code to explicitly set one or other of the options that errant %BN-CLICKED message is NOT generated by the system (who knows why!) and so the dialog doesn't get the Dialog End command prematurely.

In my code I commented out the Dialog End stuff and added Dialog Set Text messages instead so you can see what's happening.

**Dave Biggs** · 23 Jul 2008, 12:35 AM

Originally posted by Dave Biggs View Post

Charles,
Glad you have a solution

But on second thought. If this is for working code you might want to consider the following snips from PB Help on the Control Add Option statement..

..
When a group of option buttons are created, you should explicitly set the "selected" and "unselected" state of all option buttons, using the CONTROL SET OPTION statement to set the Check State of all the buttons in the group.
..
The following notifications are sent to the Callback Function:
%BN_CLICKED
Sent when the user clicks a mouse button, or activates the button with the hot-key (unless the button has been disabled).
..
When a Callback Function receives a %WM_COMMAND message, it should explicitly test the value of CBCTL and CBCTLMSG to guarantee it is responding appropriately to the notification message.
..

**Rodney Hicks** · 23 Jul 2008, 01:53 AM

Dave, thanks for the overdue lesson. Don't know why I never paid attention to this aspect of the OPTION BUTTON, always checking to see if it was set instead.

Rod

**Gösta H. Lovgren-2** · 23 Jul 2008, 07:44 AM

Originally posted by Dave Biggs View Post

Gösta,
It seems that what is happening is that the system generates a %BN_CLICKED message for the second of the two Option controls as the Dialog is being created.

If you have a case statement that responds to that eventuality - has the ID number of the control that is identified in the unexpected message - it will fire.
.

Fair enough Dave. It just was an anamoly I stumbled across and it puzzled me. Thanks the explanation.

=======================================================
Circumstances rule men and not men rule circumstances.
Euripides
=======================================================

**Michael Mattias** · 23 Jul 2008, 08:14 AM

With options buttons, wouldn't you normally want to have a third button, the "do it" button, so the user can change his mind before "doing it?"
e.g

Code:

     (_)  Option A 
     (o)  Option B 

    < DO IT button>

Code as written gives you one chance, and an inadvertent click will 'do it' immediately.

Also, if you do it this way you never need to process click notifications at all... you just query which one is checked when you process WM_COMMAND from the <DO IT> button. (Default processing will handle the setting of the checks as the user clicks or uses the arrow keys on the options).

MCM

**Charles Dietz** · 23 Jul 2008, 09:24 AM

Michael, thanks for your thoughts.

I have gone back and forth on whether to include a 'do it' button, but have settled on this way when the dialog consists only of selecting an option and not processing other information. My rationale is that options are a form of buttons, and like my first post in this thread, using options like I would buttons makes sense. Also, using a 'do it' button requires one more mouse click unless the option selected is the default.

**Michael Mattias** · 23 Jul 2008, 09:43 AM

Then why not just use push Buttons...

Code:

   < OPTION A> 
    <OPTION B>

Still one click, and since dialog ends when click is processed, same result.

Uusing radio buttons which do anything other than highlight the currently-selected option IS going to confuse users. (This is a WHEN, not an IF).

Maybe you can use some fancy buttons or something if you don't like the 'pushing' action.

Besides, you have no keyboard interface this way and therefore lose six points.

MCM

**Charles Dietz** · 23 Jul 2008, 04:18 PM

Michael, you make some very good points... in fact because of the keyboard interface issue you raise, I'm persuaded to use something other than option buttons. Perhaps some code similar to this might be a good compromise:

Code:

#COMPILE EXE
#INCLUDE "win32api.inc"

FUNCTION PBMAIN()
   LOCAL hDlg, n AS LONG
   DIALOG NEW 0,"Print Reminders",,, 190, 100, %WS_SYSMENU TO hDlg
   CONTROL ADD BUTTON, hDlg, 101, "", 25, 20, 10, 10
   CONTROL ADD LABEL, hDlg, 101, "Print number 1", 40, 20, 100, 12, %SS_NOTIFY
   CONTROL ADD BUTTON, hDlg, 102, "", 25, 40, 10, 10
   CONTROL ADD LABEL, hDlg, 102, "Print number 2", 40, 40, 100, 12, %SS_NOTIFY
   DIALOG SHOW MODAL hDlg, CALL dialogProc TO n
   MSGBOX STR$(n)
END FUNCTION

CALLBACK FUNCTION dialogProc()
   SELECT CASE CBMSG
   CASE %WM_COMMAND
      IF CBCTLMSG = %BN_CLICKED THEN
         IF CBCTL = 101 THEN 
            DIALOG END CBHNDL, 1
         ELSEIF CBCTL = 102 THEN 
            DIALOG END CBHNDL, 2
         END IF  
      END IF
   END SELECT   
END FUNCTION

Announcement

Problem with Option buttons

Problem with Option buttons

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment