How would you add the API2 ADD to API1?

1

As I’m starting new projects in B4 and Swift but leave my big projects in Xojo 2018 R3 and API1 (nearly 20 years of experience with REALbasic / REAL.studio / Xojo are hard to compensate) it gets a bit annoying to add API2 code and then change half the code to API1.

As I did for backwards compatibility (eg add NewPicture) I am adding API2 commands to API1 for forward compatibility (still hoping Xojo gets its act together). Most of the time it is just a renamed function that is easy to deal with (eg DrawRectangle) or a Getter/Setter Method-Pair (eg DrawingColor) but how should I deal with ADD? My suspicion is it might be connected to “iterable” for an elegant solution but that’s where I get stuck …

TiA

Markus

P.S. And yes, I know I can simply rename ADD to APPEND (which I prefer anyway) but that doesn’t deal with the annoyance of pasting in some code and having to fix it all the time for no benefit … and I would actually like to know how that could be done …

2

Not sure I follow

Do you mean ADD in general ? Or with respect to a specific type of control ?

3

I know how to do it for a specific case, eg

Public Function add(Extends arr() as Picture, items() as Picture) as Picture()
  Dim results() As Picture
  For Each item As Picture In items 
    results.Append(item)
  Next
  Return results
End Function

but looking at array.add, listbox.add, etc I have the feeling there must be a more general way …

4

I doubt it
I expect they’re all just additional methods on each one since few share any super classes or signatures

EDIT : A quick check of DesktopControl (by subclassing one) shows Add isn’t in that superclass so its in each control. Its consistency by convention (because Xojo chose to write things the same) not done by contract as part of an interface or other method the compiler can enforce.
I suppose they could have made an interface for Addable and put

Public Sub AddRow(item As String)
Public Sub AddAllRows(items() As String)
Public Sub AddRowAt(row As Integer, item As String)

as well as other string baed ones to others to enforce that consistency
And then had others for specific overloads like

Public Sub AddRowAt(row As Integer, item As DesktopMenuitem)

where the item being added is specific to the type of control

but thats not what they chose to do :man_shrugging:

Personally to avoid all the headaches this induces I would :

  1. subclass every xojo control I’m going to use (in API1 and 2)
  2. put API1 subclasses in a module (API1) and the API 2 ones in a module (API2)
  3. name them EACH “myListbox, MyCheckBox, etc”
  4. alter the compatability flags when you use them (in an OLD project set the API1 compatibility flag to be the one in USE and turn the other OFF so its “not compatible”)
  5. then YOU can put what ever API on them YOU want - methods, events, properties etc
    and by altering them you can keep their API’s compatible

see
https://www.great-white-software.com/blog/2019/10/11/maintaining-backwards-compatibility-in-2019r2/

5

Thanks - that is a bit disappointing. An interface would have been great …

6

I suggested that during one of the betas
It was rejected by Geoff
Dunno if I could find that conversation