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: | Provide a way to disable initial delay for displaying the progress monitor | ||
---|---|---|---|
Product: | platform | Reporter: | Sherold Dev <sherold> |
Component: | Progress | Assignee: | Milos Kleint <mkleint> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | anebuzelsky, jrechtacek, mkleint |
Priority: | P3 | Keywords: | API, API_REVIEW_FAST |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 58882 | ||
Attachments: | api diff |
Description
Sherold Dev
2005-07-14 10:58:51 UTC
Please consider increase priority and/or type of this issue as with current delay it is not nice when using it in modal dialog as necessary in issue #58882 when used for first opening Help window when helpsets are loaded. In my experiment I changed TIMER_QUANTUM to 10 and INITIAL_DELAY to 50 and it works fine. (Though not sure if both values must be changed. I suppose if I do not use progress with work units ie. do not call start(int) and progress(int) methods TIMER_QUANTUM need not be changed. It's a defect to me. I have to use a silly workaround in Autoupdate and wait INITIAL_DELAY to force to show finished state. for dialog placed progress bars the issue should be fixed already. no api required for that. for status bar placed items I think we need to add an API to progresshandle. something like setInitialDelay(int) where the parameter will be the minimum duration of the task that is required in order to show up in status bar. Created attachment 24650 [details]
api diff
the proposed API change is attached, please review. setInitialDelay(int) was added both to ProgressHandle and AggregateProgressHandle allowing people to set custom value, both long and short. My advice is to add new factory method instead of the setter. well, unfotunately that would mean add 4 new factory methods, instead of the 2 setters. Also the setter has the advantage that in 90% cases the API users don't have to care about it. With additional factory methods you have to explicitly decide which method to use and understand what the initial delay is for. Ok, it was just advice. I just believe that if something makes sence to be set just ones, it should not be setter. reassigning done, api added. Checking in manifest.mf; /cvs/core/progress/manifest.mf,v <-- manifest.mf new revision: 1.5; previous revision: 1.4 done Checking in api/doc/changes/apichanges.xml; /cvs/core/progress/api/doc/changes/apichanges.xml,v <-- apichanges.xml new revision: 1.4; previous revision: 1.3 done Checking in src/org/netbeans/api/progress/ProgressHandle.java; /cvs/core/progress/src/org/netbeans/api/progress/ProgressHandle.java,v <-- ProgressHandle.java new revision: 1.3; previous revision: 1.2 done Checking in src/org/netbeans/api/progress/aggregate/AggregateProgressHandle.java; /cvs/core/progress/src/org/netbeans/api/progress/aggregate/AggregateProgressHandle.java,v <-- AggregateProgressHandle.java new revision: 1.4; previous revision: 1.3 done |