I did find the “free gift” another Xojo user shared about a port of a JS web palette dialog of some sort from 2021…but here we are in 2025…and Web Dialog Palettes are still not to be found in the mainline IDE. I know everybody loves a nice Single Page Application…but sometimes I find that too limiting. I’ve been trying to figure out how to port my Web 1.0 based app into Web 2.0. Assuming that a Web Dialog was meant to be just that…a fairly simple “dialog”…then I’ve taken some real liberties with it. I’ve considered that I need to turn my dozen or more palettes into individual applications, though some palettes will launch other palettes (usually by sending a message to the Parent Application and requesting the launch of a specific type of palette. How would I create my app (see image) in Xojo Web 2.0 today?
If you want more window-like dialogs for your Web 2.0 application, I provide and support GraffitiAlert.
If you want to stick with Xojo’s built-in functionality, you’ll still need to write some JavaScript for some functionality.
Thanks Anthony, I hadn’t considered GraffitiAlert, I will look at that as a possible solution to my “many windows” problem with Web 2.0 – It would be “nice” if the Folks at Xojo had built-in support for this – but as there are some viable alternatives - I’ll investigate this. I already have some GraffitiSuite elements I’m testing at the moment. I really wanted smooth Excel-like in-line editing in many of the grids (multi-column list boxes). I tried several ways to implement this…the best solution I found was GraffitiWebGrid. The only pseudo-issue I found was the resize of the “window” which doesn’t work (in my opinion) as nicely as the built-in Listbox control when locked to the window edges. It’s more of a resize window and “snap” to fit than a stretch operation. This makes it hard for the end user to determine when the window is the needed size…so they go through multiple resize-and-snap cycles. I also occasionally witnessed the lazy loading process get “stuck” during scrolling to the top…but that issue is infrequent and can be awakened by scrolling elsewhere. It’s still a top-notch solution to an inline editable grid. I’m curious how Xojo’s 2025 R1 solution stacks up against it.
Will this help you?
That is the “free gift” port of some JS library I was referring to that I found in the forum circa 2021-2022 – which is another possible solution for me (and I wouldn’t be too surprised if the Javascript library wasn’t where GraffitiAlert started from.) – The availability of this Javascript library is precisely why I’m a little mistified that the Xojo dev team hasn’t seen fit to build this functionality natively into the IDE. After all… Web 1.0 had this kind of functionality. I know you have to address priorities…but this seems like low hanging fruit? I guess not enough people need this kind of thing?
@Robert_Bednar - it may be as simple as no one’s made a feature request yet.
I’d highly recommend doing so at:
Anthony
You’d be wrong. Be surprised.
I can’t reproduce that. If you have a current license, please open a ticket with an example so I can see what’s going on. If you’re still using a 2019 version for Web 1.0 then things may well have changed.
Yes… I have to keep in mind that I’ve been living in the past. Naturally the addition of GraffitiiSuite I’ve been using is one designed for Web 1.0 circa 2019. I looked at the Demo for the current WebGrid and of although my browser is a little sluggish redrawing your example grid with a zillion control cells 
– the window resize routine is otherwise a a smooth window scale. I don’t suppose you want to go back and update the ~ 2019 version? I didn’t think so. No matter… I going to try and drive this into Web 2.0…hopefully I’ll catch on to all this CSS stuff.
Well I am surprised. Many of the 3rd party controls I’ve seen for (Web 1.0) were integrations of existing JQuery controls. I have no issue with that… I don’t mind paying for someone’s work to integrate an existing control library with the Xojo framework. Some of the best things I’ve done were built upon existing libraries (the work of others). You opted to roll your own alert/dialog code. Nice… some of the best things Ive done were built 100% from the ground up. In summary, my personal best work has employed both 100% original and layered upon existing tools at times.I’m not picky if it get’s the job done.
My Alert class is built on an existing library, as are many others, but I’ve modified nearly every third-party library I use to improve how it appears or functions in Xojo Web, or has additional features and bug fixes that may be missing from the original source material.
That being said, I also provide a number of components that are 100% in-house creations (see: ControlGroup, ListGroup, Avatar, AvatarGroup, and more).
Re: JS Panel for Xojo Web
It looks like the Xojo project file should “run” as a stand alone demo? I’ve tried running it under 2025R1 and 2024R2 without success. Is there something I’m missing? It’s strange…I’m not getting an error message…they code looks like it’s going to launch…and then just stops without explanation.
Nevermind…The default port for debug was set for like 9090 which I wasn’t running a listener on. I should have spotted that.
This looks really very nice. I think it would work well for me on Palettes with fixed dimensions. It doesn’t handle resizable windows as well as it could (sorry…I don’t currently have the skillset to change that) – You CAN resize the windows… but the way it handles control placement is too weird for end users if the control is locked to the right or bottom. The controls do not “snap” into place until the “frame” is resized… which can leave controls dangling outside the palette until the resize completes. (see image)
If the palette is a fixed size…then setting the minimum height and width prevents the frame from being sized below the embedded control area. Unless I’m missing something, I’m guessing you mostly use non-resizable JS Panels.
From your screen it looks like something is broken in the settings. If you open the demo and click on palette, resizing the internal controls works correctly. If you have changed the anchors there is probably some case that is not working.
If you meant something else then I didn’t understand from your message.
@Attilio_Punzi what I did was:
- download your code
- Run
- select Palette from Examples
- resize the panel
Here is the GIF:
If the problem is that it does not resize “in real time” , it is not a real problem for me but an implementation choice (keep in mind that I developed it for my own projects). In xojo not everything you see works the same way as in a normal web framework. Every action has to be communicated to the server, which has to render back what appears on the browser. For now I just take the “end resize” event and resize the xojo web components. To do this in real time I would have to keep sending the new dialog size to the server generating lots of “useless” calls that would risk creating traffic and slowdowns on the interface unnecessarily.
It’s been a while so I hope I haven’t reported too many inaccuracies.
My guess: that is the problem Robert is reporting.
Thank you for the information.
Edit: maybe is good enough if the overflow is changed to ‘hidden’ from ‘inherit’ (this will make the controls not show outside the panel), but haven’t tested.
I suppose so, let’s see what it says! Thank you for your contribution
yes…the image I provided was captured during the resize down…which yes…makes it look like the controls have been left behind…until you release and the controls snap into place. If I didn’t need the ability to resize the palette, your library port would work. I understand we definitely don’t want “round trip” operations on a resize event. I’m not sure how Web 1.0 achieved client side live resize. I’m trying to drive my project into Xojo Web 2.0 – there are many things in 2.0 I would love to take advantage of. Unfortunately there’s a few things missing (like live resizable dialog palettes) that’s holding me back. I’ll be testing the current state of Graffiti Suite web alerts next. I did enter a case for the Xojo Dev teams consideration. I do want to let you know I appreciate your sharing this possible solution. It’s a super nice tool with some great features, minimize, maximize, parent and child palettes, to name just a few.