Verschiedene Kundenversionen in einem Programm pflegen??!

[hanspeter]

Zitat:

Zitat von franktron

DLLs geht auch mit MDI man kann alles machen damit genau wie mit BPL, einzigster nachteil die DLLs sind recht gross weil alles in jeder DLL ist. der Grosse Vorteil ist es ist einfach man muss nicht gucken das alle Delphi BPLs da sind die man braucht und man hat alles getrennt.

Das ist der Grund, warum ich möglichst BPL vermeiden will.
Wie habt Ihr MDI aus Dll in den Griff bekommen?

Gruß Peter

[dfried]

Zitat:

Zitat von franktron

DLLs geht auch mit MDI man kann alles machen damit genau wie mit BPL, einzigster nachteil die DLLs sind recht gross weil alles in jeder DLL ist. der Grosse Vorteil ist es ist einfach man muss nicht gucken das alle Delphi BPLs da sind die man braucht und man hat alles getrennt.

Na, dann schick mir mal ein bisschen Beispielcode wie du das "Tabulator-Taste-Problem" sinnvoll gelöst hast?
Wir (und andere...) haben bisher keine vernünftige Lösung hierfür gefunden.
Mit Delphi 4 ging das noch wunderbar :-)

[kalmi01]

Moin, moin,

wir machen es schon seit sehr langer Zeit so, dass die Funktionen in einem allgemeinem Programm abgehandelt werden.
Alles, was kundenspez. sein könnte liegt in Scripten.
Je nach dem, an welcher Stelle sich das Prog. befindet, lädt es Script a, b, c, usw.
Auf diese Weise kann man auch ohne Compiler direkt vor Ort schnell etwas anpassen.

Wenn das richtig durchdacht ist, hat man nur wenige Scripts und je Kunden nur 1 kundenspez. Script.

[Jelly]

Skripte unter Delphi :gruebel:

BPL's sind im Prinzip wesentlich leichter zu handhaben unter Delphi, allerdings funktionieren die nur bei Programmen die mit gleicher Delphi Version erstellt werden... DLL's sind da unabhängiger.

[kalmi01]

Zitat:

Skripte unter Delphi :gruebel:

==> DelphiWebScriptII

[Jelly]

Ob das aber noch alles performant ist ?

[franktron]

Zitat:

Zitat von hanspeter

Zitat:

Zitat von franktron

DLLs geht auch mit MDI man kann alles machen damit genau wie mit BPL, einzigster nachteil die DLLs sind recht gross weil alles in jeder DLL ist. der Grosse Vorteil ist es ist einfach man muss nicht gucken das alle Delphi BPLs da sind die man braucht und man hat alles getrennt.

Das ist der Grund, warum ich möglichst BPL vermeiden will.
Wie habt Ihr MDI aus Dll in den Griff bekommen?

Gruß Peter

Hab das DLL Demo von Luckie genommen und dann auf meine bedürfnisse angepasst.

Und für das String problem habe ich FastMM4 benutzt

[ken_jones]

Wir verwenden ebenfalls so eine Art Script. D.h. unsere Lösung basiert auf Oracle und wir versuchen so viel wie nur möglich als PL/SQL zu implementieren.
Somit ruft Delphi die PL/SQL Skripte auf um die DB zu Ändern oder Resultate zu bekommen, etc.
Gleichzeitig sind alle SQLs in der DB. Somit können die meisten Änderungen vor Ort ohne Compilieren gemacht werden.

Die Formulare selbst werden über einen VisualConfigurator (leider Copyright unserer Firma) geändert. Es gibt aber Komponenten die Freeware sind und fast dasselbe können. Dort kann der Kunde zur Laufzeit das Formular ändern. D.h. er kann Felder verstecken, verschieben, umbenennen, etc. Kolonnen in Tabellen verschieben, vergrössern, etc.pp. Die Änderungen werden wiederum in der DB gespeichert.
Viele Formulare haben auch eine Tabcontrol drauf. Auf diesen Tabs können verschiedene Möglichkeiten der Erfassung drauf sein (Detailiert, Schnellerfassung, Änderungen,...) oder zusätzliche Funktionen (Tab1: Erfassung, Tab2: Details, Tab3: Replikation...). Durch DB Einträge wird gesteuert, welche(s) Tab(s) angezeigt werden sollen, pro Mandant, Kunde, Gruppe, etc.

Sämtliche Kundenänderungen in der DB werden mit einem "Individualisierungsflag" gekennzeichnet. D.h. wenn wir einen Major Update fahren, so werden alle nicht gekennzeichneten Prozeduren, PL/SQLs, etc. geupdated. Einziges Problem: Wenn das Update eine Änderung in einem SQL erzwingt, welches vom Kunden individualisiert wurde. Dann muss derjenige, der die Individualisierung vorgenommen hat, sich um das manuelle Updaten kümmern.

Das ganze Projekt ist in hunderte von DLLs aufgeteilt. (ERP Lösung, daher...)
Es ist bei über 800 KMUs im Einsatz und wir können das ganze super verwalten. Und durch die starke Auslagerung aller Funktionen in PL/SQL können wir das ganze Projekt viel einfacher mal in eine andere Sprache umsetzen.

Es gibt kein einziges Modul, welches in 2 Versionen (für Kunde A / Kunde B) daherkommt. Nur Module die speziell für einen Kunden geschrieben sind (Funktionen die NUR dieser Kunde braucht).
Sobald die Funktion für einen anderen Kunden auch interessant wird, gehts in den Standard über.

[dfried]

Zitat:

Zitat von franktron

Hab das DLL Demo von Luckie genommen und dann auf meine bedürfnisse angepasst.
Und für das String problem habe ich FastMM4 benutzt

Und die PlugIns sind dann auch MDI-Childs oder werden die modal aufgerufen?

[franktron]

Zitat:

Zitat von dfried

Zitat:

Zitat von franktron

Hab das DLL Demo von Luckie genommen und dann auf meine bedürfnisse angepasst.
Und für das String problem habe ich FastMM4 benutzt

Und die PlugIns sind dann auch MDI-Childs oder werden die modal aufgerufen?

Eigentlich beides habe eben Dialoge und MDI Childs (meist MDI Childs)