Mantis - Squeak
Viewing Issue Advanced Details
1494 System minor always 07-19-05 19:01 01-22-06 17:27
FrankShearar  
 
normal  
new  
open  
none    
none  
0001494: [BUG] Cancelling halfway through Parser>>defineClass: doesn't
Suppose Parser>>defineClass: gets invoked (like in the recent post re "LanguageEditor := Morph new.").

If you cancel the first FITBM (which asks you for a class category) it will continue the defining process with category 'Unknown' - in other words, you can't cancel the #defineClass: at this point.

If you cancel the second FITBM (which asks you for a class definition) it will continue the defining process with some basic definition - in other words, you can't cancel the #defineClass: at this point. (As a side issue, it'd be nice for the FITBM to be a bit larger - a class definition's quite a bit of text, and it's hard to read it in such a small FITBM.)

So if you invoke Parser>>defineClass: and cancel at any point where the UI offers you a cancelling option, you still end up creating a new class of some sort.
 ParserDefineClassCanCancel-fbs.1.cs [^] (1,002 bytes) 01-22-06 17:24

Notes
(0003579)
FrankShearar   
01-20-06 15:21   
The problem is that FITBM offers no distinction between a user hitting the cancel button (the answer is '') and the user entering a blank string (the answer is '').

In particular, it may be reasonable in Parser>>defineClass: to set the category to 'Unknown' if the user enters a blank string (i.e., leaves the input field blank and hit the 'ok' button) but not if the user hits the 'cancel' button.

I can see one of two solutions: either don't let the user cancel these two FITBMs (they can delete the class after they're done), or bail out the method if either FITBM returns the empty string, maybe with a notification saying "you elected to bail so no class was added".
(0003595)
FrankShearar   
01-22-06 17:27   
ParserDefineClassCanCancel-fbs.1.cs makes Parser>>defineClass: return nil if the user clicks "cancel" on either FITBM (or the user empties the input field & hits "ok").

I'm not sure if that's good enough, partly because I haven't looked at all the places that call Parser>>defineClass:.