I am trying to update my iOS apps with Xojo 2019 R3, I have not worked on these for a few years so I don’t know if this is a result of R3 or an earlier version, but I am getting an error when I try to run the app that states.
“The constructor of this class is protected, and can only be called from within the class.”
The code that causes the error is:
cellData = New iOSTableCellData
The method the code is called in is Public, so I don’t know what is going on here. The full code is below.
[code]Dim cellData As iOSTableCellData
Table1.AddSection("")
cellData = New iOSTableCellData
cellData.Text = txtChapter2.Text
If txtCount.Text=“0” then
txtTotal.Text=“0”
Else
If txtCount.Text=“1” Then
cellData.DetailText = " Average Score " + txtTotal.Text + " Out Of " + txtCount.Text + " Attempt." + " Study Time - " + txtHours.Text + " Hours " + txtMinutes.Text + " Minutes"
else
cellData.DetailText = " Average Score " + txtTotal.Text + " Out Of " + txtCount.Text + " Attempts." + " Study Time - " + txtHours.Text + " Hours " + txtMinutes.Text + " Minutes"
End If
Is that actually a good move?
I’m learning the way to do that, currently converting from using AddRow to using a DataSource (with an iOSTableDataSource interface). There, the RowData method returns an iOSTableCellData.
With the old way (which I never actually used, but I thought it would be more on purpose), one would just create an iOSTableCellData (set the cell up and return it).
With the new way, one has to:
add a property to the class, holding the iOSTable (since you can’t use CreateTable from an arbitrary table)
use the iOSTable.CreateCell method (which, by lack of documentation, doesn’t explicitly state whether the method actually creates room for the cell or otherwise does anything, or just returns a cell without doing anything else (why must it be called from that table instance in this case, and not the class definition?)
avoid referring to the sample code of the CreateCell documentation (where AddRow is used, which is what I exactly want to avoid in the first place)
return the iOSTableCellData object created. Probably the framework adds the row to the table, which we could just have done from in the RowData method.
Looks over-complex and a bit illogical to me. But, well, if those are the right steps (please tell me), I’ll learn toward that way.
[quote=479110:@Paul Lefebvre]The interface has the table passed in as a parameter to RowData so you should just be able to use that instead of setting up your own property.
There are more examples is this topic along with a list of all the various example projects:
Currently, learning is going its way. My history list is showing fine and the steps make sense, I agree. I’ll still have to handle the Remove button.