This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | allow the user to fix illegal property | ||
---|---|---|---|
Product: | platform | Reporter: | Rochelle Raccah <raccah> |
Component: | Explorer | Assignee: | _ tboudreau <tboudreau> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | asunhachawee, dsimonek |
Priority: | P3 | Keywords: | FOCUS |
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 29447, 31896 | ||
Bug Blocks: |
Description
Rochelle Raccah
2001-02-20 00:28:47 UTC
Try uncommenting line 755 in PropertyDisplayer and test. It will probably work ok only when hitting Enter. A way to make it work also after the user clicks on another property has to be found. Target milestone -> 3.3 Reasign Target milestone -> 3.3.1. Important, but beware, impl will be probably *very tricky*, count with it. Set target milestone to TBD Set target milestone to TBD This can be partly resolved by implementation 17184. I feel this is a bug because user expects that a value should change. Error dialogs should pop up in context and give the user a chance to resolve the issue. Currently, the user is being presented with the equivalent of "This is a wrong value. Too bad. You can't change it unless you go back and track it down yourself." It's like the IDE is half heartedly trying to help the user. Note, that all the other major IDEs do not allow user to leave a node unless they correct the value. For example, .NET does not do this. Eclipse simply doesn't allow user to change properties. BTW, I don't see how bug 17184 affects this bug, unless i misunderstand. Does "implementation 17184" refer to issuezilla 17184 or not? Adding to property sheet rewrite umbrella. Note this is not yet fixed with property sheet rewrite, but should be comparatively easy - add a boolean return value from PropUtils.updateProp() and don't close the editor if it returns false. I just took enough of a stab at implementing this to find out that it will be more work than I thought, even in the new property sheet - so I'm just adding some notes on what to do while it's fresh in my mind: - Migrate away from a shared cell editor for all instances of SheetTable - Modify PropUtils.updateProp to take a WindowListener argument - Implement that on SheetTable, and once we're creating cell editors per table, the cell editor can know which SheetTable invoked it, and use it as a windowlistener to pass The problem is that the code that displays the dialog (which I more or less reused unmodified from the old property sheet) returns immediately, briefly setting focus to the property sheet as it removes its editor, then the dialog pops up. I could probably do a horrible hack and re-initiate editing after two focusGained events have been received following a failed edit, but that's a bit too likely to fail for my taste. Better to do it correctly. Fixed on the property panel rewrite branch Property panel rewrite branch merged. |