I am planning on making a web version of my software. I assume this is going to be a lot more difficult than I am expecting right now, but what can I expect going in? Complete redo or touch up work?
Thanks!
Difficult to tell you without knowing the kind of app it is. There are many limitations to the Web framework, which may or may not impact your app. Among others, the UI refreshes only when events are over, which means ProgressBar and other things of the same nature must be run by timers.
You will have less immediate control with text justification, fonts and colors, since that has to be managed by WebStyles .
In terms of porting, if your current app does not have too much logic within controls, usually you can simply copy/paste methods, modules. There are differences between the two frameworks, but there are usually equivalents. As long as you use pure Xojo code, you should be fine.
In my experience, it is more a matter of a lot of touches than complete rewrite. Just a matter of patience, and looking a lot in the LR for websomethings.
if you use the listbox to edit data, or a styled text input control expect a whole world of pain!
however…
Once you get the hang of container controls, its really a nice way to work.
I still think a proper editable listbox and a styled text control should be built in Xojo controls though.
[quote=193557:@Russ Lunn]if you use the listbox to edit data, or a styled text input control expect a whole world of pain!
however…
Once you get the hang of container controls, its really a nice way to work.
I still think a proper editable listbox and a styled text control should be built in Xojo controls though.[/quote]
CRAP! My entire program is run off of a listbox as it is a high pressure graphing system and I use the listbox to hold the data. I take it that makes my mission not possible?
If the listbox does not actually have to be visible, you can just as easily create a session or page or class property that is an array, with the same structure as your current desktop listbox.
If manual data entry is required, you can simulate the listbox with text boxes in a webcontainer. There are also replacements. I would suggest to have a look at Daniel Taylor’s web controls. I am using his web treeview as well as a few other of his controls with success in a couple of applications. Daniel has been very helpful even when my problems were self-inflicted issues I am ashamed of bringing up. 
You will have to put the data in an array instead.
The WebListBox is just a viewer which does not allow any data entry. Among the solutions I have used, besides a bunch or TextFields in a WebContainer, is a WebListbox that is used to view only a set number of lines as a window on data. Scroll being achieved by moving data behind that window, row by row. The advantage is that you can have ScrollPosition (does not exist in WebListBox), and use a TextField placed over a cell to do EditCell.
There is a lot that is much better on the Web such as multi-line listbox cells, only one screen to manage at one time, multi-user access automatically and WebStyles (a pain until you get used to them!).
I have a huge app with two windows: one for login the other main one for everything else. The main window has two levels of toolbars and about 60 containers (and sub-containers) plus about 40 dialogs to display all the information you need. Containers are your friends on the web!
You must get used to threads and timers, otherwise things will freeze for other users if someone does something intensive. Consider running multiple Helper apps to spread the load across more CPUs as well (I have a Scheduler to run tasks if/when the user logs out).
I have entirely different interfaces, but share 100% or code between desktop, console and WebApps. You can do this by passing items as an Object then working with them appropriately for their platform.
The biggest benefit by far is having only one app to update. I run mine as standalone apps since it’s faster, safer and easier to manage.
To be nitpicky, this is 100% true of desktop code as well. The only difference is that Refresh exists on desktop to force an update synchronously. But I recommend that like I recommend walking on hot coals.
Y’all rock!
Now here is a question…
Serial port communications, SMTPSecureSockets (for emails), and canvas.refresh, do they work the same/similar or is that a rewrite?
should all work as is, but remember that they run from the server, so the serial device has to be connected to the server. if thats not possible, id suggest serial to ethernet modules, they work very nicely.
Also the emails will be sent from the server.
for the serial port, i would make it an object on the app, so that multiple sessions don’t try to talk to it at the same time.
the email part could be a method of the session object.
The canvas object has a few differences i think. i’m not 100% sure, but i think it has to do with things going out of scope before they get drawn, so you have a picture object in the session that you draw to, then in the canvas paint event, you draw the picture in.
others will have more info on that though.
SMTPSecureSocket is not secure…
see
https://forum.xojo.com/22855-smtpsecuresocket-encrypted-transfer
One other thing you can take advantage of on a Web App is dialog screens. I used them sometimes for data entry or other user interaction. They can pop over as modal or I like to slide down from the top like you see many Apple desktop apps work.
I believe this works pretty good because you can leave the underlying screen in place and do little user interactions in a modal dialog then make them disappear. This saves switching screens to do user interaction then having to reload to go back to a “main” screen.
Of course Your Mileage May Vary based on needs and your personal preferences.
+1 on dialogs. All my search help screens (find a client, find a document, etc) in my current web app project are webdialogs. Datepickers are shown in a webdialog. I also use webdialogs to enforce strict formatting of phone number inputs, etc. Works very well.
For all intents and purpose, a palette dialog works like a window, except it is available only within the browser view. Nevertheless, that is convenient to adapt certain desktop projects.
There is a bug in Modal and sheet which makes them report width and height inaccurately when they have been resized. But to be fair, modal windows are not too often resizable in desktop.