For my own guesses I quote myself from the March 25 post:
"The speed problems increase with the growing number of controls. There is a direct relationship; the assumption that the Rev IDE is monitoring all controls on a card at the same time, apparently somehow constantly looping over all controls could not be far off the mark."
and
"One problem - that seems to me to be evident through my tests with larger stacks - are the many interfering processes of the Revolution IDE that are probably meant to be "helpful" (like Dan Shafer has remarked), but get in the way of a solid efficiency of the IDE. Monte Goulding has shown that substantial improvement is possible.
As a starting point for further improvement the "rev scripts" put into front- and backscripts should be carefully analyzed as to how much of these algorithms are really necessary and whether - if they are indeed not expendable - they could be streamlined."
Following my assumptions I tried to narrow down the sources of the problems and came across some tentative solutions.
The issues I had reported were:
- "White-washing" Revolution - button delays - transparency of IDE elements - special problems of Object Inspector and Application Browser"
To remind you I give abbreviated descriptions of these issues here (for full details compare my post of March 25)
1. "White-washing" Revolution
- start Revolution - open a test stack with 1600 or more controls on a card - open the Windows Task Manager - click on the test stack to set the focus (this is important)
Now move the Windows Task Manager over the test stack or IDE elements like tools stack and Menubar. It will now serve as an eraser tool, erase all controls on its path and leave a white background on stack and IDE elements behind, i.e. NOT on the other parts of the screen.
You can also use other non-Revolution windows on your screen to achieve these effects.
2. Button Delays
- start Revolution
- open test stack 5400
- choose browse tool clicking at the tools stack
This will cause the first "button delay" because it will take 10 seconds until the "hand" button is down.
- click on any button of the test stack (note: this is the first click on a control after the stack has been opened)
What happens?
* Nothing happens for 10 seconds then
* the button appears in its pressed-down state.
* After another 10 seconds the dotted rectangle appears inside the button area that indicates that the button has received the focus.
* And again, after another 10 seconds the button finally comes up again and now the script begins executing.
Together, this is a 30-seconds delay. For the 3300 stack the whole delay is about 9 seconds.
When you now (after having clicked once on a button after the stack was opened) click on any *other* (important, see below) button, you get a delay of 20 seconds; the first phase described above is apparently skipped and the button appears immediately in its pressed-down state.
When you click on the same button again - any "same" button whitout clicking on a different button in between - no delays happen (the IDE apparently remembers which button was clicked last).
The same holds more or less for IDE buttons, the delays here are about 10 seconds.
3. Transparency of IDE elements and stacks
- start Revolution - open the 5400-fields test stack - remain in "select" mode (pointer button pressed) - right-click on a button - choose "Edit Script" from the pulldown menu
The script editor immediately comes up as "transparent", i.e. only the decorations and borders of the script windows are visible. Tools stack and Message Box (if open) disappear; why is that??.
After ten seconds the background and contents of the script editor come up.
When you close the script editor, the tools stack and the message box reappear as transparent, and only after another 10 seconds their surface is restored.
The same "transparency" occurs when you choose - in the above sequence - "Property Inspector" instead of "Edit Script", the only difference being that this time tools stack and Message Box do not disappear!"
First thing I noticed when testing and looking through the IDE scripts that the white-washing, button delay, and transparency occur only with fields, not with corresponding numbers of buttons or graphics, but that the special problems reported by me for the Application Browser and Object Inspector are caused by any type of controls.
Of course, you could use Suppress Messages (works for "pointer mode" for editing scripts and properties) and "Suspend Development Tools" with pressed down Shift-key to see how the stack would really work, but constantly using and changing these options is certainly tedious and not what an IDE is designed for.
Results of quite a couple of hours of inspections, as I felt somehow challenged by these problems:
The source of the first three problems is button "revtable" of stack "revlibrary" as a frontscript, which contains the "table library" for "improved table field interaction with databases" as the header says, but produces problems for any type of application, i.e. also for such without table fields or spreadsheets as it is in inadequately insulated from other types of applications.
The simplest solution is of course to remove the script of button "revtable" from front, but I was interested to find out what exactly could be the cause.
There are two instances of a loop with "number of fields" in the script.
The first - in the "on preopenstack" handler - is inoperative because the "on" line is commented.(???)
The second is contained in the "revDeleteCellFields" handler which is used among others in the "non-rev" handlers
- focusin - focusout - exitfield - closefield - scrollbardrag - mouseup
Closefield, scrollbardrag, and mouseup eliminate non-cell related objects through their if-conditions
The if-condition of exitfield can be substituted by that of closefield, and then does not cause troubles.
This is not possible with focusin and focusout: Although after the substitution of the if-condition the "button delay" no longer occurs when working in browse mode on the stack, if you want to open the script editor you get the described "transparency" effects and a delay.
So it is better to comment the whole focusin and focusout handlers as the substitution of the if-condition of closefield is not sufficient here.
"RevDeleteCellFields" in the focusin and focusout handlers explains why the described "button delays" occur in the stack and the IDE. What causes the "white-washing" and "transparency" in particular I am uncertain. Anyway all these problems disappear with the commenting of focusin and focusout.-
I have not (yet) looked into the speed problem of the Application Browser with larger number of controls (There was an improvement though as can be expected by function "revControlsHtml pControls --generate html with embedded icons for speed" in the stack script) and the shortened display of controls in the Object Inspector, as I have indeed a lot of other things to attend to and think this should be the obligation of members of the Rev team to produce an IDE that works under a number of different conditions - like the Metacard IDE does. Excuse the last five words, but as Revolution and Metacard use the same engine and the same set of basic commands, functions etc. it should be possible to achieve a comparable level of performance - given adequate programming structures.
Regards,
Wilhelm Sanke
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
