Thanks for the appreciations, they are always nice!
To do what you need you need to add (under resizeit[‘stop’]) in the JSCLASS constant:
resizeit['resize'] = (panel, paneldata, event) => {
var jsonObj = new XojoWeb.JSONItem();
jsonObj.set('top', panel.style.top);
jsonObj.set('left', panel.style.left);
jsonObj.set('width', panel.style.width < js.minResizeWidth ? js.minResizeWidth : panel.style.width);
jsonObj.set('height', panel.style.height < js.minResizeHeight? js.minResizeHeight : panel.style.height);
XojoWeb.session.comm.triggerServerEvent(el.id, 'resize', jsonObj);
};
Keep in mind that it will speed up a bit but still not be as smooth (there are ms of delay between communication)
1 Like
I tried this additional resizeit routine and it seems to work as expected for any controls that are at least anchored to the top and left. If a control is anchored on the top right…the control tends to outrun the right border of the palette frame. I have a fighting chance of figuring out why this is so. My initial expectation is that the the control repositioning is either ahead of or behind the frame repositioning. Perhaps due to the inherent update lag introduced?
There are a few adjustments to be made :
- Add a control that throws the resize event every X px of step. Don’t leave the resize event so free, otherwise if you make a resize of 200 px in one direction and 200 px in the other you get 400 data exchange events between client and server. Do something like:
resizeit['resize'] = (panel, paneldata, event) => {
if(Math.abs(el.style.width -panel.style.width)>20){
var jsonObj = new XojoWeb.JSONItem();
jsonObj.set('top', panel.style.top);
jsonObj.set('left', panel.style.left);
jsonObj.set('width', panel.style.width < js.minResizeWidth ? js.minResizeWidth : panel.style.width);
jsonObj.set('height', panel.style.height < js.minResizeHeight? js.minResizeHeight : panel.style.height);
XojoWeb.session.comm.triggerServerEvent(el.id, 'resize', jsonObj);
}
};
- Comment out all the code inside the AttyWebContainer’s “FireResize” function. I needed this for nested controls that in older versions of xojo had problems (maybe still today but I don’t think so). So you should leave the handling of anchors to xojo.
(I have not tested any of this. Unfortunately it’s been a really long time so I hope I haven’t added inaccuracies)
I’ll try this. Thank you.
I’ve made a first effort at implementing your custom Alert Class. The busy looking toolbar is just an experiment with replacing the “footer toolbar” I use in my Web 1.0 based version. The result looks pretty good for a first effort. But I do have some issues I need to overcome.
I don’t (readily) see an option to set minimum height and width constraints on the alerts. I would guess I could do something about this somewhere in resize event but if I have different palettes of different minimum sizes…this could get a little tricky.
Your examples with a container use an implicit instance of a container from the page.
and attach it to an implicit instance of GraffitiAlert also on the page.
I use many different types of “containers” – and often multiples of each type.
In Web 1.0 I instantiate an instance of my WebContainer in code and attach it to an instantiated instance of the WebDialog. This is much preferable to an implicit instance (probably necessary). When I tried to use a New Instance of my container… the GS Alert “Show” method complained that it was unable to determine the parent of that container. I can try to get around this limitation, but didn’t really want to go poking in your library and Javascript too much.
Hi Robert,
Please open support tickets for feature requests and issues. I track my time and ensure that I respond to all requests using that system. I, otherwise, might not see or forget about these things if they arrive via other venues.
– Anthony
Certainly. I’ve open a support ticket for your review and will followup with you there. Thanks.
I opened a case with GraffitiSuite that identified the issues I was having with the GraffitiAlert class. Anthony addressed my issues. Instantiating a container in code and attaching it to a GraffitiAlert was a matter of using EmbedWithin to resolve attaching an arbitrary number of alert palettes to my page. Anthony also has a class enhancement that supports setting minimum height and width (and maximum too). So I can now solve my Web 2.0 Palette type Dialog Issue with GraphitiSuite Alerts. Woot! Thanks Anthony… This is really helping me get un-stuck from the past. Anthony was super responsive. Can’t say enough good about GraffitiSuite. (I was already using their old 2019 version for their excellent GraffitiGrid) So many good UI tools in there.
6 Likes
In addition to GraffitiSuite I made the adjustments you recommended. The results are excellent. What a nice way of implementing palettes for Xojo with Javascript. I’m impressed with this work and the fact this class was offered up with helpful advice freely is just super. I was curious if anyone could provide a solution for the missing Palette type web dialogs in Web 1.0 and I received not just one but TWO viable solutions. Here they are living side-by-side in my program. Each has unique benefits Thank you so much to the Xojo developer community. I’ve received so much great help over the years. We are so blessed to have a community of fellow developers willing to share their knowledge and provide great tools to fill in the gaps in Xojo.
4 Likes
would you like to share in return a snippet project with a base example on how you achieve this ? thanks.
2 Likes
I’m happy to contribute however I can. Although this specific issue (a replacement for a Web 1.0 Palette Dialog) seems to be resolved…there is always the next hurdle. #1) While the the JSPanel based Palette does a pretty good job of Resize… it is making a round trip to the server which is slow. I am trying to reduce the number of resize callouts…but will probably sacrifice the “smoothness” of the user interaction. Somehow the built in Xojo solution in 2019 remains in this way superior to my best effort in 2025. Not that the Xojo solution in 2019 was perfect either. You could only bring a dialog to the front by clicking on the header (I may have been able to fix this… I didn’t try) 2) The JSPanel Code does a great job of MOVING the window. It makes the window slightly transparent which is really nice for placement, and the Minimize design is super. I also personally like the drop shadow on the window, but I’m sure that’s a stylistic element and could be removed. The GraffitiAlert based solution resizes very nicely without any lag… except for a WebListBox in the container. The rows and columns all expand and contract perfectly when anchored to the container…everything…except the standard ListBox Header** with the new Sort Options etc. The headers do not expand and contract in sync with the rest of the listbox. A little ugly during the resize…but they eventually snap into place. Tolerable. I expected to use a double-click on a row to open another “row editor” dialog. Double click doesn’t work for me in the JSPanel (probably not supported…could be added). Under GraffitiSuite…it works fine and opens the SHEET type Standard Xojo Modal dialog box I need…but it doesn’t automatically allow that window to move into the foreground. perhaps I can specifically instruct the GraffitiAlert to move adown a layer. The window by default obscures part of the modal dialog…and I don’t think I can move it…until I dismiss the Modal dialog. I hope I can overcome the slow refresh times on the JSPanel (as suggested by the author) and I hope I can resolve the layering issue with other windows with GraffitiSuite. I’m keeping my options open as I explore both alternatives. I had planned to use the new 2025 feature for direct editing on the WebListbox (No Edit Window Needed!) Like others I discovered that I could edit any empty rows… but the ones I populated with data from a result-set could not be edited…without me doing something. It’s still a considerable work in progress. I’m celebrating some victories… even considering not allowing resize of palettes until I get that sorted out. Sure would be nice if the folks at Xojo provided a Web native solution in 2025 on-par with functionality from 2019. Please…pretty please?
I have more changes in the pipeline for z-index handling, but there’s currently two modes controlled by the GraffitiAlert.ForceZIndex property. True calculates the current highest z-index on show and places the GraffitiAlertMessage above all others. False uses the Bootstrap-defined z-index for modals.
In the next release there’s going to be a ZIndex as Integer = -1 property on GraffitiAlertMessage that lets you specify any arbitrary position when ForceZIndex = False. There’s not really a great way of managing the z-index stack on the page as none of this is really meant to be done in web pages. The web just hasn’t been designed to mimic a desktop experience, so it takes a lot of work to accomplish that.
1 Like
Thanks Anthony, you are right about that a Z-index isn’t something you would normally need to control on a web page. I had considered breaking my single Xojo app down into a dozen mini-apps (one for each palette) – I may still investigate that. One problem is that there is some communication between palettes. A positive side effect would be that if one of the mini-apps goes out to lunch for whatever reason…it doesn’t kill the entire application. A Negative would be that 8 open palettes (as in my original screen shot) means 8 open session instances for a single user. Fortunately, the number of users per install is small. It might be nice to manage the each palette separately so that a recompile doesn’t include all the components. I could selectively update just one Palette. Then each palette would be a simple “page” and the user would control them as they would numerous web pages.
In your case, I would probably use a data-focused design that segments a single page in to relevant areas using containers in a flex layout rather than palettes/dialogs. Palettes are not friendly for all display sizes in addition to the other issues you’re working very hard to get around.
I’ve considered that as well… something along the lines of Filezilla which uses multiple defined areas of related elements. Of course switching to an actual Desktop application is also a possibility…or some fat client type combination that runs some web UI elements inside the Desktop UI. (I had other forum discussions with users who have tried a hybrid approach). A 100% desktop app comes with all the fun of managing releases and keeping users updated. Versus the zero install footprint of a web app along with the ability to roll out an update and have all users see it immediately. --Oh and of course the cross-platform capability of a Web Page – although yes..palettes don’t translate to mobile well.
Well, if you want to try a split view approach, you can always try GraffitiSplitView, but that’s not what I’m referring to. I’m talking more about a masonry approach using flexbox with embedded containers.
If you do move to desktop, you could build a REST API web app for the central communication, and there’s good update packages (like Kaju) that can make managing user updates easy.
Thank you so much for the compliments!
When I switched to 2.0 still in 2020 (with the first version) I practically rewrote all the graphical components of xojo leveraging JS libraries (Tables,Charts,Kanban,Calendars, Dialog,Sidebar, toolbar, input text, date picker, file uploader, tree view etc). This was not because I had to make money from them, but because I needed them!
When I later basically abandoned Xojo for work reasons , I gave away the “dialog component” because I saw that there was so much demand for it.
If you want to make resizing even faster just go from JS and change the size of all the xojo components without calling the server then with the resizeit[‘stop’] event go and update the component references on the server. There is a bit of js work but not that much either 
2 Likes
