After years and years I've figured something out

I’ve never been happy with XOJO recordsets as they seemed to sometimes return the wrong columntype

I was looking in the LR for the field types and its just clicked why that was.

idxfield is one based and columntype is zero based !

10 YEARS! 10 YEARS I’ve struggled to figure that out! AAARGHH!

… I still haven‘t …

:wink:

Just made that idxfield error again :frowning:

There are only a few instances in Xojo where things are 1 based rather than zero. FolderItem.Item and Recordset.idxField are the two that consistently bite developers. I’m sure there are others but those are the most common, IMO.

InStr and NthField too, technically.

seems I’m not the only one!

nice to be in such good company :slight_smile:

I always wait until I get an OutOfBoundsException.

The real problem is getting left and right. Some of the time “driver side” and “passenger side” works. But not always.

I guess things that were 1-based in VB are so in Xojo for compatibility.

I got bitten the other day working with MidB around Memory Block StringValues!

It was 0-based in REALbasic (Real Studio ?)

Re FolderItem: Anything with a Count property will be 1-based for sure.

The good news is, part of API 2.0 is making everything zero based for consistency.

I hope without breaking code.

Based on past experience, they won’t, which means new functions/methods and deprecating the old.

[Hobby-horse warning] Well For...Next (which I don’t like anyway) seems premised on 1-based in relation to Count properties, otherwise it will have to be Count-1 all the time. Another good reason to avoid For...Next.

You’re quite mad, you know…

If I could wish one change into Xojo’s history it would be this:

  • 0-based across the entire framework.
  • Optional named 1-based variants.
  • Optional compiler warning regarding said 1-based variants.

So RecordSet.IdxField and RecordSet.IdxFieldOne (or IdxFieldBaseOne or something). That would allow you to port code from older basic systems (i.e. VB) using a simple find/replace but leaving you with a clear delineation as to old 1-based code that should be updated/made consistent.

One of the things I like about C is that its for statement gives you clear, explicit, easy to read control over this.

Well it’s 1AM here and I’m still coding so I’m probably a little crazy by now. But my favourite with arrays goes like this:

Do until arr.ubound = -1 x = arr.Pop ... Loop

No house-keeping. Love it.

Not criticizing your coding style, but as an example of your point, that’s not the best only because Ubound is perfectly suited for a For loop.

For loops have stepping in reverse ect. so ubound doesn’t always work. Trouble with my code is Pop is LIFO whereas arrays are often used in FIFO situations.