I had a point-by-point response prepared, but I'm going to forgo it. It comes down to this: you are saying that overriding existing behavior is the same thing as blocking behavior. I disagree-- or at least I did before we got into this. In the case of my quest stone, I must allow the movement to occur (by invoking the default handler-- not by writing my own code), and then check the current location in order to adjust the item's properties. I feel that is reasonable to expect a spec_proc to do this, but apparently this goes against assumptions made in the stock code. If I'm the only one who wants to code it that way, then I guess the "bug" is not relevant to everyone else as I had assumed. I might even be persuaded to change some of my procs around, since I'm bound to run into other examples of stock code that makes the same assumptions. In any case, I should proabably avoid such debates when I'm wired from watching CNN for 16 hours. Thanks for your views. Mike -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST