Declare to have PointerDown, PointerUp and PointerDrag with all controls

I see in XCode that all iOS controls can have the PointerDown, PointerUp and PointerDrag events, not just the poor little canvas in Xojo iOS.

Would it not be conceivable to have a delegate to iOSControl that would add these events to all controls ? That would be a wonderful addition to the currently indigent set of event. In CheckWriter Desktop, all elements of the check can be moved around by the user, and I would like to do the same in iOS, which is impossible in the current state of Xojo iOS.

Ulrich ? Jason ? What do you think ?

I already know how to move a canvas very smoothly, using a few declares. Unfortunately, I am not competent enough with delegates.

Given the fact that no feature request have been implemented by Xojo in close to two years, I am not even entering one to ask for these events which should have been there in the first place. At one point, one loses faith…

So it is not possible to hook the events ? It was just an idea. As I wrote, I no longer have any faith in Xojo taking into account any feature request for iOS, as minuscule as it be. I am convinced nobody cares for Xojo iOS anyway, and there is no engineer in charge of it. We are completely on our own.

For my program I already have a solution : create a setup page with the same Wysiwyg layout but where the controls are mocked up by canvases. Once they have been moved in place, the user validates the changes, they will be reflected in the standard functional page, and saved as permanent settings.

Please write a feature request so Xojo Inc. can add those events for you.

I don’t believe anymore Xojo is willing to listen to the smallest such request. They haven’t granted any FR for close to two years, and there is no indication that will change.

FR in Xojo acronyms stands for “Futile Request”.

At one point, filling FR after FR and seeing absolutely no response for several years is beyond rude.

Sorry, but I have reported bugs and feature wishes over the years and a lot have been implemented / fixed.
They can’t do all things.

We have 1117 cases in Feedback from me, let me get you some statistics.

you can read here:
http://mbs-plugins.de/archive/2016-10-03/Xojo_Feedback_Success_rate/monkeybreadsoftware_blog_xojo

This proves nothing… I don’t have the exact numbers, but saying that 117 things WERE done, doesn’t touch on how many hundreds have NOT been done. A Michel’s point is valid. Xojo attempt at iOS is a freaking joke (my opinion). 3/4 of the control properties are not accessible (I mean no BACKCOLOR? seriously?) , but the fact that most controls are missing simple EVENTS (uh… iOS is an event driven environment for goodness sakes)…
Especially since everyone one of these things can be attached to controls in ONE LINE OF CODE in any other iOS developement ennvironment.

So it is not a matter of [quote=289633:@Christian Schmitz]They can’t do all things.[/quote]
Its a matter of they haven’t done the “right” things

A bit too harsh. :slight_smile:
Don’t forget iOS has got some love with new controls and finally a TableView with custom cells in the latest Xojo releases.
Of course it is not complete and as far as I know, only one engineer is working on iOS and thing progress very slowly. But saying nothing has been done for iOS support is not fair.

[quote]Would it not be conceivable to have a delegate to iOSControl that would add these events to all controls ? That would be a wonderful addition to the currently indigent set of event. In CheckWriter Desktop, all elements of the check can be moved around by the user, and I would like to do the same in iOS, which is impossible in the current state of Xojo iOS.

Ulrich ? Jason ? What do you think ?[/quote]
Like Jason said it is not possible to attach them in the way the libraries are built, but you might want to look into Sam’s ProjectCyborg he describes in the latest XDev. I guess a similar structure could be adapted to iOS.
A delegate in this case doesn’t work because the touch “events” are triggered on the instance itself, there is no separate delegate for responder handling. This means you always have to build a subclass, at least in iOSLib and iOSKit which rebuild Apple’s classes.

In case you want a custom control solution: You might have seen I restarted iOSLib as part of AppleLib, which means currently a lot of features will have to be re-added step by step. But the iOSLibView (meant for pure layer-based graphics) and the iOSLibCanvas (a view + a paint event) contain all the touches, motion and presses events inherited from UIResponder. iOSLibCanvas forwards the CGContext in its Paint event, so you can use all the advanced drawing features without conversion. In fact, it would be great to have some feedback on what conversions, properties and methods should be added into the controls so they do necessary conversions between iOS and Xojo transparently, or what controls are missing responder features.

I may have a working “hack” put together but I need to finish event forwarding to super before I post it. Hopefully this weekend I can get something out.

In case you hit a problem using the super structure from the Objective C Runtime, I think I can help. Just let me know.

NONE of the FR I filed has been implemented since the beta period of iOS back in 2014. And most of them are not really complex, they usually suggest to expose events or properties.

As I said, I find this FR business utterly futile. It is absolutely no point whatsoever if NOTHING is ever implemented.

I will still report bugs, but frankly, this baby has taken away all my illusions.

Although I am in the process of developing another product with Xojo, I have to seriously question my choice. I will soon port the same app to Android with B4A, and as we all know, it is code compatible with their iOS product.

Back in 2002, I started with RB for Mac, but after verifying that code could compile for Windows, I ended up today with Xojo. A developer does not have the luxury to go for years with an half baked, unfinished tool, and seemingly no interest from its publisher…