RadioButtonset event handlers/ValueChanged now gives error:
OptionsWindow.ScenarioRadioButton.ValueChanged Declaration
ScenarioRadioButton on OptionsWindow implements the event “ValueChanged,” but its superclass RadioButton has already implemented the event.
Sub ValueChanged(index as Integer)
I understand that a new version could generate warnings/obsolete and suggest changes but, introducing errors on code that worked, and do not given a solution…
If we adapted to 2.1 what will happen in 2.2?
It was the case previous ly. Explanation:
Do a Listbox subclass,
Add in that SubClass the Open Event,
Set your Listbox super to that SubClass.
You cannot add the Open Event anymore in the Listbox.
This behavior exists since probably REALbasic (I think).
Sorry.
Emile, I do not understand you, I have a radio button set and a Event Handlers/ValueChanded that deals with the radio buttons index, it compiled and worked in 2.0 now, the 2.1 gives that error,
I did not create any subclass.
Create a GroupBox
Put inside a radio button, create a set, the nduplicate the radio button several times, add a even handler to deal with which radio button is selected. That works I do not know if in RealBasic but in 2.0, but do not on 2.1
A simple example:
https://www.dropbox.com/s/m0e8itjpch8l7w2/res.xojo_binary_project?dl=0
Unfortunately its also possible to get this error when the parent doesnt expose the event at all. Try adding the Change event to ScenarioRadioButton again.
The question is that with 2.0 you get a suggestion to "replace Event (action event) to ValueChanged if you did, now in 2.1 it gives an error.
Right. Because the event name changes were reverted in 2.1. You have to go back to the old names.
Oh yes, but I’m just complaining about it, a new version suggested to change the event names, then you do to be up to date even if it was a lot of work, later, a new version go back with names, and it is not a suggestion now, you must go and change everywhere or it will not compile. Good job.
Changes in 2.0 affected many users.
Changes from 2.0 to 2.1 are affecting other users.
I bet the decision to change back was hard for Xojo.
I’m sorry this is affecting you.
Now that the changes are settled, you can change your code to 2.1 and that will work with 3.0 and later.
I wouldn’t consider that to be a true statement
@Enric Herrera : The extent of the issues caused by the 2.0 changes and the resulting flow of complaints (, whining and other forms of protest) caused Xojo to reconsider the decision to standardize event naming etc. (you are free to disagree). Reverting changes introduced by 2.0 in 2.1 only affects those of us who made the adjustment already. I am one affected by the change. After painstakingly adapting every event, statement etc. to 2.0 in one of my applications, I now do the work the other way around where required. Somehow, I messed up my SMTPSecureSockets along the way. It is annoying, no doubt. But looking at it with a bit of perspective, I firmly believe that it is for the greater good.
The evolutionary process is not a straight line, either in biology or in development. Some branches die quickly, and 2.0 falls in this category. I am banking on the success of the main branch. There are going to be more changes in the future. And some failed ones in the lot. Xojo is not unique. Apple, Microsoft and others have had failed initiatives. What I appreciate here is that Xojo responded to the situation quickly. Perhaps it would have been better to listen to beta testers, but the reaction to the problem was nevertheless quick and generaly appropriate if this forum is any indication.
And this happens even automatically for the majority of cases. It does / can not for subclassed controls and for code that manually Raises / Handles events. And there seem to be a bug that the automatic renaming does not work for Control Sets. Telling from the screenshot that bug is what @Enric Herrera is affected by.
[quote=465175:@Enric ]I understand that a new version could generate warnings/obsolete and suggest changes but, introducing errors on code that worked, and do not given a solution…
[/quote]
Yes. Yes. A flaw more and more common among APIs. Too sure of themselves they are. Even the older, more experienced ones - XODA
Difficult to see. Always in motion the future is. - XODA
I find your lack of faith disturbing
Dont be too proud of this technological error weve constructed. The inability to compile an app is insignificant next to the power of this Farce I am altering the deal, pray I do not alter it any further. -XODA
Or, in other words, forget the R2 detour, see 3.0
Look, I have exposed that I am your father! Is that not apparent.
Already know you that which you need. Always two APIs there are, no more, no less. Do. Or do not. There is no why. Impossible to see the future is" -XODA