Opened 15 months ago

Last modified 10 days ago

#2845 reviewing enhancement

Enhance Progress(View)

Reported by: pfleck Owned by: mkommend
Priority: medium Milestone: HeuristicLab 3.3.16
Component: MainForm Version: branch
Keywords: Cc:

Description (last modified by pfleck)

The progress should explicitly differ between "progress" and "endless/marquee" instead of depending on the ProgressValue. Currently, ProgressValue <= 0 or > 1 is is interpreted as "endless" and shown as marquee. Instead we should explicitly differ between those two options and invalid operations should throw an exception (e.g. setting progress value of an "endless" progress). (Currently it is not possible to set an empty progress bar with ProgressValue 0)

Furthermore, the IProgress suggest a Cancel option; however, this does not work currently.

Change History (18)

comment:1 Changed 15 months ago by pfleck

  • Description modified (diff)
  • Summary changed from Progress(View) should explicitly differ between "progress" and "endless" to Enhance Progress(View)

comment:2 Changed 15 months ago by pfleck

  • Owner set to pfleck
  • Status changed from new to accepted
  • Version set to branch

r15405: Branched trunk

comment:3 Changed 14 months ago by pfleck


  • Fixed/Added Progress Cancellation/Stopping
  • Added Visible property to progress and ProgressBarMode.

comment:4 Changed 14 months ago by pfleck

r15417 Removed Visible property and hide on "Finished".

comment:5 Changed 14 months ago by pfleck

r15444 Cancel the artificial delay if progress is stopped.

comment:6 Changed 14 months ago by pfleck

r15445: Removed progressbar state (green/orange/red).

comment:7 Changed 14 months ago by pfleck


  • Start progres with initial progress value in several cases to use the progress value update.
  • Removed object disposal guard in ProgressView because it can block part of the initialization.

comment:8 Changed 13 months ago by pfleck


  • Added an explicit method for StartMarquee.
  • Renamed Add/RemoveOperationProgress methods.
  • Moved progress helpers from MainForm into static Progress methods named Show and Hide.

comment:9 Changed 9 months ago by pfleck

r15852 renamed branch folder

comment:10 Changed 4 weeks ago by pfleck

r16307 Merged trunk changes before source move into branch

comment:11 Changed 4 weeks ago by pfleck

r16308 reverted the last merge (r16307) because some revisions were missing

comment:12 Changed 4 weeks ago by pfleck

r16311 Merged trunk changes into branch (15406-15681, 15683-16308)

comment:13 Changed 4 weeks ago by pfleck

r16312 Adapted new Hive-Project-Management and RegressionSolutionVariableImpactsView to Progress updates.

comment:14 Changed 3 weeks ago by pfleck

r16314 Moved the entire progress API to the Progress class and made the progress API within the MainForm internal.

comment:15 Changed 3 weeks ago by pfleck

r16317 Combined separate Show methods into single one with enum parameter specifying the ProgressMode. Renamed Continuous and Marquee to Determinate and Indeterminate.

comment:16 Changed 3 weeks ago by pfleck

r16318 Add optional stop and cancel handler to the Show helpers. Replaced the AddProgressTo... and RemoveProgressFrom... methods with the existing Show and Hide methods.

comment:17 Changed 3 weeks ago by pfleck

r16319 merged latest trunk changes

comment:18 Changed 10 days ago by pfleck

  • Owner changed from pfleck to mkommend
  • Status changed from accepted to reviewing

I tried to merge back into trunk but it didn't go as expected.

r15406:15851 (before the branch-rename)
r15853:16318 (after the branch-rename)

Merging those two ranges does not work properly since the "big merge" from the trunk into the branch (which contained the trunk/sources rename) happened in the second revision-range (r16307). Thus, merging the first revision range into the trunk would require redoing that merge again.

Alternatively, I tried to merge all recent trunk changes into the branch and then make a "fast-forward" by merging from two different tree using the trunk as "from" and branch as "to" (as described in [0] at "Merging Two Different Trees"). In this scenario, the merge went fine (no conflicts), however, it seems that all the merge info got moved from the individual plugin folders into the trunk folder.


Note: See TracTickets for help on using tickets.