Hersteller von Standardsoftware möchten

Transkript

1 Customizing von Standardsoftware leicht gemacht Software zur Laufzeit anpassen Der Beitrag beschreibt aus Entwicklersicht, welche Möglichkeiten das Produkt icustomizer bietet, um Software zur Laufzeit zu beeinflussen. Kunden können die Anwendung damit anpassen, ohne in den Sourcecode einzugreifen. Auf einen Blick Marco Spilker ist Softwareentwickler bei der ngroup in Hildesheim. Er ist für die Architektur der betriebswirtschaftlichen Software verantwortlich, berät in technologischen Fragen und dient als Anlaufstelle im internen Support. Der studierte Rechtswissenschaftler konvertierte zur Jahrtausendwende zum Informatiker und machte damit seine Leidenschaft zum Beruf. Marco widmet sich seit 2003 der.net-programmierung. Inhalt Vorstellung des Tools icustomizer. Wie man den icustomizer in eigenen Anwendungen nutzt. Wie Kunden das Produkt einsetzen. dnpcode A1201iCustomizer Hersteller von Standardsoftware möchten ihre Kunden zufriedenstellen und müssen dazu immer wieder Sonderwünsche realisieren. Das stellt Softwareentwickler in der ganzen Welt vor die Herausforderung, eine Vielzahl unterschiedlicher Versionen warten zu müssen. Hier wird aufgezeigt, welche Möglichkeiten das Produkt icustomizer [1] bietet, um den Programmablauf zur Laufzeit zu beeinflussen. Kunden oder auch Consultants können mit icustomizer eigene Anpassungen an der Software vornehmen, ohne dass der Hersteller in den Sourcecode der Anwendung eingreifen muss. Als Entwickler einer ERP-Standardsoftware standen wir bei der ngroup vor der Aufgabe, kundenspezifische Anpassungen aus unserer Software auszulagern. Ziel war es, die Standardsoftware von individuellem Code zu befreien, um bei der Release-Planung und -Durchführung keine Rücksicht auf spezielle Kundenversionen nehmen zu müssen. Wir haben zu diesem Zweck den icustomizer entwickelt: um unseren Partnern und Kunden Einflussmöglichkeiten zu geben und sie Funktionen erstellen zu lassen, die wir als Entwickler nicht vorgesehen haben. Der icustomizer besteht aus zwei Teilen, einem Designer und einem Skripteditor. In die eigene Anwendung muss nur wenig Quelltext eingebaut werden, damit die Applikation zur Laufzeit den kundenindividuellen Code ausführen kann. Den Designer anpassen Hersteller einer Software können den Designer des icustomizers konfigurieren und so festlegen, welche Möglichkeiten sie ihren Kunden einräumen wollen. Es können die Änderungen an einzelnen Eigenschaften (Properties) von Steuerelementtypen gezielt erlaubt oder verboten werden. Der Designmodus für einzelne Controls oder Typen von Controls kann geändert oder gesperrt werden. Die Toolbox kann mit formularspezifischen Elementen gefüllt werden. Events können formularspezifisch benutzt werden. Die Speicherstreams für das Laden und Speichern der Customizings können umgeleitet werden. Dem Benutzer kann das Editieren von Skripten erlaubt oder verboten werden. Designer und Skripteditor Der Designer ist einwerkzeug, mit dem GUI-Elemente und Control-Eigenschaften bearbeitet oder neue Controls hinzugefügt werden (Abbildung 1). Wie aus Entwicklungsumgebungen bekannt, stehen dabei Hilfslinien zur Ausrichtung von Controls, eine Toolbox für neue Controls und ein PropertyGrid zum Editieren der Eigenschaften zur Verfügung. An Controls können grafische Anpassungen vorgenommen werden. So kann beispielsweise die Position von Feldern und Buttons, die Textfarbe oder Ähnliches den eigenen Wünschen angepasst werden. Bei der Implementierung wurden die Klassen DesignSurface und DesignerHost aus dem Namensraum System. ComponentModel.Design verwendet, sodass der gleiche Designmechanismus wie in Visual Studio genutzt wird. Es können neue Controls hinzugefügt sowie vorhandene Controls um neue Funktionen erweitert werden, die ursprünglich nicht vorgesehen waren. Das geschieht über die Definition von Eventhandlern. Der Code wird mit dem Skripteditor geschrieben (Abbildung 2). Im Skripteditor wird man beim Programmieren unterstützt durch Auto- Die Integration vorbereiten Um icustomizer in ein eigenes Windows-Forms- Projekt integrieren zu können, müssen folgende Vorarbeiten erledigt werden: Einen Verweis auf die Assembly ngroup.formcustomizer.dll hinzufügen. Die Lizenzdatei ngroup.formcustomizer.licx dem Projekt als eingebettete Ressource hinzufügen. Dadurch wird beim Erstellen des Projekts der License Compiler lc.exe ausgeführt und die Lizenz wird in die Anwendung eingebettet. Beim Kunden sind keine weiteren Lizenzen bereitzustellen. Die Konfigurationsdatei ngroup.formcustomizer. dll.settings.config zum Projekt hinzufügen und die Option In Ausgabeverzeichnis kopieren aktivieren, darüber hinaus in der app.config-datei den Abschnitt ngroup.formcustomizer.properties.settings eintragen. In der Konfigurationsdatei kann ein Hotkey für den Aufruf des Bearbeitungsmodus des icustomizers festgelegt oder deaktiviert werden.außerdem kann dort das Verzeichnis angegeben werden, in dem die Dateien mit den Benutzeranpassungen gespeichert werden. Beide Mechanismen lassen sich auch im Code anpassen oder komplett überschreiben

