Generic Manipulator Tool

Hi!

Da mein Tool sich langsam auf einen brauchbaren Stand zubewegt, werde ich es hier mal kurz vorstellen.

Anlass
Wer kennt das nicht? Man hat eine Menge an Dateien (Bilder, Musik, etc.) und ärgert sich über schlechte Dateinamen oder kaputte Meta-Tags.
Tools die genau das tun, was man möchte, gibt es natürlich wieder nicht und alle Dateien per Hand zu ändern ist ab 50 aufwärts sicherlich auch keine Option.
Also fing ich an ein Tool mit dem Augenmerk auf Funktionalität, Flexibilität und grafischer Oberfläche zur einfachen Benutzung zu schreiben.

Idee
Das Tool sollte, um hohe Flexibilität und einfache Erweiterbarkeit zu garantieren, auf einer Plugin-Architektur basieren.
Eine grafische Benutzeroberfläche sollte die Bedienung erleichtern und das Programm auch für Laien nutzbar machen.
Es musste Batch-Processing unterstützen, um viele Dateien nacheinander ohne Mühe zu bearbeiten.

Zur Manipulation von Daten sollten die Plugins beliebig miteinander verknüpfbar sein.
Dazu verwende ich ein Port-Konzept, bei dem jedes Plugin mehrere (oder keine) Eingabe- und Ausgabe-Ports hat. Diese können miteinander verbunden werden, sodass komplexe Zyklen machbar sind.

Generic Manipulator (GM)
Da das Tool über Plugins mit vielerlei Arten von Dateien umgehen und diese manipulieren können sollte, habe ich es "Generic Manipulator" getauft.
GM unterscheidet zwischen zwei Plugin-Typen: DataProvider- und Filter-Plugins.
Erstere bieten Zugriff auf Daten aus Dateien (Tag-Daten von Musik-Dateien, Dateiname, usw.). Sie stellen Lese- und Schreibzugriff zur Verfügung.
Letztere manipulieren Daten - filtern sie (Splitten, Abschneiden, Zusammenfügen, usw.).

Bedienung
Nach dem Programmstart werden die Plugins aus dem gleichnamigen Ordner geladen und dann kanns auch schon losgehen.

Im rechten Bereich der Oberfläche wählt man im Tab-Control die gewünschte Plugin-Rubrik (DataProvider oder Filter) aus und zieht das gewünschte Plugin einfach per Drag & Drop auf die Arbeitsfläche auf der linken Seite.
Die Position eines Plugin-Panels kann über einfaches Verschieben (halten der linken Maustaste und verschieben des Mauszeigers) geändert werden.

Die roten Kästchen der Plugins sind die Ports. Fährt man mit der Maus über sie, erscheint ein ToolTip-Text mit einer Beschreibung des Ports. Per Drag & Drop können die Ports miteinander verbunden werden.
Mit einem Doppelklick auf einen verbundenen Port wird die Verbindung entfernt.

Über einen Rechtsklick auf ein Plugin erreicht man ein Kontext-Menü. Mit diesem kann man das Plugin konfigurieren, es löschen, die Position fixieren oder sich Informationen über das Plugin anzeigen lassen.
Alternativ ist die Konfiguration auch über einen Doppelklick auf das Plugin-Panel oder den Knopf mit dem Zahnrad möglich.

Die Toolbar und das Menü sollten selbsterklärend sein.

Im Debug-Modus werden keine Änderungen an der Datei vorgenommen. Fährt man nun mit der Maus über einen Port, werden dessen Daten angezeigt.
Auf diese Weise lässt sich überprüfen, ob der Zyklus auch das macht, was er soll.

Standard-Funktionalität
Erstellte Zyklen können gespeichert und zur erneuten Verwendung geladen werden.
Undo- und Redo-Operationen stehen im Edit-Menü zur Verfügung.
Plugins können zur Laufzeit aus dem Verzeichnis entfernt oder hinzugefügt werden. Bei der Entfernung von Plugins werden allerdings auch alle aktuellen Instanzen und deren Panels entfernt.

