Why upgrade from 2018 to 2021?

Targets Web
1

About a month ago i upgraded my xojo license from old 2018r1.1 to the latest 2021r3.1

There are a lot of excellent stuff and advantages on this last version.

BUT, for my complete disappointment, there are a lot of problems from migrating web projects.

I’m really, really concerned about this. I did this upgrade to take advantages in speed, compatibility, etc, but this lack of “migration from old to new” is frustrating.

What I mean by this:

If I cannot migrate from the old version to the new version because of one of the items that I will mention below, it makes no sense for me to do the migration, much less the investment made.

From what I’ve been following on the forum and on feedback.app, a lot of people have been complaining about it. A lot of people.

And I keep asking myself (as other people did): is it not time to do a migration-only version? A version where there was nothing new, just and only adjustments and features so that “everything” that existed in old projects, works “100%” in the new version?

Once again, I insist: it doesn’t make any sense to have a new version of xojo, if some items that worked in the old version just don’t work in the new version and/or to make them work you would have to spend a lot of time and money. Much more time and much more money than I spent upgrading Xojo.

I need to know, for sure, when this will be “fixed” so i’ll be able to know WHEN i’ll migrate my web projects to latest version of xojo. otherwise, i spent money for nothing, because if i can’t migrate my projects, why i upgraded?

This are my problems now:

WebFileUploader broken for multiple file uploads.
+Control Arrays missing
+Style Editor missing
+Style conversion/import from old projects
Missing events like MouseExit or KeyPressed for some controls.

Any idea when it’ll be implemented / fixed?

(lines with plus is very important)

Best regards

Alex

1 Like
2

web api 1 to web api 2 is not an “update” it’s a complete rewrite.
if you bought this update not too long ago, you can get a refund IIRC

3

Yes, i know.

But there is no reason for remove control arrays, for example.
Even if it’s a “complete rewrite”.

1 Like
4

Never. Xojo already said many time that a lot of the missing stuff is “by design” so, you are not going to have styles, nor missing events.

As for control sets, reading what they wrote in the desktop user guide: “Control Sets are no longer needed because you can now create controls at runtime and add them to the layout for all project types. It is suggested that you do that rather than use Control Sets.” maybe they are never gona make it to web2.

Ask a refound.

5

It is a rewrite and redesign, as such they removed things that maybe are hard to implement or that they decided not to include because they don’t match the redesign.

From the list of problems you mentioned, maybe the WebFileUploader will be fixed. Don’t count on having a Style Editor or Style conversion/import, now we need to learn CSS to do little tweaks or use a Bootstrap editor to create our own bootstrap theme.

1 Like
6

While I agree that adding controls without needing one on a window is a good thing, Control sets (in desktop) are very useful in certain situations WITHOUT using them to add controls on the fly. In fact that is how I have used them the majority of the time… They allow you to do some things with less coding.

I hope Xojo Inc realizes that and does not deprecate controls sets and I wish they would not say they are no longer needed.

I worry about that because Xojo inc seems to be removing useful features that can also be accomplished in other ways, but at our expense (more coding on our part).

Just because the current devs don’t use or see the usefulness of features added long ago because of new features they added that only do SOME of what the old ones do, does not mean the old ones are redundant.

Designing UI by adding controls on the fly in code is a lot less convenient than doing it via drag and drop… Control sets allow doing it either way, but still have the advantage of being able to have shared event code without a lot of extra coding when that makes sense.

-Karen

4 Likes
7

Working with just a few containercontrols on a Window or Form makes things a lot clearer. Next advantage is that, if you have a vision on how you want consistent GUI’s, you build up a library and work fast and faster.
And yes, even in containercontrols control-sets would save a lot of coding.

4 Likes
8

The thing that attracts a LOT of users to Xojo in the first place is the simple WYSIWYG drag-and-drop UI designer. Expecting new users to jump immediately into on-the-fly control creation is absurd, and even experienced users will often prefer to instantiate controls in the IDE just because it’s a lot easier and faster.

Xojo devs urging users not to use Control Sets in the documentation just because on-the-fly creation is possible is obnoxious and at odds with its stated goal of catering to “the average user”.

6 Likes
9

Yeah, of course!

It’s easier, it’s faster, it’s much more confortable (for me, at least) to drag and simply place on exaclty location i feel it’ll be more atractive.

Doing this by coding, it’s a waste of time, money and energy.

1 Like
10

I used to use control sets with run-time creation of all but one member, because the number needed was not known at design time - the user gets to create and destroy them. Then I found, after a certain moment, that such control sets didnt work on Linux (they could be clicked but were not visible). So I changed to use containers instead.

11