2 [Abb. 1] Im Designer entwickelt man alle kundenspezifischen Anpassungen der Benutzeroberfläche. [Abb. 2] Der Entwickler wird beim Programmieren durch Auswahlfelder unterstützt. vervollständigung, Auswahlfelder möglicher Funktionen und farbliche Hervorhebung, sodass diese Arbeit leicht von der Hand geht. Zur Ausführungszeit werden die geschriebenen Skripte dynamisch kompiliert. Dabei kommt die C#-Version des System. CodeDom.Compiler.CodeDomProvider zum Einsatz. Damit stehen die gesamte C#-Syntax und der vollständige Funktionsumfang von.net zur Verfügung. Im Skripteditor lassen sich auch eigene Assemblies oder solche von Drittherstellern laden und integrieren, die dann mit dem Skriptcode, den Controls oder den Events verknüpft werden können. Auf diese Weise ist quasi jede Anwendung integrierbar und der Skriptcode dient als Anknüpfungspunkt für die gesamte.net-infrastruktur. Nach dem Starten des Designers steht ein PropertyGrid zur Verfügung, mit dem man die Eigenschaften der Controls und die Events der Controls verändern kann. Als Entwickler beim Hersteller können Sie festlegen, welche Änderungsmöglichkeiten Sie Ihren Kunden erlauben möchten (siehe Kasten Den Designer anpassen). Es gibt die zwei Grundeinstellungen alles erlaubt und alles verboten und darüber hinaus individuelle Einschränkungsmöglichkeiten für jedes Control und jeden Event. So lässt sich beispielsweise konfigurieren, dass alles erlaubt ist außer dem Zugriff auf ein Textfeld eines bestimmten Controls. Ein Beispiel für die Konfigurationsmöglichkeiten zeigt Listing 1. icustomizer integrieren Mit wenigen Codezeilen lässt sich der icustomizer in eigene Produkte integrieren. Zunächst sind einigevorbereitungen notwendig, die Sie im Kasten Die Integration vorbereiten nachlesen können. Danach lässt sich der icustomizer mit der festgelegten Tastenkombination in der eigenen Anwendung aufrufen. Man kann sich den icustomizer als Verlängerung des Windows-Forms-Designers von Visual Studio in die Laufzeit der Software hinein vorstellen. Daher muss er zu einem möglichst frühen Zeitpunkt an die Form angehängt werden. Die Einstellungen des Windows-Forms- Designers werden ganz am Anfang des Lebenszyklus getroffen, indem im Konstruktor der Form die vom Windows- Forms-Designer erzeugte Methode InitializeComponent aufgerufen wird. Nach dem Ausführen dieser Methode befindet sich die Form in dem Zustand, der zur Designzeit im Designer festgelegt wurde. Danach werden gegebenenfalls vom Entwickler noch weitere Initialisierungen im Konstruktor programmiert oder aus dem Code heraus Eigenschaften der Form gesetzt, bevor diese angezeigt wird. Den icustomizer mit Windows Forms verknüpfen Das nächste Ereignis im Lebenszyklus der Form ist der Event HandleCreated beziehungsweise das Ausführen der Methode OnHandleCreated. Dieses stellt einen ge

