Opening container control embedded

Targets Web
1

Can someone advise me where loading the conteiner slows down. The last opening takes about 7 sec. loading a grid with 1000 rows takes about 2 sec. can anyone help I am attaching a video. Is there a tool to find out where the problem is?
thanks
video

2

you could try profile code from project menu

3

What version of Xojo are you using?

4

Xojo 2021 r1.1

5

As Markus suggested, you could use the profiler, but you should think about what’s being done on the back end to set up that page that’s so slow.

For instance, are there lots of database queries? Are the tables all indexed properly?

6

I’ve lots of embedded containers executing DB queries themselves, and load is almost immediate even for much more than 1000 rows in a remote server.

Use Profiler as suggested, can really help to understand what is happening there.

7

I have a similar problem. “Pages” are emebedded run time as containers. These containers have tab-panels, and the panels have some controls, both grafittisuite and xojo.

But going to a page (starting a container and embedd it, after this it just turns on and off). But first time container on (i.e. embedding) it takes so long… Is there any penalty for doing it like this ? The db read it very little and super fast… it is just the embedding that takes so much time… why ?

8

Hm I did a profiler on mine… and from my extremely little knowledge of profiling, I have high called and milliseconds… for some grafittisuite stuff…
I hade 5020ms for a method for populating som popupmenues… In the Add Items/updateOptions/RowsToString is 4702ms… maybe some slowness in the grafittisuite or my use of it…

I’ll pass a message to Anthony…

9

Frantisek, it looks from the video, that you are using grafittisuite stuff ? Am I right ?

Frantisek, add the lockupdate = true to the items you are using, when populating a popupmenu…

and the lockupdate = false after

mine looks like this:
pm_lokasjon_gs.LockUpdate = True

10

The LockUpdate property prevents certain GraffitiSuite components from sending massive amounts of data in small packages, which can cause extended load times. Set LockUpdate = True before any loading loops, and False after to send to the data.

Here’s an example I just built:

GraffitiPopupMenu1.LockUpdate = True
for x as Integer = 1 to 10000
  GraffitiPopupMenu1.AddItem( new GraffitiPopupMenuItem( "Item " + x.ToString ) )
next
GraffitiPopupMenu1.LockUpdate = False
11

@Anthony_G_Cyphers is there a consolidated list of controls that have this property ?

12

Not currently, but a quick search in the documentation can help out here:

  • Grid
  • PopupMenu
  • Tree

Basically the data-heavy components.

13

Also tabpanel

1 Like
14

The Web 1.0 TabPanel had it. The Web 2.0 version does not.

15

Hi
So I tried to use a profile but it doesn’t create any Profile.txt file for me so I don’t know where to look for information. Yes, I use Graffiti components and I made a change to what Anthony wrote, but the result is still bad.
Thanks

16

I managed to reduce the loading time to half by about 3 sec in the invisible area of the container, the rectangle object was better after removal, but the loading would still be better for recovery.

17

The WebRectangle and a few other built-in controls still cause slowdowns in my projects. That’s why I created GraffitiRectangle.

18

Is the GraffitiRectangle part of your latest release?

19

Sure is.
https://demo2.graffitisuite.com/#rectangle

20

Ahh OK I have R37, I guess it’s time to update :wink:

1 Like