(long) Transparent IDE elements and other problems

[Wilhelm Sanke]

On Thu, 25 Mar 2004, j <j at clsdesignassociates.com> wrote:

> >> - open a test stack with 1600 or more controls on a card
>
> can list members provide me some descriptions of the kinds of
> stacks/apps which would have more than 1600 controls on a card?  i do
> not mean this as a joke, and i am not trying to be a jerk.  i am
> sincerely interested in hearing from all of you.  i just can't even
> begin to fathom what the purpose of such an app might be.  ideas?
>
> thanks,
> j.


Astonishment or amazement as the "momentary overwhelming of the mind by 
that which is beyond expectation" sometimes leads to questions of the 
type "Why on earth should anybody......". Given the variety of 
applications that can be created with Revolution - from databases, net 
applications, e-learning environments to instructional programs, games, 
meditation platforms, scientific analysis tools, imagedata processing 
etc. etc. - it is safe to assume that there are good reasons for most of 
such applications.

Our multiple-fields stacks gradually evolved from playing around with 
color values, modifying and relating colors to each other, developing 
structures, creating color patterns with about 100 different algorithms 
- thereby using pixels, fields, graphics, or the colorbackground of 
chars as elements of design.

When I opened one of these stacks that were developed in the Metacard 
IDE in Revolution I suddenly encountered all sorts of problems; it was 
my turn to be "astonished" as I did not expect that the same engine with 
the same basic set of commands, functions etc. - which are also used to 
build the IDE and the additional "rev" commands (maybe with the 
exception of special externals) - could lead to such differences in 
performance.

As I am interested in the further development of Revolution - and 
because I am convinced that despite the addition of quite a number of 
features to the Rev IDE the performance need not suffer - I created a 
series of test stacks to narrow down the encountered problems. These 
test stacks are very much simplified versions of the color stacks 
containing only a varying number of fields (containing backcolor, but 
without text or scripts) and three to four buttons to test button 
performance.

Two of the test stacks are now in the hands of Rev developers and have 
already been already used. There probably are or could be other and 
better types of test stacks that address different problems. Anyway, 
testing under pressure, under extreme conditions, can help to detect 
underlying issues, diagnose flaws, show the limitations of a product, 
and can lead to improvement. Testing is or should be standard procedure 
in product development.-

Please, take a look at one of the results I reported in my first post of 
this thread, the different ways the script editor comes up.
There are several possibilities to open the script editor - from inside 
a script, from the message box, right-clicking on an object and choosing 
from the appearing menu, from the script icon in the menubar, from 
menuitem "object script" of button "Object" of the menubar, from the 
Application Browser, and from the Object Inspector. I think that is all?
All possibilities have the same purpose, namely to open the script 
editor, but they act differently - and these differences are not obvious 
with smaller stacks, but may nevertheless influence the overall 
performance - barely noticeable slowing down, crashes, sudden freezing etc.

With the help of the test stacks different forms of how the script 
editor behaves when opened could be identified:

- the script editor comes up at once (as it normally should) showing 
card, borders, controls, and text without exceptions

- the script editor comes up at once, but at first only shows its 
decorations and borders, the rest remains "transparent"; after some 
seconds the text finally appears

- the script editor does NOT come up at once, you have to wait a couple 
of seconds - relative to the number of controls of the stack - before 
the editor finally appears, but this time without transparency as 
described above.

I leave out here the separate differences of how the script editor closes.

Example one occurs when you open the script editor from the Message Box 
or the Application Browser - once the AB has finally appeared.
Example two is produced when you right-click on a control, example three 
when you click on the script icon of the Menubar. The findings for 
"button delay" apply here, i.e. clicking a second time in immediate 
sequence on the icon does not lead to a delay the second time etc.-

A tentative analysis to find the underlying causes and to resolve the 
problems - which is primarily the task of  Rev developers - might arrive 
at a conclusion like this:

- either there are differents scripts to open the script editor that 
lead to diverging behaviors; in this case the diverging scripts should 
be trashed and substituted by the script of example one

 - or all behaviors indeed have the same underlying script, but are 
influenced by interfering processes, most probably launched by the 
front- and backscripts of the Rev IDE - as indeed can be tested by 
"Suppress Messages". When this menu item is checked no differences in 
opening the script editor remain.

So why should the scripts not be improved according to these findings?

It should not be too difficult to resolve the other problems that became 
evident through the testing. But it needs an awareness that there are 
problems that need to be resolved. I think such an awareness has now 
been reached on the side of the Rev team.

Regards,

Wilhelm Sanke