switching cards is really slow
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Posts: 36
- Joined: Fri Jan 01, 2010 12:11 am
switching cards is really slow
Has anyone else seen behavior like this? We have an application that has about 15 or 20 cards. Each card has about 300-400 controls on it. Mainly labels and text boxes. There are some groups of graphics (lines, ovals, rectangles) as well. When I first open the stack, I can switch to another page very quickly (way less than 0.5 sec). As I move from card to card, the time it takes to switch to the next card gets longer and longer. I have done this with the message Watcher up and see that there is a focusOut message that seems to take a long time. Then the closeCard message executes and very shortly after that, the card switches. So the slow part seems to be in the focusOut message. If i trace with IDE messages on, I see tons of revRuggedID messages fly by. Can someone describe what might be happening with focusOut? And might anyone know why the first time I switch cards it happens really fast, then gets subsequently slower as I change cards?
Re: switching cards is really slow
Did you try it in a standalone?
It might be some inefficient handler in the IDE that is interfering... If it is, it most likely is a bug.
It might be some inefficient handler in the IDE that is interfering... If it is, it most likely is a bug.
Various teststacks and stuff:
http://bjoernke.com
Chat with other RunRev developers:
chat.freenode.net:6666 #livecode
http://bjoernke.com
Chat with other RunRev developers:
chat.freenode.net:6666 #livecode
-
- Posts: 36
- Joined: Fri Jan 01, 2010 12:11 am
Re: switching cards is really slow
A most excellent suggestion!
I tried converting the stack to a standalone and that fixed it. Now card changes are fast like they should be. You suggested the IDE might be holding up the show--do you have any suggestions that I might research so as to give the Rev team some more information about this intrusive behavior? How about as a start a way to increase the number of messages kept in the message watcher window. Right now when I use it, many messages go scrolling off the top...
I tried converting the stack to a standalone and that fixed it. Now card changes are fast like they should be. You suggested the IDE might be holding up the show--do you have any suggestions that I might research so as to give the Rev team some more information about this intrusive behavior? How about as a start a way to increase the number of messages kept in the message watcher window. Right now when I use it, many messages go scrolling off the top...
Re: switching cards is really slow
Hmm no idea about the message watcher. You could investigate the frontscripts, backscripts and stacks in use, but beyond that... There's not really a single and easy way to do it i think.
Various teststacks and stuff:
http://bjoernke.com
Chat with other RunRev developers:
chat.freenode.net:6666 #livecode
http://bjoernke.com
Chat with other RunRev developers:
chat.freenode.net:6666 #livecode
-
- Posts: 36
- Joined: Fri Jan 01, 2010 12:11 am
Re: switching cards is really slow
Found it!
The problem is with the button "revDatabase" front script. It has a handler for the closeCard and preOpenCard that looks like this:
The problem (at least for me) is that "the number of backgrounds" returns a count of every group in the whole stack! Wow, that turns out to be > 600 groups for this one particular application. In the IDE, this can cause card switches to take 15 seconds or so. Every time I do a card switch, that loop runs once in the closeCard and a similar one runs in the preOpenCard. If I change the name of the handler to closeCardX and preOpenCardX, then the card switching goes back to being fast. (~ 0.5 sec).
The code inside the loop seems to care about what happens when a card closes, and I suspect it was meant to only apply to the groups on the card. Can anybody confirm that? And if so, should the loop do something like:
And just because it seems a little odd, since background and group are synonyms in the dictionary (but the User's Guide does a better job of explaining the situation)
put the number of backgrounds -- the number of groups in the stack
put the number of groups -- does not work in the message box
put the number of groups of card "XYX" -- returns a value (i did not count them to see if it was accurate)
put the number of backgrounds of card "XYZ" -- gives 0 in the message box
The issue I have is that the documentation (4.5.0) says
The behavior I see is that all groups are a background even if their "Behave as Background" option is not set.
Can anyone comment if it is Ok for me to remove the button "revDatabase" front script if I am not using the database functionality?
The problem is with the button "revDatabase" front script. It has a handler for the closeCard and preOpenCard that looks like this:
Code: Select all
on closeCard
repeat with i = 1 to the number of backgrounds
local tObject
put the long id of background i into tObject
if there is not a tObject then next repeat
if the cRevGeneral["databasequeryobject"] of tObject is true and the cREVDatabaseQuery["closewhen"] of tObject is "card closes" then
...snip...
end if
end repeat
pass closeCard
end closeCard
The code inside the loop seems to care about what happens when a card closes, and I suspect it was meant to only apply to the groups on the card. Can anybody confirm that? And if so, should the loop do something like:
Code: Select all
repeat with i = 1 to the number of groups of this card
....
end repeat
put the number of backgrounds -- the number of groups in the stack
put the number of groups -- does not work in the message box
put the number of groups of card "XYX" -- returns a value (i did not count them to see if it was accurate)
put the number of backgrounds of card "XYZ" -- gives 0 in the message box
The issue I have is that the documentation (4.5.0) says
the term background refers to all the groups in a stack that are available for use as backgrounds (see below).
The behavior I see is that all groups are a background even if their "Behave as Background" option is not set.
Can anyone comment if it is Ok for me to remove the button "revDatabase" front script if I am not using the database functionality?
-
- Posts: 36
- Joined: Fri Jan 01, 2010 12:11 am
Re: switching cards is really slow
I forgot to ask..How can I prevent the button "revDatabase" front script from loading in my stack when I am working in the IDE?
-
- Posts: 36
- Joined: Fri Jan 01, 2010 12:11 am
Re: switching cards is really slow
Never mind that last question about preventing the front script from loading. I took care of it with the following code.
Code: Select all
on mouseUp
repeat for each line fso in frontScripts()
if the name of fso contains "revDatabase" then
remove the script of fso from front
end if
end repeat
end mouseUp
Re: switching cards is really slow
Hi Winston,
the difference in groups and backgrounds lies in the point of view
GROUPS are "locally" to the current CARD
-> put the num of groups -> the number of groups on the current card
BACKGROUNDS are "gloabally" to the STACK
-> put the num of backgrounds -> the number of ALL groups (of every card) in the current stack
Best
Klaus
the difference in groups and backgrounds lies in the point of view

GROUPS are "locally" to the current CARD
-> put the num of groups -> the number of groups on the current card
BACKGROUNDS are "gloabally" to the STACK
-> put the num of backgrounds -> the number of ALL groups (of every card) in the current stack
This is correct! It means that you can PLACE groups that do NOT have their "backgroundbehavior" set to true onto cards.the term background refers to all the groups in a stack that are available for use as backgrounds (see below).
Best
Klaus
Re: switching cards is really slow
Hi all,
I'd like to post a quick note of admiration and thanks to the people involved in this thread thus far. I've found it particularly instructive, not only about the specific problem (the subtle sort that can deprive one of sleep) but also by demonstrating some very useful trouble-shooting techniques. The Forum really is a great learning resource.
Regards,
Michael
I'd like to post a quick note of admiration and thanks to the people involved in this thread thus far. I've found it particularly instructive, not only about the specific problem (the subtle sort that can deprive one of sleep) but also by demonstrating some very useful trouble-shooting techniques. The Forum really is a great learning resource.
Regards,
Michael