Radio Buttons - Perennial Rant

[JTaylor]

Would you PLEASE!!! PLEASE!!! PLEASE!!! PLEASE!!! PLEASE!!! PLEASE!!! PLEASE!!! fix the RadioButtons?

Every time I have a use for them I normally end up using checkboxes instead and clear the others when one is checked because it is easier.  I know it isn't just me because I have had other people tell me the same thing.  All I want is the way it used to work in 5.x dialogs in that it would return the "value" and be able to set the value to alphanumeric instead of just numbers.  You force the setting of a value but provide no way to retrieve it.   I have to do all of the following, and often more, when only the first row should be needed.  May not seem like much but it drives me bonkers.  I would love to be able to use RadioButtons again instead of manipulating checkboxes.

col_module = DialogControlGet(dCO_Handle,"rb_dCO_col_module_all",dc_radiocontrol)
    If col_module == "rb_dCO_col_module_all"       Then col_module = 1
    If col_module == "rb_dCO_col_module_bin"      Then col_module = 2
    If col_module == "rb_dCO_col_module_ie"        Then col_module = 3
    If col_module == "rb_dCO_col_module_report" Then col_module = 4
    If col_module == "rb_dCO_col_module_marc"   Then col_module = 5

Jim

[Deana]

You should not even need to call DialogControlGet. You can use the _name parameter of the callback procedure, just like you can for other controls.

Code (winbatch) Select Expand

#DefineFunction ExampleCallbackProc(Example_Handle,Example_Message,Example_Name,Example_EventInfo,Example_ChangeInfo)
    InitDialogConstants()                                   ; Initialize Dialog Constants
   ON_EQUAL = @TRUE                                         ; Initialize variable ON_EQUAL
   switch Example_Message                                   ; Switch based on Dialog Message type
      case MSG_INIT                                         ; Standard Initialization message
         DialogProcOptions(Example_Handle,MSG_BUTTONPUSHED,@TRUE)
         DialogProcOptions(Example_Handle,MSG_RADIOPUSHED,@TRUE)
         return(RET_DO_DEFAULT)

     case MSG_BUTTONPUSHED
        if Example_Name == "PushButton_OK"                 ; OK
              return(RET_DO_DEFAULT)

        elseif Example_Name == "PushButton_Cancel"         ; Cancel
              return(RET_DO_CANCEL)

        endif                                              ; Example_Name
        return(RET_DO_DEFAULT)

     case MSG_RADIOPUSHED  ;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
        if Example_Name == "RadioButton_Blues"             ; music Blues
              return(RET_DO_DEFAULT)

        elseif Example_Name == "RadioButton_Jazz"          ; music Jazz
              return(RET_DO_DEFAULT)

        elseif Example_Name == "RadioButton_Rock"          ; music Rock
              return(RET_DO_DEFAULT)

        endif                                              ; Example_Name
        return(RET_DO_DEFAULT)


   endswitch                                                ; Example_Message
   return(RET_DO_DEFAULT)
#EndFunction                                                ; End of Dialog Callback ExampleCallbackProc




tunes = "My Shirona":@TAB:"In the Mood":@TAB:"Staying Alive":@TAB:"Rock Lobster":@TAB:"Tequila"
song="Yellow Submarine"
music=2 ;sets this radiobutton as default
volume=1 ;pre-selects checkbox.
ExampleFormat=`WWWDLGED,6.2`
ExampleCaption=`Music Selection`
ExampleX=120
ExampleY=050
ExampleWidth=128
ExampleHeight=137
ExampleNumControls=013
ExampleProcedure=`ExampleCallbackProc`
ExampleFont=`DEFAULT`
ExampleTextColor=`DEFAULT`
ExampleBackground=`DEFAULT,DEFAULT`
ExampleConfig=0