3 _ Customizing von Standardsoftware leicht gemacht Listing 1 Konfigurieren des Designers. /// Is triggered whenever a Form is being set into the design mode, and once for each Control. /// Can be used to change the design mode for specific Controls (see MainWindow.CustomizerChangeComponentDesignMode). /// In this demo the event is also directed to the currently active Form and CustomizerChangeComponentDesignMode does nothing. /// <param name="sender">the source of the event.</param> /// <param name="args">the <see cref="ngroup.formcustomizer.getcomponentdesignmodeeventargs"/> instance containing the event data.</param> public static void CustomizerChangeComponentDesignMode(object sender, GetComponentDesignModeEventArgs args) // Since we are setting the event in CustomizerActivating to trigger CustomizerChangeComponentDesignMode on the Form, there is no code here. // If there was a type of Control to never be customizable at all, this would be a nice place to declare it. ////if (args.component is *ControlType*) args.designmode = ComponentDesignModes.None; /// Disable specific properties for types of Controls. private static void ConfigureDisablePropertySettings() // The Text property of a textbox should not be changeable in the Customizer, since it is set by business logic. Customizer.ControlDefaultDisableProperties.Set(typeof(TextBox), "Text", DisablePropertySetting.Disable); // Enabled is also not allowed to be changed, because it could prevent from important buttons being pressed. Customizer.ControlDefaultDisableProperties.Set(typeof(Control), "Enabled", DisablePropertySetting.Disable); // By default everything is allowed to be changed. Above is the command to disable specific properties. // You can also change the default by setting it to DisablePropertySetting.Disable. // Now ALL properties are not allowed to be changed. // Only properties allowed by setting DisablePropertySetting. Enable will be allowed to be changed. ////Customizer.ControlDefaultDisableProperties.Default = DisablePropertySetting.Disable; ////Customizer.ControlDefaultDisableProperties.Set(typeof(*ControlType*), //// "*PropertyName*", ngroup.formcustomizer.disablepropertysetting.enable); /// Sets what kind of customization the user is allowed to do. /// <param name="allowcustomizingforuser">allow starting the customizer and doing UI changes.</param> /// <param name="allowscriptingforuser">allow scripting.</param> public static void SetCustomizerAvailability(bool allowcustomizingforuser, bool allowscriptingforuser) // Note: If EnableDesignerForUser is false while attaching a new Form the customization will be loaded in show-only mode, which is faster. // The user will not be able to change this forms customization even if the EnableDesignerForUser value changes. // Only when the Form is created while EnableDesignerForUser is true it will be possible to customize. Customizer.EnableCodeEditorForUser = allowscriptingforuser; Customizer.EnableDesignerForUser = allowcustomizingforuser; /// Adds a collection of Controls to the Toolbox. /// The Controls can then be placed on a Form in design mode. private static void AddToolboxItems() Customizer.AddToolboxItem(typeof(Button), "Controls", "Buttons", true); Customizer.AddToolboxItem(typeof(TextBox), "Controls", "Textboxes", true); Customizer.AddToolboxItem(typeof(Label), "Controls", "Textboxes", true); Customizer.AddToolboxItem(typeof(CheckBox), "Controls", "Buttons", true); Customizer.AddToolboxItem(typeof(RadioButton), "Controls", "Buttons", true); Customizer.AddToolboxItem(typeof(GroupBox), "Container", "Groupings", true); Customizer.AddToolboxItem(typeof(Panel), "Container", "Groupings", true); Customizer.AddToolboxItem(typeof(SplitContainer), "Container", "Groupings", true); Customizer.AddToolboxItem(typeof(DataGrid), "Container", "TableViews", true);

