>> - 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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
