Dave,
My goal is/was to be able to create application more quickly, which is
why I use started using RevRev in the first place!
[snip]
The type of market I work in now means that I have to write many GUI
intensive applications and try to sell them to the Customer. They are
really just GUI shells to start with and if I do a good enough job and
the Gods are with me, I get the contract and then I get paid to do
some "real" work.
[snip]
I have used a variety of methods in order to develop apps in RunRev.
I've used most of the the methods described by others on the list, For
example:
Having a common routine in the stack or card script and hard coding
object names or using Custom Properties to visually update controls.
Looping thru all the controls in a card/stack and updating them that
way.
A mixture of the two methods above, etc., etc., etc.,
Over time I got better and better at doing it, but all the above
methods meant that I had to do tweaking (sometimes non-trivial
tweaking) in order to build a new app from parts of other apps and add
the new pieces necessary to make the new app.
[snip]
I am now at a point where there is very little or no separation of
code and data, by this I mean copying and pasting a visual object into
a new app copies both the Visual Object and all the code necessary to
make it work.
As it stands now I can take an object from my Object Library or from
an existing ISM based App and place it in a new App and the most I
have to do to make it work is change a few custom properties in the
Property Inspector and hey presto it just works.
No tweaking of scripts, no renaming of objects, no nothing! It just
works!
[snip]
When I start a new app, I take whatever pieces I need from the Object
Library or existing apps, throw them into a new app and the stuff that
did work still works (with no or minimal changes to Custom
Properties), leaving just the task that I really want to do which is
design and code the new piece.
OK, I'm beginning to conceptualize your library. But C was almost as
incomprehensible to me as HyperTalk was to you; so sending messages in
C is pretty much foreign, or long-ago visited, territory. The part
about building a GUI with objects from a library seems straightforward.
But I still have no feeling for what is involved in "visually
updating" controls either via custom properties or looping. Is this
necessary every time a stack that includes an iteration of the control
opens?
From my limited perspective, I think of "visually updating" of a
control as involving manipulation of properties like colors/patterns,
image/icon, or text formatting. These don't seem to me to be prime
candidates for runtime updating, and if they were, I would assume a
consistent look & feel is desired throughout the GUI...if so, colors &
text can be changed en masse by setting them to empty for all objects
subordinate to the stack and making all changes at the stack level.
Images can be changed by switching image libraries or changing image
files for referenced images.
My impression is you a building a library of "standardized objects"
to be referenced by multiple stacks. All iterations of standardized
objects in that stack are to be initialized per a library stack
handler when it opens and set to some other state when the stack
closes. Is that essentially the goal of the example?
Yes, that's it. In order to do the above, a "Listen" routine needs to
be called for each object that wants to receive a message. The listen
function can be called at anytime, but to make it easier to use, I am
scanning for the ISM_InitializeObject handler and if it's present,
call it. The ISM_InitializeObject in the target object can then call
the Listen function to register itself (or any other object for that
matter). The same goes in reverse, I want to stop listening when a
stack closes.
In out-of-the-box Transcript, every object with a script is born
listening. The trick is to place a handler in the spot in the message
hierarchy where it hears requests from all objects that need its
services.
So one can make handlers and images available to any stack by placing
the handlers in the library stack script and/or placing the images on
the first (or any?) library card. One can change icons en mass by
switching between to image libraries containing images with identical
ids. One can change images by referencing image files instead of
importing them and then changing the files in the image folder. One
can change handler action by editing the handler in the library. One
can change the colors and text format en masse by maintaining
inheritance in all objects below the stack level. Combined, these
techniques support making changes in one file or folder that will be
recognized at runtime by any stack that uses any of the modified
resources.
Isn't that what you are trying to accomplish when you place a generic
control & it's associated script in the object library?
Rob Cozens
CCW, Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