4 Listing 3 FormCreationObserver. FormCreationObserver formcreationobserver = new FormCreationObserver(); formcreationobserver.formcreating += FormCreating; formcreationobserver.startobserving(); Listing 2 Eventhandler FormCreating. public static event EventHandler FormCreating; protected override void OnHandleCreated(EventArgs e) if (!this.recreatinghandle) EventHandler formcreating = FormCreating; if (formcreating!= null) formcreating(this, e); base.onhandlecreated(e); eigneten Zeitpunkt für das Anhängen des icustomizers dar: Alle Designzeit-Einstellungen sind getroffen, aber die Form wird noch nicht angezeigt. Üblicherweise sollen alle Forms oder ausgewählten Forms einer Anwendung für das Customizing zurverfügung stehen. Damit der Code nicht jeder Form individuell angepasst werden muss, bietet es sich an, OnHandleCreated in einer gemeinsamen Basisklasse aller anpassbaren Forms zu überschreiben. So kann etwa ein statisches Event FormCreating erstellt werden, welches das Erzeugen neuer Forms an einem zentralen Punkt überwacht (Listing 2). Als Alternative zur Basisklasse stellt der icustomizer die Klasse FormCreationObserver bereit (Listing 3). Diese Klasse erlaubt es, über einen lokalen Windows Hook [2] die gesamte Anwendung auf das Versenden der Fensternachricht WM_CREATE zu überwachen. So kann für alle Forms der Anwendung ein FormCreating-Ereignis bereitgestellt werden, ohne etwas an den Forms der Anwendung zu verändern. Wird man auf die eine oder andere Art und Weise über die Erstellung einer neuen Listing 4 Customizer.Attach. public static void FormCreating( object sender, EventArgs e) Form form = sender as Form; Customizer.Attach(form); [ ]

