I’m trying to port my logic code from a desktop app to an iOS app.
Why on Earth are there two mutually exclusive but seemingly identical events for the Timer class?
It appears that Timer.Action() and Timer.Run() are identical except Timer.Action() is for desktop/console only and Timer.Run() is for mobile only!
What is this madness??
Thanks to this I can’t port my timer subclass easily between the two projects. Is this a bug? Surely this can’t be by design?
Run was supposed to be API 2.0, but then renaming all the events broke people’s stuff so Xojo rolled back new event names. That’s the history.
I despise the desktop-prefixed-crap, but I suppose if they were to add a DesktopTimer class, the event should be Run.
It’s little paper cuts like this that make it so hard to abstract out logic between project types.
There should be an engineering requirement that requires putting any changes on those two meme buttons, then judging the facial expression below BEFORE implementation.
I’d meme them as “Safety - API-1” and “Sure Death - API-2”
I keep running into this issue with my cross-platform macOS and iOS app. It’s extremely frustrating that I can’t share a simple timer class between the two projects. Feedback:
Just gave a thumbs up to that case.
it is called API 2
And clearly someone once just decided to have it just to be as-is … probably because “it may break code”… I’d rather have 1 version break some event name than keeping my mind pointing the wrong way because someone ever deciced to have 2 different events on differen platforms for the same class !!
I just hope Xojo for once decides to be consistent like in ALL ways.
As noted on the ticket, Mobile is the odd one out.
I agree and it’s annoying to have to cater for two commands in my code to perform the same thing, but remember that this thinking is what gave us API 2 (< prepare for arrows>which I love 
</prepare for arrows >).
You should be able to use #target statements to share a single project file:
#if TargetMobile then
AddHandler MyTimer.Run,AddressOf MyMethod
#else
AddHandler MyTimer.Action,AddressOf MyMethod
#endif
Correct, but the main issue for my projects is sharing the logic of the timer subclass without duplicating code.
You don’t need to duplicate code with Arnaud’s suggestion. Since the sender reference in both cases is Timer, MyMethod can be one method.
The timer issue is an example where I subclass the Xojo timer class and create my own methods/functions with appropriate names consistent for all platforms. I’ve done this for most of the UI classes now because with a large app over 10 years old it was a quicker fix than attempting to search/replace every instance in the source code with a new syntax every time Xojo decides to have a brain fart.
Problem fixed.
Agreed I don’t really understand why the need for all the desktop framework prefixes when this could (should) have been fixed by the IDE picking the appropriate code merely by defining the target platform.
As for the “new features”… made my own set classes ages ago, and ZIP functionality was written way back in the REALBasic days - from memory thanks to either either Thomas Templeman or Kem Tekinay
The whim of renaming the events with many many many downsides and no real beneffit 
Thank you; I wasn’t aware AddHandler was added during the period I stopped using XOJO; this is a great solution.