Bild
Auf dem Bild ist ein etwas komplexerer Zyklus zu sehen, den ich verwendet habe, um die Tag-Informationen von OGG-Files zu korrigieren.
Als Basis nehme ich Datei-Informationen (Filename-Provider): Dateiname und Verzeichnis.
Ausgabe erfolgt in einen MusicTag-Provider (v.l.n.r. Artist, Title, Album, Year, Track).
Das Format der Dateinamen ist "2002 - Album Name\01 Erster Track.ogg".

Der Artist ist immer gleich und wird mit einem statischen Text hinzugefügt.
Vom Dateinamen wird die Endung und die Tracknummer abgeschnitten (Truncate) und als Titel gesetzt.
Der Dateiname wird auch am Leerzeichen gesplittet und der erste Teil als Tracknummer verwendet.
Das Verzeichnis wird zum einen um die Jahreszahl beschnitten und der Rest dann als Album in das Ausgabe-Plugin geleitet.
Zum anderen wird wieder am Leerzeichen gesplittet und der erste Teil als Jahr gesetzt.

Da ein Port immer nur mit einem anderen Port verbunden sein kann, werden MultiOut-Filter verwendet, die die Eingabe auf mehrere Ausgänge verteilen.

Mfg NeuroCoder

Technik
Vielleicht kurz ein bißchen was zur Technik.
Jedes Plugin wird in eine eigene AppDomain geladen und implementiert ein fest definiertes Interface.
Über einen FileSystemWatcher wir das Entfernen oder Hinzufügen von Plugins erkannt und direkt umgesetzt (Laden / Entladen).
Es können mehrere Plugins in einer DLL sein, was ich aber zur besseren Austauschbarkeit bei meinen Plugins nicht angewendet habe.

Jedes Plugin wird einmal instanziert und dann bei Verwendung in einem Panel geklont.
Das Panel dient als Frontend für die Plugin-Funktionen.

Undo- und Redo-Funktionalität ist über das Command-Pattern gelöst. Das System ist nach dem Vorbild von herbivores Post aufgebaut.

Verschiedenes
Beim Laden eines Filters wird die Verfügbarkeit der verwendeten Plugins (inklusive Versions-Kompatibilität) geprüft.

Vor jedem Lauf (Debug oder Single-/Batch-Process) wird der Zyklus auf zirkuläre Verweise geprüft, um Endlosschleifen und Stack-Overflows zu vermeiden.

Bekannte Probleme*Das Ausführen eines Zyklus ist noch unoptimiert und daher nicht besonders schnell / performant. *Das Filename-Plugin ist in der Ausgabe (Verschieben und Umbenennen) noch nicht getestet *Einige Fehlerbehandlungs-Routinen sind noch nicht eingebaut, sodass nicht gefangene Exceptions mitunter auftreten können.

Haftungsausschluss
Ich biete hier das Tool in einer frühen Stadium zum Download an.

DIE SOFTWARE WIRD OHNE JEDE SPEZIELLE ODER IMPLIZIERTE GARANTIE
VERGEBEN, DIES SCHLIESST DIE GARANTIE ZUR BENUTZUNG FÜR EINEN
BESTIMMTEN ZWECK UND RECHTSVERLETZUNG EIN, IST ABER NICHT
DARAUF BESCHRÄNKT. AUF KEINEN FALL SIND DIE AUTOREN ODER
COPYRIGHTINHABER FÜR JEGLICHEN SCHADEN VERANTWORTLICH, OB IN
EINEM VERTRAG, DELIKT ODER ANDERS, WELCHER DURCH DIE
BENUTZUNG DER SOFTWARE ENTSTEHT.

Source Code
Der Code der letzten / aktuellesten Version befindet sich weiter unten im Anhang:
Post mit Source
Das Projekt ist unter einer BSD-Style-Lizenz veröffentlicht.

Bei produktivem Einsatz, Weiterentwicklung oder Ähnlichem würde ich mich aus reinem Interesse sehr über eine PN oder E-Mail freuen.

