How significant are the “memory clobbering” issues you fixed? I’m curious if I should expect to see any improvements in normal use?
It will in generally give you random crashes when the parameters do not match the signature.
Its not for sure how many of those methods and properties your code was calling though, I do not know how common use of each of them is since I have not used this control.
Might also be more cases which I missed but I will fine comb it soon, and do more detailed review of the code.
Note its also not clear if the Xojo Github was actually up to date, so whichever build you had of the control might have had some of it fixed even if their github did not, I just dont know.
I regularly have to do really difficult and hacky things to properly display code in different languages. I have apps that use AppleScript and Xojo Script and more recently am doing a lot of python plugins that would like to be edited inline. Anything that lets me do that more easily would be very much greatly appreciated. I’ve never gotten reasonable auto correct to work without some lower level plugin.
To be clear, what is being proposed is NOT a text or code editor. TextInputCanvas is a canvas that has events for text input. You implement events to return characters in a given range, for example. It’s very raw. But you can use it to build a code editor, but it’s a ton of work.
That’s an understatement. I’ve been working on my code editor for about 6 months!
Yeah, I have delusions that I want to create one.
All the reason why, in my humble opinion, this control does not have its place in the Library. Xojo is a RAD, meant to be used right away even for beginners. TextInputCanvas definitely does not comply to this requirement.
I don’t disagree, but this is work that Xojo is already doing which the community could benefit from. It doesn’t need to be built-in, although I think it’d be better that way. I would definitely not show it in the library pane.
I really wish I had the skills necessary to take this plugin and run with it. I’d love to see it as a controller object (one that sits in the tray on a window) instead, so we benefit from the built-in canvas. Somebody could subclass canvas, add one as a property, and hook up some events with AddHandler. But I don’t know if that’s even possible. Maybe it needs to be a RectControl.
I’m just frustrated because this is a massive barrier to some really great functionality, that Xojo has shared with us, and then given up. They started to “dog food” this, and then became ambivalent about it. I think if Xojo hadn’t shared this originally, I’d have no desire to see Xojo maintain it.
I use Formatted Text Control which is based on TextIntputCanvas in my apps. The code is massive.
Is there are prospect for compiling this for iOS?
I may be mistaken, but TextInputCanvas is desktop only.
Rich text under iOS is possible, though. Back in 2015, Jean Paul Devulder created me a declare for iOS that did bold, italic, and different fonts.
Since then 64 bit rendered it obsolete, but I believe a good OC programmer should be able to come up with a styled mobile TextArea.
Personally, I use now an editor within an HTMLViewer for that purpose.
FTC does a lot of things including allowing 3 different types of display. And does a lot of conversions between text, RTF, and an internal XML format. But I will say that getting it to work with the Text Input Canvas was a big undertaking and took a lot of back and forth with Joe Ranieri to get it working properly. Honestly, since he’s no longer with Xojo there may not be enough experience at Xojo to do the control justice.
Is TExtInput Canvas Mac only or only needed on a Mac? How about the FTC?
No it’s for Desktop Cross-Platform.
Changing it would mean to duplicate the class as an iOS subclass and then look how things work on iOS to adapt all the calls. Or in other words: It is a rewrite.
FTC works on macOS and Windows.
Works also fine on Linux
In the entire history of Xojo, Inc., there has never been a time when we didn’t pursue the development of a particular feature or bug fix due to a lack of expertise. For some recent examples, we added incremental compilation for 64 bit and Apple Silicon support after Joe left. We have in-house knowledge and experience with the TextInputCanvas. What we are lacking at the moment is enough interest to give us a reason to stop working on something else to instead work on the TextInputCanvas.
For anyone using it, if you are using it because it has a feature that some existing control is lacking, I highly recommend making a feature request for us to add that capability to an existing control as that’s far more likely to happen than there being enough interest in the TextInputCanvas for us to pour resources into it. Having said that, if the interest was sufficiently high, we would at least consider it but first and foremost we would be looking at improving existing controls as replacements.
Please read the thread from the start. I’ve linked two Feedback cases, @Thom_McGrath also added a link to another Feedback case. They already exists!
And at the time of this writing, has more points than Windows ARM support, which is on the roadmap.