Target not working???

[David Burgun]

Good Morning to you too Rob, although it's late afternoon here!

On 28 Mar 2006, at 16:45, Rob Cozens wrote:

> Morning Dave,
>
>> All I want to do is to call a handler if it exists in a script.  
>> I've read up on the message path etc. but not sure how it applies  
>> in this case. Could you elaborate?
>>
>
> Moi & my foolesh mouth!
>
> Now I have to analyze your code in more detail, ignore your  
> question, or offer another general opinion.
>
> In general, I echo Mark's feeling:
>
>> I still think you're fighting the "natural" object hierarchy.
>
> But, as I said previously, this does not mean your approach won't  
> work.
>
> So help me understand the underlying goal.

My goal is/was to be able to create application more quickly, which  
is why I use started using RevRev in the first place!

In order to explain how I arrived at the ISM solution I will have to  
describe a bit of history!

I started off programming in Assembler on Mini-Computers working  
mainly on data entry systems. One of the system had a Dartmouth BASIC  
implementation which is where I got my first taste of high level  
languages. Another of the Mini's had a LISP compiler and another had  
a SNOBOL4 and later a SPITBOL implementation which is where I first  
discovered xTalk type environments.

I then moved to micro-processors, specialized systems embedded  
systems, coding in assembler, 8080, Z80 and 6800 to name a few. I am  
access to a mini that ran SPITBOL which I used to develop tools to  
help write and analyze code in written assembler.

Then came the PC. Again, I programmed mostly in Assembler and used  
BASIC and SNOBOL4 (running on the PC) to write tools. I started  
using  a mixture of C and assembler for parts that needed speed (C  
compiler technology wasn't that great in those days). I remember GEM  
as being the first real graphical environment I used. I then moved to  
UNIX and RISC chips, programming mostly in C. Then in 1989 I started  
on the Mac initially using Think Pascal and then C. Hypercard was  
around then, but like 99% of the programming world, I really didn't  
understand it, and besides machines were not really fast enough to do  
it justice in those days, especially for the type of work I was  
doing. C++ started to take off and I gradually moved over to using it.

I looked at V1 of RunRev, thought it was a GREAT concept, but V1  
didn't really do enough to make it worthwhile. Then around 2 years  
ago I started playing with RunRev V2 and was VERY excited it could do  
what I wanted and the processors were now fast enough to make it  
worthwhile. Since then I have written around 8 RunRev applications,  
some of them used External Commands for heavy-duty image processing.

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.

One of the things I hated was writing GUI code in C and C++, it just  
took way to long to write the code, was hard to debug and wasn't  
really cross platform (depending on the Framework being used).

This is why RunRev was/is such an attraction to me. When I first  
started with RunRev, I could do something in (say) 5 days it would  
have taken me (say) 5 weeks in C/C++ *and* it was Cross Platform. A  
great gain. Call this a 5:1 ratio for RunRev vs C/C++.

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. For instance if you  
use the common routine/hard coded object names approach and have two  
Apps already written using that technique and then want to use parts  
of the two apps in a new app, you have to re-code the common routine  
so as to take account of the new objects. If the parts from the two  
existing apps just happen to have the same object names then it makes  
the job that much more difficult. You have to expend energy making  
parts that are already debugged and working in separate apps just to  
get the same functionality in a new app. Then you have to add the new  
pieces and update the common routine again to take into account the  
new pieces. As the common routine grows in complexity it take longer  
and longer to build a new application, e.g. it is a data dependent  
algorithm.

At this stage I'd guess I had an 10:1 ratio RunRev vs C/C++.

But being lazy (as most programmers/engineers are), I wanted MORE!!!!

Taking a step back from this, Object Oriented Programing (OOP) in  
general promoted the concept of Object-reuse, and I remember thinking  
that one of the good things about C++ was that given an existing  
object to was fairly simple (in C/C++ terms) to incorporate a  
existing objects into a new App, and I remember thinking "if only it  
were like this in RunRev".

So began the ISM. 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!

Right now I'd say I had a 30:1 ratio RunRev vs C/C++!!

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. The new piece is then available for  
use in the next app and so it just gets faster and faster. The  
snowball is getting bigger and it's moving more quickly!

> 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.

I'm revising the ISM so as to make it more developer friendly and  
therefore even easier to use it in other apps. Once I've done that, I  
was intending to put it on revOnline.

All the Best
Dave