Der Code ist qualitativ nicht in einer Form, in der ich ihn gerne veröffentliche. Er hat viel Refactoring nötig und ist an einigen Stellen nicht besonders elegant. Aus Zeitmangel war es mir jedoch nicht möglich, ihn in eine brauchbare Form zu bringen, obwohl dieses Vorhaben schon seit etwa 3 Jahren besteht. Interessenten mögen an dieser Stelle ein Nachsehen mit mir haben.

Mfg NeuroCoder

Version vom 13.08.2007 im Anhang

Hallo NeuroCoder,

die Idee und die Umsetzung sind ausgesprochen interessant!

Wenn ich es richtig verstehe, hast du ein Tool zur grafischen Programmierung geschaffen. Die Programme, die man damit schreiben kann, dienen der Manipulationen von Datei-Meta-Informationen.

Die Plugins bilden die Bausteine (oder wenn mal es textuell stehen will) die Statements, aus denen man das Programm aufbaut.

Man könnte neue Plugins schreiben, aber in Normalfall wird man mit den vorhandenen auskommen. Was ein Plugin genau tuen soll, legt man über seine Konfiguration fest.

Alles richtig?

Ich freue mich, dass du dieses Tool zur Verfügung stellst.

herbivore

Ich finde das Projekt auch sehr interessant, mir gefällt die Idee sehr gut, dass man für die Manipulation einen grafischen Workflow erzeugen kann.

Eine Frage: Wenn mir diese Plugins auch Lesezugriff bieten, kann ich dann auch abhängig von bestimmten Werten den Workflow verzweigen? Ich meine eine Art grafisches IF.

Hi!

Vielen Dank für das positive Feedback!

@marco.b: Ein If-Plugin wäre denkbar und auch nicht schwer umzusetzen. Tatsächlich habe ich auch schon an ein solches Plugin gedacht.
Ich könnte mir da einen Aufbau mit 3 Eingängen (Quelle A, Quelle B, Steuerung [klingt mehr nach einem Multiplexer]) und einem Ausgang vorstellen, oder zwei Eingängen (Quelle und Steuerung) und zwei Ausgängen.
Je nach Quelle würde dann der entsprechende Eingang durchgeschleift oder der entsprechende Ausgang versorgt.
Das MultiIn-Plugin macht schon so etwas ähnliches: Es schleift das Signal des ersten nicht leeren Eingangs durch. Das könnte dann am Ende von einer Verzweigung quasi als "End If" stehen.

Die Idee ist auf jedenfall gut. Ich denke, ich werde ein If-Package mit mehreren Plugins in einer DLL bauen.

@herbivore: So habe ich das noch gar nicht betrachtet 😄.
Im Grunde liegst du schon richtig, wobei ich nicht weiß, ob du das mit den Plugins richtig verstanden hast.
Die bis jetzt vorhandenen Plugins sind erst eine einfache Basis. Es fehlen allerdings noch interessante Funktionen, wie z.B. der von marco.b angesprochene If-Mechanismus, oder ein einfaches RegEx-Plugin.
Dank Plugin-Architektur ist es aber ja kein Problem diese einfach einzeln nachzuliefern.

Die Plugins haben jeweils eine Basis-Funktionalität (zumindest meine): Das Truncate Plugin kann nur Text be- oder abschneiden. Das Replace-Plugin kann nur Text durch anderen ersetzen und das StaticText-Plugin kann nur vorher festgelegten Text ausgeben.
Die Konfiguration wäre in dem Fall dem Truncate Plugin zu sagen, dass es vorne und hinten Leerzeichen und zusätzlich die ersten beiden Zeichen abtrennen soll, oder dem Replace-Plugin zu sagen, dass es alle "_" mit " " ersetzen soll.

