The last full week including the weekend was a terrible experience. I came back to Xojo after 5 years and discovered what a nightmare this whole Xojo web stuff has become. I spend 10% writing code and 90% struggling with bugs, building workarounds, search the web and asking for solutions (Feedback). The WebListBox in 2021 release 1.1 , is totally unusable when there are 100+ rows. Yeah, I get a confirm in Feedback, but then… no solution, stucked.
So the Xojo staff replied and asked to change to version 2019 release 3.2.
Had to bring the code back to the old calls, but anyway. I experienced a fast, and ok working WebListBox.
We purchased the Xojo Cloud because it would be a painless simple solution to host the app. So far so good. My app finally runs on a Mac, but when I upload it to the Xojo Cloud, some parts are not working. After many many hours of trying to do some debugging with MessageBoxes I discovered that the standard WebFileUploader takes my file (just 266 kB), but never calls the UploadFinished. When I search the forum I read this is an old bug, but can’t find the solution. Yeah, change back to 2021 release 1.1. I need a good working Listbox and a good file uploader. Contents in a XML file should be parsed and displayed in a WebListBox, nothing fancy just basic stuff.
Stucked.
I don’t know how to proceed, because developing such simple and basic stuff takes more time as if I would do it in PHP and Javascript. We run a business, not a Xojo bug detection service. So, for a last try my question: Which Xojo version has the Listbox functionality of 2019 release 3.2, and a working FileUploader in Xojo Cloud?
Instead of keeping their customers happy by fixing existing bugs and providing features they want, Xojo Inc. prefer to break existing stuff, replace existing stuff with non working replacements or release new stuff untested adding to the number of bugs they won’t fix.
I recommend you go back to PHP / JavaScript and use something React or ExtJS for your UI.
@Wim_van_Dijk it’s true there are bugs and things are not working that great as you may think, but there are many people here on the forums (and off the forums) still using the Xojo products.
We use Xojo Web, Xojo iOS, Xojo MacOS, Xojo Linux and Xojo Windows all without significant release problems. So if there is a problem, you could try to get a solution that suits your needs.
For Xojo WebListbox i’d recommend to not push all rows in one go, it’s not designed for that (perhaps to keep the server responsive). Instead try to use the WebListbox.DataSource and give it a WebDataSource value. https://documentation.xojo.com/api/web/webdatasource.html
This will have the xojo framework request the rows when it feels there is enough processing time (slice) available to push new rows. If you feel there is an issue with it, report it in feedback (it’s a pita to use it).
Or just go for Node.js or PHP …? Well Xojo web will definately help you get there faster if you know how to (re)design to suit you best. Just ask for solutions on the forums to begin with.
About the WebFileUploader, i feel this class should have been working the right way from the beginning but it seems to be full of bugs (not sure how good it works now 2021 r1.1).
Thanks Kevin, I have to agree with you based on last weeks experiences. What’s the use of having a Feedback system without getting solutions. If I just look at the UI, and how settings are translated to CSS/HTML stuff, it is a mess and it looks like someone who build it lacks good knowledge of basic HTML / CSS. My project could benefit so much from the Xojo approach, but this seems to be a road that wil take way more time as the PHP / Javascript solution.
Thanks Derk, your info is important to me. I have to decide to get my money back or proceed. It is obvious what this has become if I take a good look to the generated webcode HTML / CSS. Although WebListBox API 2 is not designed for displaying 220k data, WebListBox API 1 does it in a glimpse. The knowledge how to build is based on working around bugs, deciding which version and knowing all the pitfalls, instead of at least a reliable result for just some really simple basic stuff. I mean a WebListBox with just 5 strings, 10 characters per string, and by just clicking the header, WebListBox data gets corrupted. That is bad practise. A simple Webfileuploader that fails on Xojo Cloud even when I try to upload one small file. Many regrets I choose Xojo, and far from a solution…
This is what I experienced too. Quality is getting worse. You either have to deal with it or move on. I moved to PHP. I hope to come back to Xojo but things are not getting any better.
I used a different approach : make your own web sdk control with web 2
this way, you control a lot more javascript than using standard controls
it’s quite easy (except again for some lack of examples and latent bugs)
I’m able to go through it.
but I agree it’s a pain to have a 1 year old product with still so many things unfinished.
It may be easy with the numerous issues with Web 2.0 and the incredible delay with Android support to give up and want to walk away, however, I still use Xojo 2018 r3 most days for desktop and web 1.0 projects. Web 2.0 is a very different beast and you’d likely get on much better with Web 1.0. I have tried porting one my desktop apps to the latest release of Xojo - after making the mammoth amount of function name changes it runs just fine so they are getting something very right even if Web 2.0 isn’t quite right for everyone yet. (Due to the lack of Android I had to move elsewhere for iOS and Android but want to come back).
IMHO it would be worth going back to Web 1.0 for now - it’ll be quicker and work until Web 2.0 is fixed if you need some of its features later on.
But to use web 1.0 you’ll need Xojo 2019r3, which (mostly) doesn’t work on Big Sur or newer. On Big Sur it loses registration every launch and won’t save projects in version control format even after registering with your Xojo key for that launch.
I am surprised your API 2 listbox loads are so much slower than API 1. I have written some electric meter reading apps and found that if a user tried to load several years of data into an API 1 listbox, it would take forever. With API 2, the listbox is loaded with only a few more rows than needed to fill the display while the remainder are held in an in-memory database and rows are added as the user moves the scroll bar.
The API 2 listbox layout tools do not work well at all and changing the number of rows in code is a disaster. But if you use a separate listbox with the number of rows fixed, the system will assign the column widths to fit the data and it works very well (unless you need fixed widths). My biggest complaint is that sorting is limited to alphanumeric. A clickable header cell would allow the listbox to be refilled with new data sorted in the desired manner, but that is not yet possible.
Thanks Dean,
I need a lot of columns for the listbox, example: to display each day for a whole year with just a small number in it and many rows.The way it behaves now, the widths are not fixed. This is because the IDE setting says: widths, but are assigned in the HTML/CSS style as max-width. I mean, c’mon. In web 1 it was assigned as HTML/CSS width. Simple stuff like that, but I don’t know how to fix it. The app is on Xojo Cloud. Tried some CSS overrides, but very hard to get it fixed because of the hierarchy in CSS and the fact it is in Cloud. Besides that with multiple columns the headers disposition in relation to the rows.
My next concern is that the new web 2 approach sucks. There are a lot of Javascipt HTML dynamic table solutions available, very fast, beautiful and capable of storing huge amounts of data without trouble. How they do it? Simple, get away from the standard HTML table and build the dynamic “table” with DIV’s. As you all can see web 2 is not like that and it will never be as good because the fundament is bad. I sent in a web 2 simple WebListBox app with 5 rows, 1 column with each a 5-10 character string. By just clicking on the damn thing I manage to get the data corrupted. So my biggest respect to those who have this thing working without errors. I can’t…
Well, this is Xojo. Never a final version, always a Beta that feels like alpha. Not easy to choose a release, in a newer you get a fix but in exchange for 2 new bugs.
I Use 2018r3 for web as it was not wort it to spend money on anything newer, web1 is dead, web2 is not near fully functional. Webuploader is not working in the las release, bugs are marked as fixed BUT, who knows the release date of that new version with this bugs fixed and who knows what new bugs will be there.
Then there are those of us who use Xojo day-in and day-out without any major complaints. There are some things to workaround at times, some things that need further study of documentation or forum topics when implementing, but it’s still a heck of a lot faster than building a framework from the ground up, using some of the frameworks for other languages, or learning entirely new languages.
Does Xojo always get it right? Of course not. No language/framework/IDE does, especially when you have a company that builds all of those in one product, but Xojo ticks most – if not all – of the boxes for me and a lot of others. If it doesn’t do what you need, nobody will tell you to use a tool that doesn’t fit yours or your project’s needs, and I hope you find the solution that best suits you.
As for Xojo Cloud, you don’t have to spring for it. I’ve been running Xojo Web apps on basic VPS forever now. It takes a little more work to setup (unless you have Lifeboat) and maintenance, but it’s certainly doable and dependable.
And, hey, if you run into an issue – with the uploader for instance – you can always try one of the alternatives like GraffitiUploader, or the previously mentioned Plupload component for Web 1, or even throw together a PHP script to handle the upload then call it from within your Xojo Web app. All it takes is some looking around or a little imagination. And I quite like Xojo, honestly, despite (or because of) all of my experience with other languages.
At any rate, I hope you get what you need. Whether it be from Xojo or another toolset.