Example001=`009,117,050,014,PUSHBUTTON,"PushButton_OK",DEFAULT,"OK",1,1,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example002=`069,117,050,014,PUSHBUTTON,"PushButton_Cancel",DEFAULT,"Cancel",0,2,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example003=`085,075,036,016,RADIOBUTTON,"RadioButton_Blues",music,"Blues",1,3,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example004=`085,059,036,016,RADIOBUTTON,"RadioButton_Jazz",music,"Jazz",2,4,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example005=`085,041,036,016,RADIOBUTTON,"RadioButton_Rock",music,"Rock",3,5,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example006=`047,095,036,014,CHECKBOX,"CheckBox_LOUD!",volume,"LOUD!",1,6,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example007=`085,095,036,014,CHECKBOX,"CheckBox_Quiet",volume2,"Quiet",2,7,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example008=`009,095,036,014,STATICTEXT,"StaticText_VOLUME",DEFAULT,"VOLUME",DEFAULT,8,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example009=`007,005,110,014,STATICTEXT,"StaticText_2",DEFAULT,"What is your listening pleasure?",DEFAULT,9,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example010=`007,051,064,040,ITEMBOX,"ItemBox_1",tunes,DEFAULT,DEFAULT,10,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example011=`067,025,056,014,STATICTEXT,"StaticText_3",DEFAULT,"Type Preferred?",DEFAULT,11,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example012=`007,021,058,014,VARYTEXT,"VaryText_1",song,"Choose a title",DEFAULT,12,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example013=`007,037,062,014,EDITBOX,"EditBox_1",song,DEFAULT,DEFAULT,13,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
ButtonPushed=Dialog("Example")



If you really need the control Value rather than Name...Have you considered creating a global list or array that stores the name value pairs?

[JTaylor]

I guess I just don't understand.  Why is this even a question?  Isn't the "Value" of a control the important thing?  Why do you return the value for other controls and not the RadioButtons?  You are going to have trouble convincing me that the purpose of the "Name" field is a surrogate for a "Value" or to somehow use it to contrive a system for figuring out what the "Value" is for a control.   Name/Value pairs?  Seriously?   Yes, one could make it work that way but why should one have to do such silly things?   Why do you make RadioButtons work COMPLETELY different from every other control?    Why do you act like I'm being unreasonable in expecting consistency in the implementation of the controls?  While they appear as separate controls on the screen, to me they simply appear to be a variation on itemlists?   Aren't any with the same variable name, properly, treated as a single control?  I realize your approach is the easy way to do it but not sure how you can defend such an approach as it makes no sense.  While I have to know what control was affected, for obvious reasons, that is irrelevant if I can't return the value of a control.   Telling me that I typed something in editbox 3 is nice but useless if I don't know what was typed in editbox 3.

Oh well, I know this discussion is pointless.  Just keep hoping that one day someone will straighten this mess out.   I just have places where RadioButtons would be nice to use but with the extra work involved coupled with the annoyance at the illogical implementation I normally give up and use checkboxes.  Can't believe anyone there uses them either or surely they would get fixed and I know I'm not the only WinBatch user to think this way about this issue.  I think part of the annoyance is that you all implement practically everything you do so well it just throws me off when you do something like this and then staunchly defend the need for us to jump through hoops to use it as being reasonable.  In any event, sorry to bother you with a pointless rant once again.   I'll shut up now.

Jim

[Deana]

Lets be clear.. the Radiobutton variable does contain the VALUE of the radio button upon return from the dialog. However when handling events inside the Dialog callback procedure you are dealing with control names, just like you do with ALL of the other controls. I consider this a consistent implementation.

Maybe what you are truly wanting is for a new DialogControlGet request to return the Radiobutton that was clicked Value. I will be happy to pass on such a request to the developers. 

Did I somehow imply that you were being unreasonable in my response? I do not feel like I did. But If so I apologize.

[Deana]

I would also like to offer another suggestion for a workaround ( but please don't see this as dismissive to your request ). We work very hard here at Wilson WindowWare to listen to our user and resolve their issues quickly.

The workaround I would like to suggest is that you simply name your Radio button controls with the Value of the button.

Code (winbatch) Select Expand

#DefineFunction ExampleCallbackProc(Example_Handle,Example_Message,Example_Name,Example_EventInfo,Example_ChangeInfo)
    InitDialogConstants()                                   ; Initialize Dialog Constants
   ON_EQUAL = @TRUE                                         ; Initialize variable ON_EQUAL
   switch Example_Message                                   ; Switch based on Dialog Message type
      case MSG_INIT                                         ; Standard Initialization message
         DialogProcOptions(Example_Handle,MSG_BUTTONPUSHED,@TRUE)
         DialogProcOptions(Example_Handle,MSG_RADIOPUSHED,@TRUE)
         return(RET_DO_DEFAULT)

     case MSG_BUTTONPUSHED
        if Example_Name == "PushButton_OK"                 ; OK
              return(RET_DO_DEFAULT)

        elseif Example_Name == "PushButton_Cancel"         ; Cancel
              return(RET_DO_CANCEL)

        endif                                              ; Example_Name
        return(RET_DO_DEFAULT)

     case MSG_RADIOPUSHED  ;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
        radiovalue = Int(Example_Name)
        Pause('radiovalue',radiovalue)
        return(RET_DO_DEFAULT)


   endswitch                                                ; Example_Message
   return(RET_DO_DEFAULT)
#EndFunction                                                ; End of Dialog Callback ExampleCallbackProc



tunes = "My Shirona":@TAB:"In the Mood":@TAB:"Staying Alive":@TAB:"Rock Lobster":@TAB:"Tequila"
song="Yellow Submarine"
music=2 ;sets this radiobutton as default
volume=1 ;pre-selects checkbox.
ExampleFormat=`WWWDLGED,6.2`
ExampleCaption=`Music Selection`
ExampleX=120
ExampleY=050
ExampleWidth=128
ExampleHeight=137
ExampleNumControls=013
ExampleProcedure=`ExampleCallbackProc`
ExampleFont=`DEFAULT`
ExampleTextColor=`DEFAULT`
ExampleBackground=`DEFAULT,DEFAULT`
ExampleConfig=0

Example001=`009,117,050,014,PUSHBUTTON,"PushButton_OK",DEFAULT,"OK",1,1,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example002=`069,117,050,014,PUSHBUTTON,"PushButton_Cancel",DEFAULT,"Cancel",0,2,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example003=`085,075,036,016,RADIOBUTTON,"1",music,"Blues",1,3,DEFAULT,DEFAULT,DEFAULT,DEFAULT` ;!!!!!!!!!!!!!!!!!!!!!!!!
Example004=`085,059,036,016,RADIOBUTTON,"2",music,"Jazz",2,4,DEFAULT,DEFAULT,DEFAULT,DEFAULT`   ;!!!!!!!!!!!!!!!!!!!!!!!!
Example005=`085,041,036,016,RADIOBUTTON,"3",music,"Rock",3,5,DEFAULT,DEFAULT,DEFAULT,DEFAULT`  ;!!!!!!!!!!!!!!!!!!!!!!!!
Example006=`047,095,036,014,CHECKBOX,"CheckBox_LOUD!",volume,"LOUD!",1,6,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example007=`085,095,036,014,CHECKBOX,"CheckBox_Quiet",volume2,"Quiet",2,7,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example008=`009,095,036,014,STATICTEXT,"StaticText_VOLUME",DEFAULT,"VOLUME",DEFAULT,8,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example009=`007,005,110,014,STATICTEXT,"StaticText_2",DEFAULT,"What is your listening pleasure?",DEFAULT,9,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example010=`007,051,064,040,ITEMBOX,"ItemBox_1",tunes,DEFAULT,DEFAULT,10,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example011=`067,025,056,014,STATICTEXT,"StaticText_3",DEFAULT,"Type Preferred?",DEFAULT,11,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example012=`007,021,058,014,VARYTEXT,"VaryText_1",song,"Choose a title",DEFAULT,12,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
Example013=`007,037,062,014,EDITBOX,"EditBox_1",song,DEFAULT,DEFAULT,13,DEFAULT,DEFAULT,DEFAULT,DEFAULT`
ButtonPushed=Dialog("Example")