Durch die Plugins sind noch ganz andere Anwendungen denkbar. Ein MusicList-Plugin könnte mit den Eingaben eine HTML-Musikliste generieren. Das Filename-Plugin kann Dateien auch verschieben und umbenennen, indem man andere Pfade angibt oder den Dateinamen ändert.
Ein Datenbank-Plugin könnte Datensätze aus einer Datenbank von dem Tool manipulieren lassen (das sollte man aber besser per SQL erledigen 😄).
Es sind also noch viele Möglichkeiten denkbar.

Leider ist die gepackte Datei mit 347 kB groß und damit zu groß, um hier gespeichert zu werden. Deshalb musste ich sie auf meinen eigenen Webspace laden.

Auf Wunsch kann ich in nächster Zeit den Quellcode zum Download anbieten oder zumindest das Plugin-Interface offenlegen, damit man seine eigenen Plugins schreiben kann.

Mfg NeuroCoder

Theoretisch wäre es mir dann auch möglich, hunderte von Musikdateien anhand von Genres oder Interpreten in einzelne Ordner zu sortieren, oder? Und automatisiert HTML Indexdateien für jeden Ordner zu speichern, wie du das schon angeführt hast. Das ist wirklich eine Art grafisches Scripting, und du hast einen der wenigen Fälle gefunden wo das meiner Meinung nach auch Sinn macht.

Inwiefern wird es möglich sein, eigene Plugins zu schreiben? Falls es überhaupt möglich sein soll.

Hi!

Wenn alle Plugins korrekt funktionieren, sollte das kein Problem sein.
Das HTML-Index-Plugin gibts allerdings (noch?) nicht (das könntest du ja dann ändern 😉).

Eigene Plugins sollten kein Problem darstellen:
Es gibt eine PluginBase-DLL die alle Interfaces (3 an der Zahl: IPlugin, IDataProviderPlugin, IFilterPlugin) enthält und von jedem Plugin-Projekt referenziert wird.
Je nachdem was für ein Plugin du schreiben möchtest, implementierst du das entsprechende Interface (IDataProviderPlugin oder IFilterPlugin). Zusätzlich musst du von MarshalByRefObject ableiten (das ist notwendig, weil jedes Plugin in eine eigene AppDomain geladen wird).
Wenn du möchtest, kann ich den Source der PluginBase und eines Plugins als Beispiel posten.
Auf Wunsch würde ich auch über einen Release des gesamten Sources unter einer Lizenz (da muss ich mir noch Gedanken machen) nachdenken.

Wichtig
Ich möchte hier allerdings nochmal betonen, dass sich das Projekt keineswegs im Endstadium befindet und dies hier mehr oder weniger eine Alpha- oder PreAlpha-Version darstellt.
Daher bin ich für Feedback und Bug-Reports sehr dankbar. Das Filename-Plugin ist zum Beispiel bezüglich dem Verschieben und Umbenennen noch nicht ausreichend getestet.

Mfg NeuroCoder

Hallo NeuroCoder,

das eine Plugin-Architektur es immer ermöglicht neue Plugins zu schreiben ist mit genauso klar wie, dass noch nicht alle grundlegenden Plugins erstellt wurden, wo du ja noch in der Entwicklung steckt.

Aber ich sehe einen qualitativen Unterschied in der grafischen Programmierung und der Plugin-Programmierung.

So wie es in C# eine begrenzte Anzahl von Schlüsselworten gibt, mit denen man beliebige C#-Programm erstellen kann, sollte es in meinen Augen eine begrenzte Anzahl von Plugins geben, mit denen man "alle" grafische Programme schreiben kann.

So wie es im Vergleich zur normalen C#-Programmierung Spezialkenntnisse erfordert, um C# um weitere Schlüsselworte zu erweitern, benötigt es im Vergleich zur grafischen Programmierung Spezialkenntnisse, um die grafische Programmiersprache um weitere Plugins zu erweitern.

Ich will darauf hinaus, dass die Menge der Personen, die in der Lage sind grafische Programme zu "malen", weit ist größer als die Menge der Personen, die in der Lage sind, mit C# Plugins zu schreiben.

