I’ve followed this thread and I’m amazed how it went from nonconstructive to this.
My 5 cents are can’t we have 2 documentations:
Given the limited resources at Xojo inc this could help. On quarterly basis or whatever frequency is feasible the review takes place and the official docs are updated.
(bold is mine)
Just so that wording does not cause any confusion for anyone…
While it is obvious, I would like to point out that while the events are shared between all the members of the set, the property values are not. If they were shared for example all labels in the set would have to have the same caption and checkboxes the same state, etc.
-Karen
For Mac apps that is a a very good top… For Windows it can be problematic.
On Windows Xojo supports the the use of accelerator keys (Using & in the caption). A user typing the accelerator key combination triggers the accelerator key event on the label which typically used to set focus to control it is a label for.
If that event is shared (As all the others are, I assume it is, but never tried using labels as control set) then one would potentially need to have a long select case statement in the event to set the focus to the right control!
I have been trying to remember to support accelerator keys as my employer is moving from Macs to all Windows boxes .
-Karen
It is actually way easier to create and mantain One single big SelectCase than 20, 40 or more individual events.
IMO not really for that use, particularly when doing layout and tweaking the design and deciding which controls to use for what.
-Karen
Correct. That was my mistake and it’s not on the Control Sets page. But thank you for pointing it out because I too do not want anyone to be confused by that.
We don’t want to modify it too much (if at all). However, there’s plenty we can do to the content to move deprecated items further down the list.
We talked about that and given the better alternative, we really don’t want to advertise that. Obviously we aren’t going to go out of our way to make it not work, but we also don’t want to confuse people either.
Please don’t hide deprecated things any more than you already do, you’ve been saying for a while now that we don’t have to stop using them. Some of us have hundreds of thousands of lines of code that contain deprecated items, without time to fix them all.
And how are you going to find the deprecated item’s page if you don’t see it somewhere in the search results?
What is the better alternative for the type of menu use Ian mentioned. I have used menu item sets in a number like that in number of different of situations… It’s quicker than doing things like subclassing MenuItem and simpler (and less configuration work) than using add handler on each of the items.
Whoever added the concept to the product way back when, really hit on something easy and RADish…
I really don’t understand the lack of love for that mechanism at Xojo inc. these days.
-Karen
I wanted to add RadioButton in one of my program and I saw that it doesn’t exist anymore, now it is DesktopRadioGroup. In the past we were oblige to create a control set with 2 or ore RadioButton.
Why RadioButton are not indicated as deprecated when I verify my code?
I would like to say that if now we are less free (we can’t put radiobuttons everywhere, there are vertical or horizontal and all the same width), it is more logic now.
@Thomas_ROBISSON - They are not deprecated. The are just not part of the library. Add e.g. a DesktopButton to your Window and set change his Superclass to DesktopRadioButton.
It does exist and is not deprecated.
Its like Martin says. Xojo decided this is good idea. And as result I have had several users using my plugin radio button thing control from the custom button which is not meant for this and I have asked them why their using it for this situation and was shocked to find out it was because of this silly thing that Xojo hides the button. Where they either a) Did not know it was still there or b) Do not trust that Xojo wont just remove it one day.
So the idea they had to make it “easier” by hiding the main radio button to push people to the useless RadioButtonGroup is confusing the hell out of users and making things harder on them, for literally no good reason.,
that is not true.
You never needed to create a control set to use radiobuttons. You could do it that way, but that was not the intended use.
You put them on a containing control such as a window, group box, container control or when you don’t want the container visible, a canvas and then they act in concert as group.
-Karen
Sort of like hiding control set documentation…
Seems like Xojo Inc in recent years has gotten some strange ideas about what is best for customers in a number of areas.
-Karen
The questions are what is the reason for that, and why does Xojo Inc think that is a good thing?
-Karen