Hi guys. I’ve recently updated a large Mac/Win targeted project to Xojo 2013 from RealStudio 2011. Some questions about Web targets, if you please…
In Xojo 2013, there is no way to load the project and re-save it as a Web project. Is this still the case in the 2016 version?
Has anyone made a project converter?
Xojo control (UI) plugins do not work/compile for the Web target. Correct? We will need to revert to built-in controls.
Is there a significant reason I would want/need to obtain a current license and work on the Web target in the 2016 version of Xojo as compared to the 2013?
Anything else I should know? The initial testbed server will be a CentOS 6 box connecting to MySQL.
All this is essentially correct. Controls are not compatible between Desktop and Web.
However, if your app is written with most of the logic in methods, it is a fairly simple task to recreate the UI and copy/paste logic. Otherwise if you have a lot in events, you will have to add events manually, and then copy the content.
As to why you should work on the web target, it is entirely based on your strategic decisions…
Unless you find that something doesn’t work, you shouldn’t have to.
However, you may find that custom controls like HTML Edit for Web might require 2014r2 because of changes that were made to WebControlWrapper that opened up some new abilities.
In Xojo 2013, there is no way to load the project and re-save it as a Web project. Is this still the case in the 2016 version?[/quote]
Save and Save as only refer to the file format saved as (Binary, XML, or Text_) and not the project type (iOS, Desktop, Console, Web)
And no there is no “convert to to a web project” for me as the two types have really different characteristics
On the desktop using Keydown is fine
On the web this will likely give you a less than ideal experience because of latency, etc
[quote=273325:@Christian Miller]In Xojo 2013, there is no way to load the project and re-save it as a Web project. Is this still the case in the 2016 version?
Has anyone made a project converter?[/quote]
We had a utility at one point that could do some basic conversions between desktop and web, but it was lost in a hard drive failure a few years back. The problem was, like any conversion utility, it did standard controls okay but subclasses and/or complex controls it just didn’t work well. Plus, there are enough event different events that you’ll want to use the web-safe events anyway. Some control events you really don’t want to use in your web app.
Correct, but there are 3rd party controls out there. Web Custom Controls, Graffiti Suite, and Jeremie Leroy (and others) have created their some decent stuff out there.
Nothing significant in IDE changes but as with everything Xojo the framework gets updated over time. There is now limited drag and drop introduced in 2015 (forget the release). In 2016 R1.1 got a significant boost in compiler speed to make it worthwhile on any largish project. You can also create 64 bit web apps now too.
@Bob Keeney Sooooo… I’m having trouble getting the app to launch… 2013 only builds 32-bit, correct? If my Linux server is 64-bit, it won’t launch, correct? I’m getting “Unable to launch application ‘xxxx’ on port 80” via the web browser and the error log displays ‘Can’t exec “/path/to/app”: Permission denied at /path/to/app/app.cgi line 326.’ Line 326 says: ‘system(@args) == 0 or return 0;’
I’ve checked and the permissions and owner/group are all as they should be.
If you are on a 64 bit server you will need to install 32 bit compatibility libraries. Which is why going to a newer version makes sense because then you can just build it for 64 bit. No 64 bit debugger yet, but we’ve only had a few issues with builds.
Alright… I updated to 2016 & compiled for 64-bit. I spent hours & hours trying to get a simple web app (1 button & msgbox) running on my CentOS 7 VPS. Did I say hours? It always timed out. I changed from compiling a CGI app to compiling a standalone app, opened a new port in my VPS firewall, and it worked right away. Pros/cons to this solution? Am I guessing correctly that this will only run with a single connection and not let multiple users/connections hit the app? Hmm… could that be the problem with the Apache/CGI? It was trying to open another port for the connection and the firewall (iptables) was blocking it?
Standalone has several advantages. One is that you don’t need Apache or IIS server as it acts as its own web server. Two, it’s tied to a specific port so, theoretically at least, it’s a bit more obscure. They are a bit faster, IMO.
The disadvantage is that they keep running until someone stops it or it encounters an error it can’t recover from. Error handling will help but any sort of memory leak will accumulate over time and eventually kill the app. You can get over this by using system automation, like cron, to restart the application if it’s not already running.
The cgi apps can shutdown on their own if there are no sessions and you allow it to auto quit. This mitigates memory leaks. The first user accessing the app has to wait for it to spin up.
I haven’t done any work with load balancers so I don’t know the advantage/disadvantage of cgi vs standalone.
Looking at server logs might give you some indication of what’s going on. It’s usually some pretty obscure stuff so good luck finding it. Look for things like Premature End of Headers.
I know one of the things that I fought for a while on some servers was FTPing the files up changed the user/group in permissions to something other than what it could run. Once I switched to the CPanel file transfer it worked fine.
Another issue that’s bitten me is that there is a hidden .htaccess file generated by the IDE that you’ll never see on the Mac. Make sure you zip and upload the entire folder or you most likely won’t actually transfer it. After the first time you don’t have to upload it every time.
The uploaded files need their permissions set properly, but the containing directory needs it setup too.
The config file needs a permission that’s different than the other files. Off the top of I don’t remember but it’s in the documentation.
I’ve not had to worry about it for a while since I switched servers, but I had to add a line to my .htaccess file to get the cgi application to work. It’s probably somewhere in the depths of the forum.
So I have felt your pain for main years with deploying web apps. Once you figure it out, for that server, write it down! There’s nothing worse than having to relearn it 3 months later when you want to deploy a change and you’ve forgotten how to do it (because they’re all different).