I’m fairly new to Xojo, and am in the process of creating a database-driven Web app. I have a Weblistbox populated from records from a table in the database. As things stand, if a user wants to edit one of the rows in the Weblistbox, it’s necessary to double-click the row in question (or select the row and click an “edit” button), which brings up a Webdialog allowing the user to make changes. When the user clicks OK in the Webdialog, the changes are committed to the database and the Weblistbox is repopulated. Works fine, but it seems a bit clunky. It’d be much nicer if a user could edit data in-place in the Weblistbox. Ideally, a single click of the mouse would select a row in the list, and a second click would enter editing mode in the cell that’s clicked.
This doesn’t seem to be possible with a standard Weblistbox. From what I can see, I can either buy something like the GraffitiSuite Web Edition and use the GraffitiWebGrid control from there, or I can “roll my own” control. It’s early days for me on the Xojo learning curve, but it looks as if it should be possible to do something like this using WebContainers - the approach used in the example included with Xojo at “Web | Containers | WebGridContainer” seems to me as if it could probably be adapted to do what I want.
Ideally, it’s be nice neither to have to fork out for a third-party solution, nor have to reinvent the wheel myself. I had a good ol’ search through the forum and the Web generally this morning to see if there were any freely-available classes to do this kind of thing, but pretty much drew a blank. Is anyone aware of something out there that would fit the bill?
I’d fork out the 150 bucks and be a happy GrafittiSuite user if I was in your shoes.
If you have any intention to commercialize your app, the GraffitiSuite control is nothing as compared to what you will earn. Time is money.
The GraffitiSuite Grid seems to suffer from the same thing that containerControl-based lists do - that is, that each element in the list (and perhaps each control in each list element) has to send a ‘shown’ event back to the server - even if we leave the event out of the controls. It’s between slow and very very slow.
Between that and the very limited function of the existing weblistbox we’re in a bit of a hard place… or entirely roll our own from HTML/JS/CSS and give up on the controls and Xojo code that make WE great.
I’m strongly hoping that Xojo is creating a version of the weblistbox OR (even better) a container control that coalesces it’s shown events into fewer, or even one, event.
Otherwise lists with > 50 items are way to slow. And yes, there are workarounds but in the world outside of Xojo WE, we can send lists with hundreds of items very quickly…
It’s always bugged me that Xojo designed a read only grid. It’s probably the biggest failing of web edition.
If they just wrapped one of the open source ones for us it would be a BIG help.
Thanks guys. I do take the point that $150 for the GraffitiSuite ain’t a lot of money in the grand scheme. But it’s nice to have options!
Steve - was interested to read your comment on performance issues with ContainerControl-based lists. I can see that this might be the case if the number of columns/rows were large. I wonder how the GraffitiSuite control works under the hood.
Russ - had a look into your comment about open source grids and found http://js-grid.com/demos/. The demo at the bottom of that page is pretty much exactly what I’m looking for. Maybe I need to look at the Xojo WebSDK…
I do, but it won’t be before the end of the year, maybe early next year. Other projects have taken precedence. Sorry.
Not at all Michel - look forward to checking it out when the time comes.
You should impressed. The intent is actually to clone the Desktop control for the web. The prototype I worked on back in January (already !) had almost everything working. Since I did not subclass the Xojo control I had a quite a bit of work, but the result is nice so far. I cannot release it yet in its present state because of rough edges.
I am going to use the same technology in Check Printer for iOS, as Xojo does not have any listbox for that platform yet.
[quote=289108:@Michel Bujardet]You should impressed. The intent is actually to clone the Desktop control for the web. The prototype I worked on back in January (already !) had almost everything working. Since I did not subclass the Xojo control I had a quite a bit of work, but the result is nice so far. I cannot release it yet in its present state because of rough edges.
I am going to use the same technology in Check Printer for iOS, as Xojo does not have any listbox for that platform yet.[/quote]
How’s this project going, Michel?
@Michel Bujardet - Just ran across this thread. Just what I am currently looking for. Do you have an update? Thanks
GraffitiWebGrid does not communicate for each record. Make use of LockUpdate to load all at once, as opposed to sending multiple packets.
Sorry, folks, the iOS project I was on two years ago never got completed, so I have given up on the control. It would take too much work to make it ready for prime time, now.
GraffitiWebGrid looks like a good alternative, and I see Anthony already chimed in
As a customer of Anthony’s for a couple of years (web controls), I am happy with the grid control (and almost everything else included in the suite) and his response when I’ve run into a roadblock.
@Robert Litchfield - agree
I am new to Graffiti Web WE improvement solutions and am just scratching the surface with GraffitiWebGrid. At first it was not easy. I received responses in a timely manner and they always pointed me in the right direction all be it my learning curve is still occurring.
I have been able to completely remove added dialogs or fields to receive row-cell data for editing. Instead users directly edit data in a cell. This has enabled significant layout changes and improved user experience. If you are working on a WE project and use a WebListBox then this is a really good solution