Pause(0,music)

[JTaylor]

This has been an ongoing issue for many years that I have repeatedly raised (actually first raised it when dynamic dialogs were first released) but apparently we haven't been communicating.   The "Value" is, of course, what one would want.  That is what has puzzled me in all the discussions over the years.  Why would one NOT want the Value?  The big question for me is why would one implement a Control and provide no way to retrieve the Value in the first place.  In my opinion, the fact that you have to suggest work-arounds to get the Value of a control makes my point for me.  That is what is inconsistent...not that fact that one uses "Names" to address controls.   This is the only control that I am aware of that provides/returns a "Value" but then provides no way to retrieve it.

In any event, thank you for finally hearing me after all these years of asking.   Just to repeat so it isn't lost.   If action is taken on this request, please allow alphanumeric values as used to be possible and not just numbers.

My comments weren't all related to just this discussion but to all the past discussions and, No, you didn't make any comments related to me being unreasonable in this present discussion.

Jim

Lets be clear.. the Radiobutton variable does contain the VALUE of the radio button upon return from the dialog. However when handling events inside the Dialog callback procedure you are dealing with control names, just like you do with ALL of the other controls. I consider this a consistent implementation.

Maybe what you are truly wanting is for a new DialogControlGet request to return the Radiobutton that was clicked Value. I will be happy to pass on such a request to the developers. 

Did I somehow imply that you were being unreasonable in my response? I do not feel like I did. But If so I apologize.

[stanl]

Jim;

