Target not working???

[Rob Cozens]

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)