I am about to finish a full implementation of an iOSLib extension that offers all the features of UITableView. I have chosen a different implementation path than before (should be a bit faster in event handling), which means you will be able to use a subclass of Xojo’s built-in iOSTable and should in theory be able to build your own custom TableView cells or even a .nib file from XCode and use all the different events a TableView offers.
In theory, because I was surprised how many classes I had to build in order to get this running, and I will need a few more days to finish it. Testing all that stuff would take a very, very long time, let alone figuring out what convenience methods would be wise to implement.
Therefore I’d be grateful for a little help. If you are interesting in testing and giving me a bit of feedback, please drop me a line here and I’ll inform you when I got the stuff ready for test. Once I got enough positive feedback (read this as “debugged all the hastily hacked code”), I would add it to the official iOSLib.
Currently it’s fully undocumented. You should be accustomed to Apple’s developer docs therefore.
I wouldn’t test your qualification, it’s only a word of warning because documentation eats up a lot of time and I’d like to have the project tested while I work on the latter. You find some excellent threads and hints about declares here in this forum, and in general everything that’s in the appropriate Apple docs will have its Xojo counterpart. Except for the class names in iOSLib don’t start with “NS” or “UI” but “Apple” instead, and I shortened a few ridiculously long or confusing method names to something which I hope communicates better. For example dequeueReusableCellWithIdentifierforPath is simply named AddReusableCell.
I’ll gladly send you an invitation to the test once it’s finished. If it’s too confusing, you’d have to wait a few weeks until documentations and tests are done.
Thanks to the forum (again), I did finish a few more things. So far EditMode is working (with or without animation), indentation (here by row number) and a few more events that give you control over the cell before it is displayed (and to speed up the display).
Well, fact is I needed a better TableView, and I like to share it with the community. I have no idea if my code would align with Xojos, and I know not everyone likes to install a library that fills up your project easily although you can strip iOSLib from a lot of things, I only need to find time for the documentation. If it helps a few people until the always busy engineers find time to add an own implementation, then it’s at least building up a bit of good karma for me
Yes, and that’s a good argument. It’s just that the project in itself gets quite big, and I remember the times when I had an old Mac without a Fusion drive. Just opening a project with MacOSLib did take some time. With a SSD- or Fusion drive-equipped modern Mac it’s no real concern. But I surely look forward to when we’ll be able to build plugins from within Xojo.
The image shows what works so far. It’s not intended to win in a beauty contest.
There’s one strange error I encountered: I moved setBackgroundColor to the UIKit framework module because it’s used by several classes. From time to time, the EditAction event crashes with a
When I change the architecture to 64bit or to another device and back, it works reliably again. Could this be a Xojo link error? If you should be able to reconstruct it (I encountered it only twice), Ill move the set method to a local one again.
I am not sure if I am really there yet to understand enough to help you test, but I’d like to try.
Aside from that, I agree with Christoph and Norman. Isn’t there a roadmap that Xojo Inc. would like to share with us people that have actually purchased a license, at least? Gifted guys like you Ulrich could then perhaps target their do-gooding for the community a bit better
Currently I’m a bit stuck. I continued and everything works nicely, until I closed and reloaded the project. The table will then only show the header, the background image and the row lines. The cells are invisible until I delete the table from the view, drag in another iOSLibTable (a subclass of iOSTable) and paste the events from its successor into it. Then everything’s back to normal. iOSLibTable has no custom inspector behavior properties cannot be a problem on that side.
That’s no working state of course. Any ideas what might be going on?
I checked that the events are still called and the rows do exist.
Don’t worry, Hal. Looks like I finally found it. I don’t know why, but after a reload the control doesn’t want to run when you don’t supply it with an EstimatedRowHeight. If there is no estimation event handler, the RowHeight event itself does not fire, and thus 0 was returned and the cells didn’t draw.
I don’t have the faintest idea why replacing the control with a new copy fixed this behavior, but I have an idea that I probably can fix the bug soon.
but I need to let you wait a bit longer. It turned out hijacking the Xojo control was too limited. A few customization options wouldn’t work, and most of all I found no way to catch the standard EditActions, only customized ones. Im therefore rebuilding the control as a custom control, but try to align it with the Xojo implementation although you’ll have to use a few different classes. Storing the DataSource properties isn’t that trivial. I’ll return to this thread once I’m done with it.
I would be more than happy to help you with testing. I’m currently struggling with several issues with tables, and I believe your extensions might solve some of these.
I had to do a few other things first, and as I didn’t find a way to implement all the delegate features on the Xojo control, I am afraid I’ll have to provide a custom control too. Ill post a note here once the project is ready for a test drive.
