Mantis Bugtracker

ID Category Severity Reproducibility Date Submitted Last Update
0001494 [Squeak] System minor always 07-19-05 19:01 01-22-06 17:27
Reporter FrankShearar View Status public  
Assigned To
Priority normal Resolution open  
Status new   Product Version
Summary 0001494: [BUG] Cancelling halfway through Parser>>defineClass: doesn't
Description 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.
Additional Information
Attached Files  ParserDefineClassCanCancel-fbs.1.cs [^] (1,002 bytes) 01-22-06 17:24

- Relationships

- Notes
(0003579 - 677 - 717 - 717 - 717 - 717 - 717)
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 - 289 - 337 - 337 - 337 - 337 - 337)
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:.

- Issue History
Date Modified Username Field Change
07-19-05 19:01 KenCausey New Issue
07-19-05 19:03 KenCausey Reporter KenCausey => FrankShearar
01-20-06 15:21 FrankShearar Note Added: 0003579
01-22-06 17:24 FrankShearar File Added: ParserDefineClassCanCancel-fbs.1.cs
01-22-06 17:27 FrankShearar Note Added: 0003595

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
39 total queries executed.
30 unique queries executed.
Powered by Mantis Bugtracker