iOSControls update

Just made an update to the iOSControls lib by adding a demo screen for the textfield extension module and wonder why Github tells me it cannot show files that big??

… and another update, this time with an iOSTextArea extension module. Link is the same.

… and because an iOSTable shares the UIScrollView features with iOSTextArea, here’s an addition to it. Zooming doesn’t seem to work in both Tables and TextAreas, but I left the methods included in case I err (or to have them available for other scrollview extensions.)

Why are you not using Xojo Project format? Would be much easier to browse the source, see changes, etc.

Didn’t your original Table version had the ability to change the background color?

You can. Table is a subclass of ioSControl, therefore you should find all iOSControls (UIView & NSObject) methods in it.
And thanks for the hint, Thomas! Changing format right now.

Addition: Yes, they’re there. Just checked it.
Use mytable.backgroundcolor = yourcolor, or even mytable.setbackgroundcoloranimated ( … )

You probably should include the missing code files too :slight_smile:

Oh! blush I see!
Boy, that sourcecode thingy gives me hard times. Better now?

[quote=159372:@Ulrich Bogun]Addition: Yes, they’re there. Just checked it.
Use mytable.backgroundcolor = yourcolor, or even mytable.setbackgroundcoloranimated ( … )[/quote]
… but for row background, that was another thing. Will see what I had done there …

Ulrich - the controls look great - well done on creating them!
I have a question - are these native controls which you have access to through your declares - or are these self made replacements?

Just curious :wink:

Those are native (hence the declares). :slight_smile:

Sorry, I was referring to the row/cell background. :slight_smile:

Sorry - I should have said…are they ALL native controls via declares :slight_smile:

Hi Richard,

thanks a lot and yes – when you look into the Lib folder you will see that almost everything is realized by modules hopping onto Xojo iOS classes. There’s a few things for wich was no replacement available like the Notifications but they’re done completely via declares. In case you need Events for custom animations you would have to use the UIImageView subclass but this is a child of the Xojo classes again.
Of course I would have to leave this path once I walk deeper into visible controls not yet available, but that’s something I still have to practice more. For now: No views mangling, no replications.

… but you should not try to build the project. This takes an awful lot of time on the animation views – I wonder if it is because of the cross-referencing constraints. Better copy the Lib into an own project when build time has arrived.

I am just trying to determine if it is worth trying Xojo for iOS at the moment.
I believe there are many controls missing, and that the auto layout seems to be causing confusion for others.

Before I even attempt Xojo for iOS, I need to ensure that all the controls I would need are available natively.
I am getting the impression it is better to wait 3 or 4 more releases, before considering it seriously.

I will keep an eye on the forums to see how it is progressing :slight_smile:

I reread the docs and believe that we could get a better solution by addressing the Data Source interface. Sadly, again, I’m short on time but I will try to add that as soon as possible.

@Christoph: But it doesn’t look good. I can use the datasource but row colors are unreliable again. And this is no bug but a (Currently hard to handle) feature. I reviewed Richard’s UITableView addition ( and found that the reason it seems to work is he sends the table in an endless timer-based setbackgroundcolor loop.

Reason for all this is Apple reuses cells for performance reasons. So when you address a cell it can happen that a former cell that was prepared is taken as a template for the new one to draw. The only reliable method seems to be coloring the cells from inside the datasource/delegate object. This is ridiculously full with methods and I shy from creating one myself. I think the bestway would be to post a feature request on implementing the tableView: willDisplayCell:forRowAtIndexPath method which should allow to create a cellpaint event like on desktop.
A possible workaround would be to create a custom TableCellData constructor with separate ReuseIdentifiers – when the identifiers are different they won’t be reused. But this would lower performance again, and cells are made from Nibs and I don’t have the faintest how to call the appropriate ones.

Table cell are at a very basic level.
We really need to be able to subclass it (and the class name could be the ReuseIdentifier internally) and an handle to be able to do many of the common customization that now we can’t make.
Even better if we could visually design these subclass.

Do you know if a feature request already exists?