"TM" == Timothy Moore moore@bricoworks.com writes:
TM> On Aug 10, 2005, at 12:01 PM, rpgoldman@real-time.com wrote:
>>>>>>> "TM" == Timothy Moore moore@bricoworks.com writes: TM> See 24.3 in the Input Editing chapter which describes the >> conditions TM> SIMPLE-PARSE-ERROR and INPUT-NOT-OF-REQUIRED-TYPE. >> >> Thanks. I did look at those. The problem is that if I hoist an >> INPUT-NOT-OF-REQUIRED-TYPE error, it's just that --- an error. There >> is no automagical trapping to reprompt to get good input. We just >> throw an error at the user, which doesn't seem like a very nice thing >> to do...
TM> Ah, but that's a quality of implementation issue. I think it would be TM> completely reasonable for the command reader to do something friendly TM> with these errors. The accepting-values code does try to something TM> reasonable with any error that results from accept.
A related problem is that when I tried to set up accept to do the reprompting along the lines that I had mentioned in my earlier email, I found that it turned the pane whence command argument values were being read into gobbledygook --- my format string, that was supposed to tell the user s/he had done something wrong, got echoed all over the form for inputting values, making it unusable. :-(
I.e., modifying the ACCEPT method for this purpose seems inappropriate, since you don't have enough control over the context within which ACCEPT will be invoked.
This seems to suggest that one might need to modify STREAM-ACCEPT instead. But that seems like a bit of a Catch-22. That option seems pretty much open to you only if (a) you provide a completely new method for stream-accept or (b) you have access to the source code to modify.
So does this mean that we have, in McCLIM, a version of ACCEPT that doesn't provide enough of a stable context for us to extend built-in methods? Is the spec insufficiently strong to allow us to extend the ACCEPT protocol without risk of breaking things? Or have I overlooked something (quite likely, alas)?
Best, R