I need to understand why when I use this code in a radioGroup under selection changed:
Select case me.SelectedIndex
case 0
System.DebugLog “Selected Daily”
case 1
System.DebugLog “Selected Weekly”
case 2
System.DebugLog “Selected Monthly”
end Select
My code compiles, but if I use:
Select case RadioGroup1.SelectedIndex
case 0
System.DebugLog “Selected Daily”
case 1
System.DebugLog “Selected Weekly”
case 2
System.DebugLog “Selected Monthly”
end Select
it fails.
And as a secondary (minor) thing, is it possible to that NO radio button is selected at startup? By the nature of radiobuttons, I figure at least ONE must be active.
And yes, it is possible for none of the buttons of a RadioGroup to be selected. As explained in the documentation you can set SelectedIndex to -1 for no selection.
It should work if you are placing the code into a control that is on a window. On the other hand, if you are working on a subclass of RadioGroup, you need to use ‘me’ because you are referring to properties of an abstract class.
A good way to look for issues like this is to verify that the IDE is auto-completing and/or that it can identify elements of your code when you click on them. For example if you click on “SelectedIndex” and it doesn’t know what that is, you know you’ve got a syntax error of some kind.
Honestly, I’ve done that more often than I care to admit - forgotten to include the index when typing a property of a control that’s part of a Control Set - and I’m always like “Why isn’t the &^$*% auto-complete working??”
Here’s my personal rule on me vs self vs explicit naming:
Never explicitly call by name unless you have no other choice. For example, all of a window’s controls and properties should be private, allowing you only the constructor and other methods to pass data into and out of the window. The window should be responsible for what to do with that data. This way, Window1 can know of Window2, but Window1 cannot directly ever call controls on Window2. This way the controls on Window2 can be changed (such as swap a checkbox for a radio when you need to add a third option) without affecting the code in Window1. Window2 still needs to explicitly call its controls by name of course, but that’s what I mean by no other choice.
Me should only ever be used inside a control’s on-window event handler. I actually argued to remove its existence from every other bit of code, but it would break too much.
`Self’ is used everywhere else.
I always prefix with Self to avoid any ambiguity. This means calling Self.TextField1 instead of just TextField1. When I come back to the code later, it’s clear to me where that resides. While control names tend to be more obvious, this is especially handy with method names. Since I won’t use global methods or properties either, it becomes very clear where everything resides. I don’t have to go hunting for it.
And not a rule, but I wish we had This or Static or something like that so shared methods and module methods can reference their container. This is mostly for factory methods so I could use new this(param1, param2) instead of explicitly writing the class name.
Is there a reason you are using RadioButtonGroups and RadioButton Sets together? RadioButtonGroups already contain multiple RadioButtons, and you can add more at any time. Groups have benefits, with easy identification of which is selected, shared events etc.
Sets have different benefits and can be useful in other ways. Good old RadioButtons still exist and can be used by adding a group and changing the super to RadioButton (desktop or other).
To have both a group and a set seems overkill, so I’m just curious.
In OOP classes of objects may have defined properties and methods. At their design, people can define certain “behaviors” like “call this method when someone click on this visual instantiated object”, that’s called an “event handler”. As the handler can be called from any instance of any object of that class like obj1.onclick(…) or obj2.onclick(…), imagine that internally the class define the onclick(..) as myClass.onclick(me As myClass, …) and when firing onclick() on any of those myClass objects, let’s take obj1 for instance, it calls it as myClass.onclick(obj1, …)
This “sender” parameter is implicit, you can’t see it in a Xojo method signature onclick() but the “me” sender is there and you can use it, and you know what object is being handled by this class handler method.
I hope that what I said makes sense to you as it makes to me. Talking and drawing is better than writing because the understanding differs depending on the previous expertize of the learner.