Having never had any problems with Radio controls whether a static or dynamic dialog (and Deana's last suggestion is quite useful), it appears you have a need to treat radios like "pseudo-events" inside a dynamic dialog rather than as a selected value, i.e. when a button is pushed the selected radio value is used to get some result.

By a pseudo-event I mean something like the value of the radio clicked influences another control in the dialog, like a drop-down which changes it's values based on the radio selected. Am I way off base here?

[JTaylor]

Correct.  Actually I would think that would be the most common use but maybe I'm wrong.   Even if that isn't the use case it still doesn't make sense that one has to maintain a separate value-to-control table of some sort just to match up a selection with the real value or hijack the "Name" parameter for that purpose.  There are obviously work-arounds but that has been my point since their implementation.  A work-around, by definition denotes a deficiency of some sort, especially in this context and I can see no reason why a work-around should have ever been required in this situation.   Initially one had to check the value of every radio button to find out which one had been selected.  I hollered loud enough to get that changed but could never get anyone to listen to me about the failure to return the "Value".

So you have never found it odd that you can't retrieve the value of the selected RadioButton and that you have to match up the selection with some value?

Jim

Jim;

Having never had any problems with Radio controls whether a static or dynamic dialog (and Deana's last suggestion is quite useful), it appears you have a need to treat radios like "pseudo-events" inside a dynamic dialog rather than as a selected value, i.e. when a button is pushed the selected radio value is used to get some result.

By a pseudo-event I mean something like the value of the radio clicked influences another control in the dialog, like a drop-down which changes it's values based on the radio selected. Am I way off base here?

[stanl]

So you have never found it odd that you can't retrieve the value of the selected RadioButton and that you have to match up the selection with some value?

I have never found it odd, probably because I traditionally see radios as discrete selections, mainly to assist as a SQL query - so the 'value' is only important after a button is clicked. Also, I have never taken WB dialogs to a level beyond a 'what you see is what you get'.

[stevengraff]

Just chiming in... I think you all know my level of programming skill, for one thing, and I think I am probably the protypical WinBatch programmer, if that's even relevant...

I had not used a 3rd-party extender in the past, but finding out what was included in "Dialog Controls Extender" I decided I need to take the leap. I think the straw was DropListBox, but ToolTips was close behind. Since then I have made use of the following functions:

ToolTips
ProgressBar
StatusBar
ListBoxes
DropListBox

My main, albeit humble, point is: these functions all seem natural to me. If you asked me whether they should be in WB as native functions I'd say yes. Only the developers, ultimately, can say what "belongs" and doesn't belong in the core product, but gee, these functions, at least, sure seem central. It is surprising to me that these are not "core" features.

I am really grateful for the opportunity to use these functions in my scripts.

Regards,
Steven

[kdmoyers]

If we're taking an informal poll, I'd have to say that despite doing some fairly hairy dynamic dialog work, I've never felt like radio buttons worked poorly.  Maybe its because of the way I code dialogs -- I always work from the control names and ignore the values.  Not saying that's better -- it's just the crazy way I do it.

That said, I really do know how it can feel super irritating to constantly deal with a perceived flaw in the language.  Boy do I!

BTW - I have used Deana's trick of encoding a bit of info in the control name -- it's works well!

Only my $0.02
Kirby

[....IFICantBYTE]

I agree,
I often make compiled exes, used by many people inside our company, and they almost always have fancy dialog interfaces to drive them.

I generally use a mixture of "tricks" (some would say hacks), to get the dialogs to look and feel the way I want, over and above the "official" implementation of Winbatch dialogs.

Most of it is done using the Win32 API and DllCalls, but sometimes even this is not good enough (can't do custom event processing/subclassing) and I wonder why the WinBatch folks don't implement some additional controls and functionality nativley.

Perhaps they don't see the need, they want backward compatibility, or are worried about the extra effort and support needed for things they see as rarely used?

Whatever the case may be, I wish they did give us some more in the GUI area.
I know they sometimes do, menus, reportview etc, and I'm grateful for that, but it is something I wish they concentrated on for a while and basically re-designed for the latest incarnations of Windows and added all the bells and whistles! (or at least gave us the functions and the ability for hacks like me to write our own winbatch code to really extend it - without using DLL extenders)

[JTaylor]

I've probably said enough but that never seems to stop me  ;)

I agree, having a hook into the dialog callback and a way to implement controls would be nice.  Probably easier though to just implement the controls themselves.  Adding additional functionality once the controls are there is much easier.

I probably said this before but it seems a HUGE problem to me when one has to use a "trick" on a standard control to obtain basic functionality.

Guess I should stop my whining now  :-X

Jim

[Deana]

Unfortunately the current Dialog implementation has been around for a very long time and has been supported on many Windows platforms. It is this fact that makes it difficult to include new controls without careful consideration. We are currently focusing on implementing dotNet in WinBatch which may someday completely replace the current Dialogs. So there just may be some light at the end of this tunnel.

Recently I have been posting some dotNet dialog examples; many of which can be found in the technical support database: http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/dotNet/System_Windows/System_Window_Forms