Ich finde den grafischen Ansatz gut und interessant, aber er stützt in sich zusammen, wenn es (zu oft) notwendig wird, eigene Plugins zu erstellen, weil dann viele potentielle Benutzer ausgesperrt werden.

Natürlich heißt das immer noch nicht, dass du alle Plugins selber schreiben musst, aber es muss eine möglichst zentrale Quelle für Plugins geben und die Plugins sollten alle möglichst benutzungskonform sein, damit die größere Gruppe der grafischen Programmierer mit deinem Tool arbeiten können, ohne Plugins erstellen zu müssen.

Das meinte ich mit:

Man könnte neue Plugins schreiben, aber in Normalfall wird man mit den vorhandenen auskommen.

Leider ist die gepackte Datei mit 347 kB groß und damit zu groß, um hier gespeichert zu werden.

Ich habe die aktuelle Version an dein zweiten Beitrag von oben angehängt. Schick mir einfach eine PM, wenn sich die Version entscheidend geändert hat. Dann kann ich den Anhang durch die neue Version ersetzen.

herbivore

Hallo herbivore!

Dann habe ich dich in deinem ersten Post leider falsch verstanden, Sorry.
In der Tat hatte ich es so gedacht, wie du es im letzten Post gesagt hast. Nach Möglichkeit sollte man mit der Plugin-Library am Ende auskommen und fehlende Funktionalität durch Kombination von mehreren Plugins kompensieren können.

In Spezialfällen kann es natürlich sein, dass man ein Plugin selbst schreiben muss. Das sollte aber wirklich die Ausnahme bleiben.
Ich möchte also den Fokus auf die "grafische Programmierung" legen, da das Tool ja auch mit dem Hintergedanken an Laien ohne Programmierkenntnisse gedacht war.

Ich würde vorschlagen - wenn seitens der Administration nichts dagegen spricht - die Plugins in diesem Thread der Konsistenz halber zu sammeln.

Da das Projekt offenbar ein gewisses Potential besitzt, werde ich bei Gelegenheit eine eigene Projektseite erstellen.
Außerdem werde ich die PluginBase und Beispiel-Plugins hier posten, damit auch andere Mitglieder Plugins entwickeln können.

Mfg NeuroCoder

PS: Danke fürs hochladen, herbivore!

Hallo NeuroCoder!

Gute Idee! Leider ist mir dein Programm beim Ausführen eines Zyklus bisher immer abgestürzt und Windows Vista zeigt da auch keine genaueren Fehlerdetails an. (Hab Anwendung mit Administratorrechten gestartet)

Du könntest ja eine kleine Website basteln und mit diesem Snippet ein Installieren von Plugins aus der Website heraus möglich machen.

vg,
Simon

Hallo NeuroCoder,

In der Tat hatte ich es so gedacht, wie du es im letzten Post gesagt hast.

fein, dann sind wir uns ja einig.

Außerdem werde ich die PluginBase und Beispiel-Plugins hier posten, damit auch andere Mitglieder Plugins entwickeln können.

Das kannst du gerne machen.

Ich würde vorschlagen - wenn seitens der Administration nichts dagegen spricht - die Plugins in diesem Thread der Konsistenz halber zu sammeln.

Es spricht nichts dagegen und einiges dafür.

Ich fände es noch sehr wichtig, dass die Plugins die wesentlichen Einstellungen ihrer Konfiguration anzeigen, also z.B. StaticText-Plugin den Text, den es liefert und beim Replace-Plugin den Such- und den Ersetzungstext. Damit werden die grafischen Programme m.E. wesentlich übersichtlicher und leichter zu verstehen.

herbivore

Hi!

Okay, es gibt ein Update!

Changes
*Fixed: Filename-Plugin etwas Crash-sicherer gemacht *Fixed: Locked-Attribut der PluginPanels wird mitgespeichert (alte Filter immer noch ladbar) *Fixed: Icons der Plugins im ListView verschieben sich bei Online-Entfernung eines Plugins *Added: Filter Plugins zeigen ihre Konfiguration auf ihrem Panel an (Danke, herbivore!) *Added: Boolean Plugins (Ifs, StaticBoolean, And, Or, Not, Boolean Compare) *Added: StringCompare Plugin *Added: Zwei Beispiel Filter

