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?
@Enric H has already implemented the event.
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 it’s also possible to get this error when the parent doesn’t 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.
@Enric H 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.
@Alberto D Now that the changes are settled,
I wouldn't consider that to be a true statement
@Enric H : 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.
@Greg OLone Right. Because the event name changes were reverted in 2.1. You have to go back to the old names.
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.
@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....
Yes. Yes. A flaw more and more common among API’s. Too sure of themselves they are. Even the older, more experienced ones - XODA
@Enric If we adapted to 2.1 what will happen in 2.2?
Difficult to see. Always in motion the future is. - XODA
@Enric 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.
I find your lack of faith disturbing…
@Enric Good job.
Don’t be too proud of this technological error we’ve 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
@Alberto Now that the changes are settled, you can change your code to 2.1 and that will work with 3.0 and later.
Or, in other words, forget the “R2 detour”, “see 3.0”
@Greg Unfortunately it’s also possible to get this error when the parent doesn’t expose the event at all.
Look, I have exposed that I am your father! Is that not “apparent”.
@Louis @Enric ; : The evolutionary process is not a straight line, either in biology or in development. Some branches die quickly... There are going to be more changes in the future. And some failed ones in the lot...
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