API 2 Bit Me This Week And I Wasn’t Even Using It

I had one of those weeks where my nearly 20 years of Xojo knowledge went up in smoke.  I started a new project and was using the classic API.  I did this because it was a database application and I’m not convinced that the major database changes with API 2.0 are tried, true, tested, and worthy of every day usage.

I was testing to see if a string was contained in another string and did this:

Dim bDoesNotHave As Boolean = sString1.InStr(kSomeConstant) = -1

Gosh, where do I even begin to explain the hot mess this is?  First, InStr (classic API) returns a zero if sString1 doesn’t contain the string kSomeConstant.  Second, the API 2.0 replacement is String.IndexOf but that does return -1 if the string isn’t there.

Thankfully, testing discovered that the code wasn’t working but I felt pretty dumb.  This is one of those areas where I think API 2.0 is totally going to mess old timers like me up.  I’ve used Instr for nearly 20 years and all of a sudden my brain tells me, oh, no, this returns -1 if the string isn’t there.  True – only if you’re using API 2 and I was not.  Which is so weird because I’ve not created ANY new projects in API 2 – just some random testing.

I’m mad at myself for not remembering and mad at Xojo for changing the rules.

13 thoughts on “API 2 Bit Me This Week And I Wasn’t Even Using It

  1. You’re right. Xojo should not have the same-named functions returning different values. Xojo should use different names if the behaviour is different. Code is contract.

    • See, I almost think you should pass in a ByRef variable that gives you the index and returns a Boolean if the search string is contained.

      dim iIndex as integer
      if sString1.InStr(kSomeConstant, iIndex) = true then
      //Found string now do something with it
      end

      Overloading becomes harder then. Maybe impossible with the way it currently works?

  2. Might also add the user base hasn’t made this issue any easier. When Xojo Inc separated the new and classic framework via namespaces citizen-devs considered it too cumbersome.

    Then people touting themselves as pro devs wanted zero-base arrays in api 2 which I argued strongly against. After all, only in the pro dev world do people consider a zero refers to one of a thing. Makes for nice loops but otherwise how stupid is that?

    So in the case of namespace Xojo Inc decided in favour of citizen devs but in the case of base counts decided in favour of pro devs and here we are in the land of confusion. What I said at the time, is to let the devs set the base be it zero or one as Visual Basic allows. But that is expensive for Xojo Inc to implement and maintain – in effect doubling up the language. So the best compromise I suppose would be to name things differently api2. But in my opinion the pro devs made the wrong call on this one.

    • I have zero issues with the zero based arrays. If they had gone 1-based I think many developers would be even more pissed off. The problem, as Karen points out below, is that some methods were zero and some were one based.

      The Xojo framework was pretty good. The “wall of code” that people complained about was a stupid argument IMO since you could use Using and eliminate the wall.

    • Option base was the source of so many issues in VB I’m glad Xojo does not support it at all

    • One of the problems with namespaces was that you had to know in which namespace something was before using it (difficult for beginners, lots of extra code, harder to read), or use USING everywhere which begs the question what use the namespaces were anyway. Most people simply saw no benefit in them.

  3. “When Xojo Inc separated the new and classic framework via namespaces citizen-devs considered it too cumbersome.”

    I don’t think that was necessarily a divide between pro’s vs non pros. i think it was more people who found walls of code hard hard to read and those that did not.

    Not being pro I may be mistaken but for me a bigger issue is that, regardless of the NameSpacing. the Xojo framework just made a lot of things more work and less RAD by it’s design.

    “Then people touting themselves as pro devs wanted zero-base arrays in api 2 which I argued strongly against.”
    Arrays were always zero based in RB …and that is fine as they are an abstract n-dimentional data structure (and that is why using Row/Table terminology with them is an abomination IMO) …

    Counting “things” tended to be 1 based (FolderItem children, String position)and that was OK too…

    But there were cases where they messed up and mixed 0 and one based counts… RecordSet.IdxField in 1 based but RecordSet.ColumnType is 0 based…

    THAT is a real issue that i have tripped over a number of times…

    There was no need to make EVERYTHING 0 based IMO , as long as they were consistent in how they used each base.

    -Karen

    • AFAICT it only made it less RAD because folks hated the “wall of code” which actually served many purposes – that no one cared about because that simple little decl for something turned into several words instead of one
      Instead of “Memoryblock” now you had to wrote “Xojo.Core.Memoryblock”

      And now we get to return to bitching every time Xojo inserts a new global keyword or class name or something else that clobbers something we have used for years as a class name in our projects

  4. Maybe it isn’t API2 that tripped you up, but the ListBox? THERE (and maybe some other places) you do check for -1 when it isn’t a valid row.

    • Hm…maybe, but I had never made that error in the past. API 2.0 just muddies the water a bunch and makes me second guess myself a lot now. Clarity won’t happen ever on our projects since they’ll never get updated to API 2.

      • I wonder how many long time users are in this position of “not going to update”

        • I simply see no reason to update unless I’m forced to. I might, maybe, use API 2 in a new project but even then I might not. 20 years of muscle memory…

        • I await what will happen this summer. Will WE 2.0 be released with the prospect of stability within a short time. Without the ability to start stable projects based on WE 2.0, I still see no need to switch to API 2.0 for desktop and console projects, other than the fact that API 1.0 is no longer being updated and I would end up in the well-known VB 6.0 déjà vu.

Comments are closed.