Will converting to API 2 be mandatory in next future?

General
41

Chaining? I thought it was new and we had only functions as most people here wrote code in the ancient method. But I read that many, but not most methods as I noticed since api2, were introduced in v5 and up.

1 Like
42

That’s a too expensive code under a good compiler.

1 Like
43

You never did prepared statements under API1, then? With API2 you essentially don’t have to bother anymore, it’s all done for you.

4 Likes
44

If your problem was absence of line breaks, this also solves your problem, but for ME small one liners reads better at a glance, maybe my brain processes better horizontal contents at once than vertical ones:

api2 = s.NthField(".", 3) _
        .Replace("g", "x") _
        .Right(4)

I also hate the BASIC continuation mark even though I use it very much

2 Likes
45

That change couldn’t have been done for API1?

4 Likes
46

I think, the real problem was the massive change done in one time.
$
If I wanted to use a diferent language, I left this one and go elsewhere.

I do not wanted to do that, but GPDevelpments (try to) force me to do that…

Incompatible project file format,
Massive changes in the language,
Deleting large part (with no replacement *) of the language (I use on an everyday basis)…
Nice looking Language Reference with the same ‘good old contents’ instead of changing the contents. For someone who says ‘changes are good…‘

  • GetFolderItem removed. One have to use a Constructor to get a FolderItem.

Xojo is 9 y/o. When it will have a brand new name ?

Original IDE: 1998-2004 (or was it 1997 ?)
New IDE: 2005-2013
Xojo IDE (browser like): 2013-2022 and running…

1 Like
47

And what is wrong with that?

3 Likes
48

I don’t think that Str() was deprecated. It is still a full-fledged part of the language, No?

2 Likes
49

You’re correct, but only because Xojo kept a number of those global functions in place for VB compatibility. The Str function violates two of their rules: it’s abbreviated, and it’s global. There are a handful of these kinds of functions.

1 Like
50

This is the real problem. If we want to update large projects, we have to work a lot of hours with no advantage for our customers (and our bank account too).

That’s all. I’m preparing to spend a lot of time in the next future, because someone decided to make a lot of language changes at the same time. This is sad…

2 Likes
51

@Sergio_Tamborini

Then don’t upgrade your project. If you want to use API 2 for new stuff, do that.

I don’t see what the whole thing is here that’s driving people to upgrade their projects to the latest & greatest thing.

4 Likes
52

I never understood why the Xojo people (and the former ones) don’t listen:

  • My brain retains ONE single set of instructions.
  • Writing code without autocomplete sucks.
7 Likes
53

For me, it’s the analyzer. I use it extensively. #Pragma Warning and #Pragma Error are used to remind me to get something finished. I deprecate methods (and sometimes classes) when refactoring. And of course, just catching mistakes. A stable release doesn’t go out the door unless my analyzer is empty.

So when the analyzer has thousands of deprecations, that’s a problem for my workflow. Even if I chose to ignore the API2 stuff, they will still flood the list, making it very difficult to find the things I’m actually interested in. Turning off deprecation warnings isn’t an option, since I actually want that info. So for me, the only practical option is (or was) to handle them.

6 Likes
54

Maybe its because the IDE doesn’t allow people to work on projects in a v1 API only mode.

We asked for it and were told no.

2 Likes
55

The last time Xojo made a new project type (and yes, that’s what it would have taken to split api 1 from api 2), the community didn’t like that either. So yes, you are right. Xojo said no.

Now, to be completely fair, I personally do not think that what we were aiming for back then was a “if you want to start using API 2 in your project, you need to convert the whole thing” kinda deal. Edge cases came up that caused that to happen so late in the implementation phase that we really had no choice. I’m not saying that it’s perfect, but it’s what was done.

Now, one thing you can do is keep using 2021r2.1. Xojo has statistics about how many people use a particular release, so if enough people keep using a pre-API 2 release, maybe they’ll get the point. Not that API 2 should go away mind you, but that there needs to be better autocomplete support for older projects that may never be converted. IMO that is something that’s certainly within the realm of possibility and would go a long way towards some good will for long-time customers.

2 Likes
56

And the deprecation queue. One day, that not updated items, will change from warnings to errors, and a slow upgrade of the code with tests in the past may become a race to a urgent half baked half tested release for tomorrow.

1 Like
57

Well, yeah, that’s what we’re doing. It sucks because AutoComplete is less than ideal.

A question that I’d like an official statement from @Geoff_Perlman is what is Xojo doing about this? When is the IDE going to be 100% API2? If it’s anything less than soon then why the heck should we supporting a project that isn’t truly ‘eating its own dog food’? If the answer is not soon then what are you going to do to make it easier for many Xojo developers with to still work with API1?

3 Likes
58

Would it have really taken a new project type just to hide v2 API from auto completion and to hide warnings? If it really did then maybe that limitation should have been addressed first.

Xojo should have disabled the v2 API at that point until a later date when it fully understood the ramifications of what it was doing.

That works for some but unfortunately, others have to upgrade to get fixes for stupid bugs introduced into the IDE, compiler & framework.

1 Like
59

If you really want to stick with Desktop API 1, I think these steps might be helpful for some of you:

  1. In 2019r1.1, create a new Desktop project. Save it in Binary format as DesktopAPI1. (Download here if you don’t have 2019r1.1 installed.)
  2. Copy the DesktopAPI1 project to the Project Templates folder in your 2022r1.1 installation.
  3. When you want a new Desktop API 1 project in 2022r1.1, go to Templates in the Project Chooser and select DesktopAPI1.
  4. Your project now uses the Desktop API 1 controls. Autocomplete should show both API 1 and API 2 stuff.
4 Likes
60

@Paul_Lefebvre - Those things do not solve the Autocomplete issue. 2021r3 and forward only autocomplete the non-deprecated API 2 stuff.

1 Like