| Anonymous | Login | 10-22-2021 20:17 UTC |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | |||||||||||
| 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) 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 - 289 - 337 - 337 - 337 - 337 - 337) 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:. |
|
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. |  |
