Free cookie consent management tool by TermsFeed Policy Generator

Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#842 closed enhancement (done)

ProgrammableOperator Overhaul

Reported by: epitzer Owned by: abeham
Priority: medium Milestone: HeuristicLab 3.3.1
Component: Operators.Programmable Version: 3.3.1
Keywords: Cc:

Description

Quite a number of tickets have accumulated concerning the programmable operator (#607, #179, #450, #173, #482). In a complete overhaul these bugs should be addressed.

Change History (33)

comment:1 Changed 14 years ago by epitzer

  • Status changed from new to assigned

comment:2 follow-up: Changed 14 years ago by epitzer

Add SharpDevelop libraries to support syntax highlighting and code completion (r2685)

comment:3 in reply to: ↑ 2 Changed 14 years ago by epitzer

should be (r2658)

comment:4 Changed 14 years ago by epitzer

Add new Plugin that provides a code editor with syntax highlighting and code completion (r2659)

comment:5 Changed 14 years ago by epitzer

New ProgrammableOperator with syntax highlighting, code completion, configurable assemblies and namespaces (r2660)

comment:6 Changed 14 years ago by mkommend

corrected SharpDevelop plugin r2661

comment:7 Changed 14 years ago by epitzer

Ensure proper resizing of CodeEditor and don't crash when removing non-existent assemblies (r2667)

comment:8 Changed 14 years ago by epitzer

Group assemblies by plugin and replace assembly and namespace list boxes with tree views (r2668)

comment:9 Changed 14 years ago by gkronber

Fixed incorrect reference to PluginInfrastructure with r2670.

comment:10 Changed 14 years ago by epitzer

Add InvokeRequired in Dispose method to prevent cross-thread access exception (r2672)

comment:11 Changed 14 years ago by epitzer

use SharpDevelop's TextArea.KeyEventHandler to prevent editing before Prefix and after Suffix (r2673)

comment:12 Changed 14 years ago by epitzer

Filter out generated assemblies during discovery (r2678)

comment:13 Changed 14 years ago by epitzer

statically initialize list of assemblies and plugins (r2679)

comment:14 Changed 14 years ago by epitzer

keep namespace treeview node expansion and expand newly added namespace nodes (r2680)

comment:15 Changed 14 years ago by epitzer

also allow sub namespaces that don't contain any types (r2681)

comment:16 Changed 14 years ago by epitzer

try a different method for signaling the parser thread to terminate (r2719)

comment:17 Changed 14 years ago by epitzer

disable elements while updating (or compiling) (r2720)

comment:18 Changed 14 years ago by epitzer

check temp path, and disable code completion persistence in case of file permission problems (r2762)

comment:19 Changed 14 years ago by epitzer

properly close test file and explicitly catch all possible exceptions (r2765)

comment:20 Changed 14 years ago by epitzer

towards migration of ProgrammableOperator to HL 3.3 (r2799)

comment:21 Changed 14 years ago by epitzer

further steps towards migration of ProgrammableOperator to HL 3.3 (r2877)

comment:22 Changed 14 years ago by epitzer

Finished initial port of ProgrammableOperator to HL 3.3 (r2897)

comment:23 Changed 14 years ago by gkronber

Fixed plugin dependency in programmable operator plugin with r2978.

comment:24 Changed 14 years ago by epitzer

adaptation to HL 3.3 (r3008)

comment:25 Changed 14 years ago by epitzer

Correctly update displayed method signature if operator parameters change (r3014)

comment:26 Changed 14 years ago by epitzer

Change Project references (r3056)

comment:27 Changed 14 years ago by svonolfe

Added check to ProgrammableOperator if the ApplicationManager exists so it can be used outside of HL in r3234

comment:28 Changed 14 years ago by abeham

I wanted to add two more issues encountered when I was using the ProgrammableOperator recently:

  1. The parameters cannot be set.
  2. Using the default method parameter context in the code results in missing references.

Regarding 1.: The Execute method signature contains the values of the parameters, but not the parameters themselves. This means that if I design a custom evaluator with a Quality parameter, the value will be null (Quality is not yet available) and it cannot be set through (typically) QualityParameter.ActualValue = ... as only the value is given in the signature. It would be better to have the parameter itself in the method signature instead of its ActualValue.

Regarding 2.: E.g. the simple line "int count = context.Scope.SubScopes.Count;" requires that I add HeuristicLab.Collections.ObservableList as well as System.ComponentModel.INotifyPropertyChanged. I would suggest including a bigger set of assemblies that are loaded by default.

There are also a view usability issues (from my point of view):

  1. There is no indication of what the two tree views on the left contain. A label "Assemblies" and "Namespaces" should probably be included.
  2. The first tree view lists all HeuristicLab plugins/assemblies first and groups everything else under "other", while the second tree view lists all other namespaces first and then groups the HeuristicLab ones at the end. It would be better if both lists had the same grouping and order.
  3. No text can be entered in the line just above "return null;", but tab, backspace, and return do work.
Version 0, edited 14 years ago by abeham (next)

comment:29 Changed 14 years ago by epitzer

Incorporate changes suggested by abeham in comment:28 (r3903)

  • Fix persistence of selected assemblies
  • Fix problem with static initialization
  • Make parameter values (ActualValue) with parameter object
  • show (or hide) parameter namespaces as necessary
  • add icons for buttons, assemblies and namespaces
  • sort assemblies and namespaces alphabetically
  • correctly mark and unmark select assemblies
  • put assemblies and namespaces into group boxes

comment:30 Changed 13 years ago by abeham

  • Owner changed from epitzer to abeham
  • Status changed from assigned to accepted

This ticket spans prerelease commits as well as postrelease. I'm closing this as released under 3.3.1. Any issues concerning the programmable operator should go into own tickets. #173 is still left open, I don't know what to do with that.

comment:31 Changed 13 years ago by abeham

  • Status changed from accepted to readytorelease

comment:32 Changed 13 years ago by abeham

  • Resolution set to done
  • Status changed from readytorelease to closed
  • Version changed from 3.2 to 3.3.1

comment:33 Changed 13 years ago by swagner

  • Milestone changed from Current to HeuristicLab 3.3.0

Milestone Current deleted

Note: See TracTickets for help on using tickets.