The IDE is not WYSIWYG for web 2.0 . The IDE allows you to create a button that is 15 pixels high or four pixels high, but when it’s rendered in the browser it’s going to be 38 pixels high. There is no choice whatsover.

This is because the average Xojo user doesn’t miss it. (this is what I have been told by Xojo)

12

I would sure like to meet that (mythical?) average Xojo user… they sure seem to be different than me! :wink:

Seriously though, as someone who does not know web technologies and who does want to have to learn them, from a coding perspective Web 1.0 was much more attractive to me than Web 2.0 is.

  • Karen
2 Likes
13

Yeah, I was referring only to desktop.

14

I have upgraded from 2018r3 to 2021r3.1 for Desktop, and most projects have been developed from new or going through any exceptions for language changes. For Desktop the changes have been quite positive.

For web - I’m still in limbo on whether to fork out the cash for a new license as Web 2.0 is quite different and so many people on the forum are reporting issues. I develop on Linux though so the 2018 IDE has some control sizing issues on Linux whereas the 2021 doesn’t, making it easier to use for development.

15

As someone new here reading this, he does have a good argument, which is a bit concerning. They advertise some advantages as being easier than PHP or other languages, as you can upgrade your web app at any time. I don’t see how it’s that different as having to rely on dependencies like JS libraries, CSS or Python/Perl/PHP versions if new releases of Xojo are going to break migrations.

I completely understand the API 2 is new, but he does have a valid point either way. The reason people use other web technologies is that there is no upgrade break path, major new versions are released in steps and usually require little to no changes to the existing code. It would completely destroy a programming language and its users base if there was no upgrade path, just like with anything else.

Example, a framework like CodeIgniter on their new version lost most of its users because there is no upgrade path either and requires a full rewrite of the applications.

3 Likes
16

Ok. I “accept” this argument.

But why not make this transition smooth? Things like “Control arrays missing” it’s a pain! I’ll need to “guess” where all my controls will be to create and move them in code. And to make matters worse, it’s not wysiwyg!!! The size of previous objects changed on new version!

And about no more style editor?… Everything i did on past, size, color, lines, etc, etc, i lost going to the last version! This is not clever, at all.

It WOULD be absolutly necessary to have a transition.

OMG?!?!

17

I know CSS, but I understand people’s frustration as Xojo is aimed to non coders or fast prototyping apps. Makes little sense if you have to code everything by hand. While some code might be required with every software aimed to non programmers, I don’t agree with styling. It’s not that hard to let users click and select colors and styles, which then can create automatically the proper bootstrap theme and code. Maybe it’s coming in the future.

Maybe this helps:
Builder – Bootstrap Build

18

The old “Always in BETA” feeling. You get a couple things fixed, but if you move you loose compatibility with something they broke or abandon :neutral_face:

And WHEN an upgrade breaks all the backwards compatibility, almost all other tools offer actual support and maintenance for some years to the deprecated technology instead of just leave there dead in the wather with no more bug fixes, nor languaje/IDE improvements.

Well, according to Xojo, they know better and this is what you want :man_facepalming:t2:

19

With so many different browsers real Web WYSIWYG is not possible. Xojo Web 2.0 comes close or as close as possible.

20

Every browser has the same standards now when it comes to CSS, HTML5 and JavaScript. There are actually only 2 major browser rendering engines left, Gecko for Firefox and Chromium which every other browser is using, including MS Edge, Vivaldi, Opera, Brave (name your flavor…). I don’t mention Safari because that is WebKit and basically Chromium comes from WebKit. Ironically, Safari is now the underdog when it comes to web standards, as Apple is afraid future web technologies could be used to bypass the app store by developers not willing to give them a 30% cut of their sales.

Said that, as long as you target the lowest denominator, Safari, it will also work in every other browser.

It’s absolutely possible to have a visual editor with click and point buttons that when executed generates code for all major browsers. Not rocket science. The question is if this is the approach Xojo is going for. If they are going with the let’s just code everything approach, then there are gazillion IDE code editors available, even free which are the norm like Visual Studio Code. A professional developer uses a code IDE anyway, me included. My interest in Xojo is more mobile and desktop, being able to target all platforms with the same code. Web is not that important for me today, but it would still be nice having the option to quickly generate web stuff using the same code for other platforms. As long as you can always still manually edit the code.

At least, from my impression reading here, most people pick Xojo because they are not developers or do software as their main job. But if the API 2.0 has new features, it’s understandable they are still building functions on top, and they plan to make it easier in the future.

Just guessing, but at least it seems in my impression, their marketing approach is targeting all platforms for non developers. It means the web part which is not currently a top priority (and I completely understand why) is still underdeveloped and older features are yet not ready. I suspect most features will come at some point that makes web development easier again. For now, being able to code is better than not having the option at all.