WebContainer shown event

Hello. I’m kind of a newbie in Xojo, so I’m sorry if I’m gonna say something wrong.

I’m currently implementing a web Application that fundamentally is going to display some tables with many rows (over 1000). At first I was trying to use the WebListBox to do that, however it revealed to be a bit featureless for what I need. Then I started to use WebContainers to implement my own tables with my own features. So far so good, however in the last days I spent some time trying to figure out why are my tables so slow to load. After some digging I found that the “shown” event is being called for each one of the WebContainers (let’s say that in a 1000x10 table, the shown event is being called 10.000 times). Needless to say that I don’t have have the shown event being handled anywhere in my code.
So my question is, once I’m not using the shown event, why is it being called from the JavaScript framework? Is there a way to prevent it?

Thanks in advance for the help!

The shown event does more than just raising the event in your code. It is used to trigger code in the internal framework.

Is there a way do work around it? In the case I just explained, it takes around 3 minutes just to trigger all the shown events (approximately 20 ms each).

Are you showing all 1000 rows on the same page ? Some measure of paging could drastically reduce display time. Usually, a page seldom displays more than 60 rows or so at a time.

Yes I am showing all 1000 rows in one page, and I’m already using pagination once the original table has some tens of thousands of rows. Make the table shorter (60 rows) is not really a option for me at this stage of the project. But hypothetically, even if I reduce the page, lets say to 100 rows, I guess I’ll still have a intolerable delay just to raise the shown event. Just to make this situation clear, the 1000 are displayed reasonably fast, but then the page is blocked until the shown events are all triggered.

I’m resurrecting an old thread because this sounds like exactly what i’m hitting now. I am only creating 50 lines or thereabouts but the calling of the shown event for each embedded container is taking many seconds before the page can then respond to any other input.

I have not implemented the shown event in any of the container controls. And when I just create a test app with a simple container control and a button in it and embed 4 or 5 of them into the page they don’t call the shown event.

What is it specifically that the framework needs the shown event for so I can avoid it?

What happens is that my page loads, but won’t respond to any input for however many seconds it takes for the shown events to finish processing. There are no shown events implemented anywhere on the page or on the embedded container controls, but in the timeline of the browser I see one being sent for each container control and it takes forever. I was thinking that the eventImplemented might not realize that I had removed an event that was there previously, but that doesn’t seem to matter. When I add that event to the demo app I created it doesn’t even send the event to the server in a way I can find. So there is something here I don’t understand yet.

I will continue to try to build a demo app that does it, but my containers aren’t that complicated. Literally just 3 labels with some styles applied or each label control. Why are they calling a shown event to the server when there are no shown events implemented?

I did find a bug that I will be reporting shortly where a webPicture control sends a picture changed event even if you haven’t implemented it. So I was able to cut my load time in half by deleting that control and using the function of the labels to show the couple of icons I want to show inline with the main labels text. But thats still not good enough. I need to stop it sending a shown event 75 times which takes quite a bit of time before the user can click on anything.

The shown event is where the data containing the size of each control is sent back to the server so you can later do things like

dim w as integer = me.width

And have those values be somewhat accurate.

that makes sense, but I can’t duplicate it in a simple project. I can embed any number of container controls into a test app and the timeline in the browser shows only a single shown event for the page itself. Not one for each and every container control. Even if I add shown events to the container controls and actually access the width or other properties and put them into labels in the container control I see only a single shown event for the page, not one for each container control.

I moved the actual container control from the other project into a new project and while I did have to comment out some code to make it run in a vacuum I canned some of the moving around of things so that it would still access all the elements as it did before, it doesn’t do it in a fresh project. Obviously I’m not finding the place that causes it to happen. I will continue to fight with it as it’s tripling the time between when my page is first shown and when it is actually ready to accept any input which makes it rather frustrating to use.

One possible work-around:

Keep the data (the records) to be shown in an array separate from the “listbox” container.

Have exactly the amount of containers in the “listbox” needed to fill the height of the listbox container (listbox container height divided by row container height and then round up). Note that when the user resizes the window the count of rows need to be re-calculated and row containers need to be removed or added.

Calculate size and position of the vertical scrollbar based on the array size and vice-versa. I use listbox-container-internal variables called mListIndex and mScrollPosition for that.

Have the row containers collect the data for the currently visible rows from the array (based on the mScrollPosition variable).

That way you can show 10 millions of records with no delay.

Hello everybody,
I have the same issue. The web app is answering “SQLS6”… and then the app crashes.
Any ideas?

[quote=348624:@Romain Jordan]Hello everybody,
I have the same issue. The web app is answering “SQLS6”… and then the app crashes.
Any ideas?[/quote]
Please don’t hijack threads. You’ve asked this in another thread already.

I’ve actually replaced several displays in the non-web version of the interface with similar displays where I manage them and their drawing myself. I was able to make large displays with controls and very complicated drawing in each line show up much faster than trying to draw the individual cells of a listbox.

These lists won’t ever have millions of items in them on the web though :wink: I get very annoying to the users delays with as little as 10 or 20 custom lines.

I have had one more thought about what might be causing it but not in my demo app that I will try out today, but I think the solution for me is going to be creating a webAPI control that will send the individual items and manage their html. This isn’t all that complicated and I only need a few mouse down actions for the various items and to be able to set some text and move a couple of items. I think I can do that in a plugin so that there are no dynamically created container controls on the page at all. Just the one plugin control that is kept sized appropriately and keeps the HTML inside updated in response to received events which already have IDs that won’t overlap with Xojo’s control ID schema. I can use those to target the specific elements and change their displays and if it generates a shown event even if I don’t want it then it will only be ONE shown event not 50 or 60 of them. No guarantees it will be faster though :wink: I’ve often headed off to redo things and then run into new difficulties :wink: Luckily this HTML is simple enough that I shouldn’t run into too many cross browser issues. Doing more complicated things in plugins is such a testing pain in the neck that I happily leave that sort of thing to the xojo engineers :wink:

just FYI, loading the list as a single webapi control is AWESOME. It’s there in half a second and is ready to accept your clicks the instant it shows up. Compare to more than 6 seconds when embedding individual container controls for each line. I know a few seconds isn’t that big a deal, but it’s going to make me a lot happier with the product I use myself and make a lot of users a lot happier too.