home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / tcl / 1340 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  1.9 KB
  1. Path: sparky!uunet!wupost!sdd.hp.com!hplabs!ucbvax!ansa.co.uk!eo
  2. From: eo@ansa.co.uk (Ed Oskiewicz)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Re: Bug in menus of radio buttons
  5. Message-ID: <9209111653.AA24476@caligula.ansa.co.uk>
  6. Date: 11 Sep 92 16:53:26 GMT
  7. References: <18lan7INNs76@agate.berkeley.edu>
  8. Sender: daemon@ucbvax.BERKELEY.EDU
  9. Lines: 33
  10.  
  11.  
  12. John,
  13.  
  14. Thanks for responding, a couple of people pointed out the -variable switch to
  15. me. However I think the situation is still a bit confusing to the unwary and
  16. maybe could be clarified in the documentation. I can (now) appreciate the
  17. value of grouping radio buttons logically independantly of their placement in
  18. a menu or packing order in a frame. But this notion of radio button group
  19. seems quite crucial and is not really brought out in the documentation.
  20.  
  21. However the existing behaviour seems to me to be idiosyncratic, my suggestion
  22. for 'less surprising' behaviour is as follows. First change -variable to
  23. -buttongroup (or something more reminiscent of what is going on), second by
  24. default (i.e. when -buttongroup is not specified) arrange that radio buttons
  25. are grouped according to where the user places them, if in a menu all those in
  26. the menu form a group, if in a frame all those in the frame form a group and
  27. so on. It should be easy to fabricate a unique buttongroup name
  28.  
  29. Also, if you remember my original confusion was compounded by the discovery
  30. that adding a space to the labels caused the two menus to act independantly.
  31. Thus it seems that within a radio button group that adding a button with the
  32. same label as an existing label causes it to be regarded as though it were
  33. 'the same' as the first instance, wouldn't an error be more appropriate as the
  34. resulting behaviour is not what the programmer thought was going to happen?
  35.  
  36. Cheers,
  37.  
  38. Ed Oskiewicz
  39.  
  40. email:    eo@ansa.co.uk (mcsun!uknet!ansa!eo)    ANSA,
  41. tel:    +44 223 323 010                Poseidon House,
  42. fax:    +44 223 359 779                Castle Park,
  43.                         Cambridge CB3 0RD, UK
  44.