HI All
I was wondering if there was a way to use Xojo to create seperate HTML files instead of a single bundle? My clients find it frustrating when going back a page.
Also I find it unusual that the WebSDK doesn’t support this, I find that most websites don’t function like this anymore. Instead there are workarounds and hacks to make it function properly when using the back arrows on the browser.
Am I missing something to make this work easily?
Thanks in advance
I worked around this behavior by providing a “Return” button and structuring my web apps to center around a menu page. It is good enough for most of the use cases that I need to address. Using containers and dialogs, I am also able to go back one ”page” where necessary.
You may be interested to look at the GraffitiSuite (Web Edition) Pagination control, which would probably answer your needs, if I understand correctly. For sure, using the standard navigation buttons is not available to us, or I never figured out how to do it. I have not used the Pagination control yet, but I am considering using it for an overhaul of one of my web apps.
Hoping that this helps.
We’re supposed to be able to use SaveState to manage the history, though I can’t comment much on how.
Has there been any talk of creating individual web pages? Can this even be done with the current setup?
Will look into these options
There’s been pushes for SEO improvements, but I don’t think what’s being worked on creates the “normal website” environment that you’re trying to achieve.
There was some dangerous project-breaking change that allows WebPage.Show at will in HandleURL in 2026r1. But, because of how untested and project-breaking this change was, it will be changed in the next release. I would not make any plans around this feature until 2026r2 actually comes out.
Thanks Tim.
Would we be better off manually coding to make a ‘normal’ site? Defeats the purpose of a powerful IDE. I like how it can be programmed but the bundled approach reduces it’s effectiveness, but’s probably where all it’s power comes from.
Xojo Web was designed to be paradigmal with Desktop. In Web 1.0 having the app behave like a website, such as making use of the Back / Forward buttons, was not the goal. Platform agnostic code and development time were higher priority. Different time, different goals.
The SaveState thing is the Xojo framework feature for hijacking browser history, but I’ve never used it. My web apps have intentionally been temporal (I intentionally want the session to be destroyed when navigating away). No need for a Logout button if closing the Session is unrecoverable 
I don’t know what’s best for you. It could be a design problem that your users think the back / forward buttons do anything, or that they should be using those to begin with. I’m not saying it’s THE answer, but perhaps there’s a design change you could make to fix users even wanting the back/forward buttons.
(The link preview above did not indicate it was a direct link to WebSession.SaveState, so I’ve re-linked it again)
I think it could be done with a websdk. let me think about it.
SaveState does work. Every time the user does something that you want them to be able to “go back to” you call SaveState. If you were doing something like a form where you wanted the user to be able to go back on a page panel within the same page until they’ve save the incremental state, you’d use the “replace” function. The trick is to include data that is meaningful enough to return the user to where they were so when the event fires on session, you can take them to the right state.
On many (but not all) browsers it’s possible to hijack some of the hot keys as well, including refresh, to prevent users from accidentally starting a new session. YMMV
here you are : a demo webapp to show 4 methods to have back browser button working.
What Xojo creates is Web Apps, not Web sites. To create web sites there are lots of solutions. Xoj is not one of them.
sure, but it’s still nice to have a back button even in a web app !
small update 1.1 to have a non visual WebSdkControl
the previous one was a WebSdkUIControl that exposed no visual component.
With Web sites, going forward and backward is natural, because the user looks at pages. When using a Web app, the user inputs data and reads back data or reports. A Web app may need to follow a process, and going back one page may not be possible. Witth Web 2.0, a back button can be implemented though.
When using an app on a desktop, usually there is no back button, then I consider that it should be the same with a Web app, where a Menu bar, buttons and contextual menus should be implemented.
My 2 cents.
I ran this and it worked exactly as I expected. Thanks for the demo file and the extra info and details on the GitHub site.
The first two methods run without an error in the IDE. The second two show an Event Loop error. See attached
This might be worth a separate thread, but is there any way to intercept the back button as an event? Then we could manually update the UI to represent a “back” state.
so you mean method 1 and 4 are working but not 5 and 7 ?
it may be related to windows or the browser I tested the 4 methods on macos and they all run fine…
That’s exactly what SaveState is for. Remember, everything on the browser is asynchronous and by the time your code runs in the event, it’s already completed on the browser.