Beispiele

MusicTag.filter:
Setzt Tag Informationen für Dateien mit dem Dateinamen: "2007 - Album\01 Erster Song.mp3".
Der Artist ist fest durch einen StaticText vorgegeben.

GreaterString.filter:
Wählt von zwei Strings den längeren (oder kürzeren, je nach Vergleichs-Operator) aus.
Das neue StringCompare-Plugin kann den ganzen Zyklus ersetzen.

Download oben

Mfg NeuroCoder

Hi!

Update Nummer 2:

Changes*Plugin-Interfaces leicht verändert *Grundlage für einen Update-Mechanismus geschaffen

Plugin SDK

Wie weiter oben angekündigt, gibt es jetzt ein kleines SDK zur Entwicklung von Plugins.

Inhalt:
ConcatFilterPlugin - Der Code des ConcatFilter-Plugins (verbindet alle Eingänge unter Verwendung eines Trennzeichens miteinander)

FilenameDataProviderPlugin - Der Code des FilenameDataProvider-Plugins (stellt den Dateinamen, Extension, übergeordnetes Verzeichnis und den vollen Pfad zur Verfügung und kann die Datei je nach Ausgabe umbennen oder verschieben)

PluginBase - Die PluginBase Assembly zur Referenzierung

PluginBase Source - Der Code der PluginBase (Nicht verändern, sonst können Plugins die die veränderte Version der Assembly referenzieren nicht mehr geladen werden!)

Anmerkungen:
Der Code ist relativ ausführlich kommentiert und die Bezeichner sollten alle suggestiv gewählt sein.
Die Properties IconImage und BackgroundImage geben beide ein serialisiertes Image zurück. Dies kann über den TransferHelper einfach durchgeführt werden (siehe dazu die Beispiel Plugins).

Die Beispiel-Plugins sind absichtlich sehr unterschiedlich gewählt (FilenameProvider ist z.B. nicht konfigurierbar), sodass für jede Möglichkeit ein Beispiel zu finden sein sollte.

Neues Plugin:
Für ein neues Filter-Plugin leitet man am besten von PluginBase.BasicFilterPlugin ab und implementiert / überschreibt die notwendigen Methoden und Properties.
Analog für ein DataProvider-Plugin von PluginBase.BasicDataProviderPlugin ableiten.

Die Assembly mit dem neuen Plugin muss "Neues.Plugin.dll" heißen, sonst wird sie vom Hauptprogramm nicht geladen. "Neues" ist dabei der Name des Plugins, der beliebig gewählt werden kann. Das Suffix ".Plugin" dient als erster Filter für Plugin-DLLs.

Neue Plugins bitte in diesem Thread posten.

ACHTUNG: Das Plugin-Interface wird sich zum nächsten Release erheblich verändern, sodass es keinen Sinn macht mit diesem SDK Plugins zu entwickeln!

[EDIT]Anm.: Das neue, stabile SDK gibt weiter unten.[/EDIT]

Mfg NeuroCoder

Hi,
hab mir das ganze mal runtergeladen, weil ich die Idee doch recht interessant fand. Hab beim spielen noch ein Fehler entdeckt. Beim Truncate-Filter, die Eigenschaften. Wenn ich in Test etwas eingebe, kommt folgende Meldung (Siehe Bild)

Informationen über das Aufrufen von JIT-Debuggen
anstelle dieses Dialogfelds finden Sie am Ende dieser Meldung.

