Hi Jim,
Not sure exactly what you are doing, but it sounds like something I
had to do a while back, and was one of the reasons I developed ISM
(to make doing things like this easier/quicker to implement).
For instance say you had a button that when pressed sent somehow
indicated that something should be sold for $500. This would equate
to the following in my ISM based Apps:
Script of button "Sell for $500"
get ISMPutMessage("msg_SellForAmount","KindSellForAmount","$500")
Any object (Stack, Card, Group or Control) listening for this message
would receive the "$500".
Now lets say some external event results in a %10 discount being
offered for a limited time.
In my App, I'd do this:
Script for button "Apply 10% discount"
get ISMListenForMessagePriority
( "msg_SellForAmount","KindSellForAmount")
Then when the message is sent, it is sent to the "Apply Discount"
button before any other objects. In this handler, I'd then do:
on msg_SellForAmount theMessageID,theMessageKind,theMessageData
local myNewMessageData
get CalcNewAmount(theMessageData) into myNewMessageData
get ISMModifyMessageInChain(theMessageID,theMessageKind,
myNewMessageData)
end msg_SellForAmount
This changes the message value for all Objects further along the
chain, so they get the new value. The new message is not kept beyond
the current message chain.
When when the discount is no longer required, you'd do:
ISMStopListeningForMessage
( "msg_SellForAmount","KindSellForAmount",ObjectLongID)
And everything would return to normal.
This just seems like an easier way of doing things IMO and is more
flexible, since you can "filter" individual messages.
All the Best
Dave
On 1 Apr 2006, at 08:01, Jim Ault wrote:
Ah, Sarah & Richard,
Thanks for the responses.
I will test one or two configurations, and probably go with a field
and
place useage the notes in the field. This is in-house software
that will
get very complicated over the next 6 months, but there cannot be a
good blue
print now since the project is dynamic.
The reason for the card script approach vs btn/fld had slight
merit, but not
enough to bother with at the moment. The idea is to make the stack
script a
foundation + the card script changeable to re-program some of the
buttons
and provide changeable functions for the stack script to call.
This will
still work.
The simple setup would put changeable functions above (back) the stack
script and still load changeable functions for buttons at the card
level,
thus each card containing buttons could be separate. Now I can see
that
having the duplicate instance of the card script will not interfere
with my
design.
The basic tenant is that several parts of the functionality and
filtering
could be updated during a day of continuous operation to produce a
changeable division of labor and our workers would not know or
care. They
make moves based on the final results.
One example of this is the random occurrence of data feed
irregularities
that cripple the ability to process the indicators that we need.
When I
detect the problem, only then will I be able to build a fix, and
may only
need it for that episode. In the next step, I may need to update the
operating remote clients on-the-fly to adjust for the changed data
flow and
format.
We are in a fast-paced-money environment where we want to take
advantage the
best possible data we can extract under all conditions, and avoid poor
advantage plays. Both result in losses otherwise. Mid-morning
reprogramming and change of assignments is essential.
Crossing my fingers that tomorrow will work smoothly :-)
Thanks again.
Jim Ault
Las Vegas
_______________________________________________
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
