Insert into back script logic

[David Burgun]

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