Some speed and other problems solved

[Wilhelm Sanke]

In my post of March 25  "(long) Transparent IDE elements and other 
problems"  I had reported in detail on some problems that occur with 
stacks that contain more than 1500 fields on a card. There was one reply 
to this post on the improvement list by Richard Gaskin who recommended 
that one should read my post more than one time - so I have to take it 
that these - for me - severe problems seem to be of limited interest for 
the rest of the community. Especially no one from the Rev team reacted 
and ventured opinions what could have caused these weird IDE behaviors 
and how the problems could probably be addressed.

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