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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