************** Ausnahmetext **************
System.ArgumentOutOfRangeException: startIndex darf nicht länger als die Länge der Zeichenfolge sein.
Parametername: startIndex
bei System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
bei TruncateFilterPlugin.ConfigForm.UpdateSample()
bei TruncateFilterPlugin.ConfigForm.textBoxTest_TextChanged(Object sender, EventArgs e)
bei System.Windows.Forms.Control.OnTextChanged(EventArgs e)
bei System.Windows.Forms.TextBoxBase.OnTextChanged(EventArgs e)
bei System.Windows.Forms.TextBoxBase.WmReflectCommand(Message& m)
bei System.Windows.Forms.TextBoxBase.WndProc(Message& m)
bei System.Windows.Forms.TextBox.WndProc(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Hi!

Zum nächsten anstehenden Release in der kommenden Woche habe ich dieses kleine Preview für Euch:

Neue Features und Updates*Stark verbessertes Plugin-Interface *Unterstützung von Lokalisierung *Online Konfiguration in eigenem Konfigurations-Panel *Schreiben von Plugins erheblich erleichtert (z.B. Automatische Konfiguration über Attribute) *Mehr Einstellungsmöglichkeiten *Stark erhöhte Exception-Sicherheit mit Infos für den Plugin-Entwickler *Komfortablere und informativere UI *Dateiformat aktualisiert (alte Dateien nicht mehr ladbar)

Die nächste Version kommt in den nächsten Tagen mit SDK.
Momentane Sprachunterstützung: Englisch, Deutsch.

Mfg NeuroCoder

Hi!

Es hat lange gedauert, aber hier ist sie - die neue Generic Manipulator Version.

Noch offene Punkte*Hilfetexte und Ähnliches für die GM-Anwendung *Bugfixing - wenn Bugs auftauchen / gemeldet werden *Icons bearbeiten (Fehler mit Alpha) *Beispiel-Filter erstellen

Den GM gibts im Anhang oben und das PluginSDK hier.

Eigene Plugins bitte in diesem Thread sammeln.

Viel Spaß,
NeuroCoder

Hallo zusammen,

Eigene Plugins bitte in diesem Thread sammeln.

ok 🙂 Hier zur Erweiterung des GMs ein kleines Plugin von mir mit den Filtern RegexReplace und RegexSplit mit deutscher und englischer Lokalisierung und inkl. Code.

herbivore

Hallo NeuroCoder,

hast Du an diesem Projekt bisher weitergearbeitet, bzw. ist es für dich in einem "Release" Stadium?

Hintergrund zu meiner Frage: wir wollen etwas ähnliches entwickeln, aber es soll als konfigurierbarer Dienst zum Datenimport/Export funktionieren. Demzufolge bin ich natürlich bei der Ideen-Findung auch auf dass hier gestoßen. Der Bizztalk ist uns zu groß (bzw. schreibt jeder schneller ein kleines Import-Programm als dass er den Bizztalk installiert) und dein Proggie hat sehr interessante Ansätze. Im Prinzip ist das einzige was noch fehlt ein aufbohren deiner Daten-Plugins (verschiedene Quellen und Ziele) und das ganze Dateiunabhängig (kann ja auch eine DB oder ein Webservice sein) und das ganze als Dienst Zeit/Ereignisgesteuert für verschiedene Abläufe zu machen.

🙂

Xynratron

Hallo Xynratron,

eventuell sind die SQL-Server Integration Services für euch geeignet.

Hallo myCSharpler,

Nach nun mehr als 3 Jahren rücke ich endlich mit dem Source raus. 😉

Der Code der letzten / aktuellsten Version befindet sich im Anhang.
Das Projekt ist unter einer BSD-Style-Lizenz veröffentlicht.

Bei produktivem Einsatz, Weiterentwicklung oder Ähnlichem würde ich mich aus reinem Interesse sehr über eine PN oder E-Mail freuen.

Der Code ist qualitativ nicht in einer Form, in der ich ihn gerne veröffentliche. Er hat viel Refactoring nötig und ist an einigen Stellen nicht besonders elegant. Aus Zeitmangel war es mir jedoch nicht möglich, ihn in eine brauchbare Form zu bringen, obwohl dieses Vorhaben schon seit etwa 3 Jahren besteht. Interessenten mögen an dieser Stelle ein Nachsehen mit mir haben.

Mfg NeuroCoder