5 _ Customizing von Standardsoftware leicht gemacht Form benachrichtigt, so kann nun der icustomizer im Eventhandler an die Form angehängt werden. Dazu muss die statische Methode Customizer.Attach aufgerufen werden (Listing 4). Der icustomizer merkt sich nun alle Eigenschaften der Form, indem er rekursiv über alle Controls iteriert und den Zustand der Property-Deskriptoren speichert. Werden später der icustomizing-modus aktiviert und der Designer gestartet, kann damit die Form in diesen Zustand zurückversetzt und die Änderungen können im Designer als Differenz (Customizing) abgespeichert werden. Dieser Schritt ist also nur notwendig, wenn später ein Customizing der Form durchgeführt werden soll. Dieses lässt sich über die Eigenschaft EnableDesignerFor- User deaktivieren. Laden von Customizings Nachdem sich der icustomizer den Ursprungszustand der Form gemerkt hat, sucht er basierend auf dem Typnamen der Form nach einem vorher gespeicherten Customizing. Dabei wird standardmäßig im Dateisystem gesucht. Der Ladevorgang lässt sich aber überschreiben und anpassen, indem ein Delegat für die Ladefunktionalität angegeben wird. Umgekehrt kann auch ein Delegat für das Speichern angegeben werden. Die Delegatmethoden müssen folgende Signaturen tragen: Stream LoadCustomization( string customizingname); void SaveCustomization( string customizingname, Stream s); Wurde vom icustomizer ein Customizing für die eben geladene Form gefunden, so wird es im nächsten Schritt auf die Form angewendet. Dabei werden die im Customizing gespeicherten Eigenschaften gesetzt, die Skripte kompiliert und als Eventhandler mit den entsprechenden Events der Form und der Controls verbunden. Starten des Designers Danach wird die Form normal geladen. Es kann nun jederzeit der Designmodus des icustomizers aktiviert werden. Dazu muss die Methode Customizer.ActivateCustomizer aufgerufen werden. Standard ist, dass dieser Aufruf mit dem Hotkey [Strg]+[F8] verknüpft ist. Dazu enthält der icustomizer die Klasse HotKeyWatch, mit der sich beliebige anwendungsweite Hotkeys erstellen lassen. HotKey hotkeyactivatecustomizer = new HotKey("Control.F8"); HotKeyWatch.RegisterHotKey( hotkeyactivatecustomizer, Customizer.ActivateCustomizer); Beim Start des Designers wird der Urzustand der Form wiederhergestellt, der beim Anhängen des icustomizers in Customizer.Attach gespeichert wurde. Dann wird der Designer angezeigt und Form sowie Skripteditor stehen zur Bearbeitung bereit. Speichern des Customizings Nach dem Bearbeiten der Form und der Skripte wird das Customizing beim Schließen des Designers gespeichert. Wie beim Laden kann auch hier eine eigene Speicherfunktionalität verwendet werden. Der icustomizer ermittelt die Unterschiede zum Ursprungszustand und schreibt diese Differenz als XML in den Speicherstream. Das gespeicherte Customizing enthält dabei Informationen über neu hinzugefügte Controls, die Hierarchie der Controls, die geänderten Eigenschaften der Controls, den Scripting-Code sowie die Eventbindungen. Neustart der Form Anschließend wird der Designer beendet. Die vorgenommenen Änderungen und Skripte sind nun sofort aktiv. Allerdings könnte der Gesamtstatus der Form nicht mehr dem Zeitpunkt entsprechen, zu dem der Designer gestartet wurde. Zum Beispiel könnte der Benutzer den Status durch Interaktion mit der Form bereits verändert haben, bevor der Designer gestartet wurde. Versteht man den icustomizer als Verlängerung des Windows-Forms-Designers und der InitializeComponent-Methode, so könnte der Programmierer im normalen Ablauf des Ladens der Form weitere Änderungen des Status vorgenommen haben, die sich jetzt nicht in der genau richtigen Abfolge wiederholen lassen. Die Form könnte sich also insgesamt in einem inkonsistenten Zustand befinden. Daher sollte die bearbeitete Form nach dem Customizing geschlossen und wieder geöffnet werden. Praxisbeispiele Unsere Kunden und Partner nutzen die neuen Möglichkeiten des icustomizers gern und vielfältig. Sehr häufig werden Masken übersichtlicher gemacht und nicht benötigte Eingabe- oder Ausgabefelder ausgeblendet. Mit neuen Reitern werden eigene Übersichtsseiten erstellt und die Informationen von verschiedenen Stellen der Applikation aufbereitet. Mit neuen Controls werden eigene Funktionalitäten eingebaut. So wurde mit einem zusätzlichen Schnellsuchfeld das Durchsuchen von großen Tabellen erleichtert: Alle Zeilen, die mit dem dort eingegebenen Suchbegriff übereinstimmen, werden farbig markiert. Auch Browserfenster werden häufig in die Applikation integriert: Diese lassen sich aufrufen und innerhalb der Applikation bedienen. Damit werden Informationen übergeben, um Lieferanten- oder Kunden- Internetseiten (Artikel, Adressen) sofort einzublenden. Auch für Plausibilitätsprüfungen bei der Eingabe wird der icustomizer verwendet: Hier werden zum Teil komplexe Prüfungen durchgeführt und Artikelkennzeichen mit Datenbankeinträgen verglichen, bevor sie gespeichert werden. Dadurch lässt sich die Datenqualität verbessern. Alle Beispiele wurden realisiert, ohne am Programmcode der Standardanwendung irgendetwas Individuelles für einen Kunden zu entwickeln. icustomizer als Beratungswerkzeug Einige Hersteller von Standardsoftware, die den icustomizer in ihre Produkte integriert haben, nutzen ihn als Beratungswerkzeug: In der Einführungsphase werden alle Modifikationswünsche des Kunden gesammelt. Nach der Einführung bespricht man diese mit dem Kunden und gemeinsam mit ihm wird entschieden, was angepasst werden soll. So werden hauptsächlich Masken optimiert und Eingaben validiert, ohne dabei den Quellcode verändern zu müssen. Änderungen werden dabei nicht vor Ort im Kundensystem vorgenommen, sondern in Ruhe entwickelt und getestet und dann beim Kunden eingespielt. Die kundenspezifischen Anpassungen bleiben auch bei Updates funktionsfähig, können individuell gewartet werden und beeinflussen die Release-Zyklen nicht. Fazit Mit Werkzeugen wie dem icustomizer ist es möglich, Kunden und Partnern eine große Flexibilität bei der Anpassung von Standardsoftware an die eigenen Bedürfnisse zu erlauben. Gleichzeitig behält man als Hersteller die Kontrolle über den Programmcode und vereinfacht das Release- Management, weil Sonderentwicklungen außerhalb des Produkts durchgeführt werden können. [bl] [1] icustomizer, [2] Lokaler Windows Hook,