Komponenten variabel halten (unterschiedliche Editionen)

[RWarnecke]

Hallo zusammen,

es gibt ja mehrere Wege Komponenten auf die Form zu plazieren.

• Komponenten komplett zur Laufzeit erzeugen
• Komponenten visuell auf die Form legen und die Konfiguration im OI festelegen
• Komponenten in der Grundstruktur ohne jegliche Konfiguration im OI auf die Form legen und die Konfiguration zur Laufzeit festelegen.

Ich möchte in einem Programm mit unterschiedlichen Berechtigungen arbeiten. Das heißt zum Beispiel bei der Komponente TMainMenu, das unterschiedliche Menüpunkte oder ganze Menü aus- oder eingeblendet werden müssen. Das Beispiel zu der Komponente TMainMenu soll nur ein Beispiel sein, ich kann mir das gleiche auch noch vorstellen für TListView, TListBox u.s.w.. Es ist nicht auf eine Komponente beschränkt.
Welche der drei Möglichkeiten würdet Ihr nehmen, bezüglich Übersichtlichkeit, Wartung/Pflege und Erweiterbarkeit im Programm (im Sourcecode und/oder Designer)? Bitte auch Gründe nennen, warum Ihr die eine oder andere Möglichkeit nehmt.

Ich persönlich tendiere zu der Variante, die Komponenten komplett zur Laufzeit zu erstellen. Ich gebe zu, das macht am Anfang mehr Tipparbeit. Aber wenn ich es schön strukturiere, dann sollte ich es nachher einfacher haben Teile für die einzelnen Berechtigungen zu erweitern.

[mirage228]

Was verstehst Du unter Berechtigungen? Sowas wie "registriert" und "nicht registriert" bei Shareware Programmen?

Also wenn Du es sehr modular machst, hast Du dann z.B. ein leeres TMainMenu und füllst dies zur Laufzeit mit den entsprechenden Actions/Einträgen, die der beim Start gegebenen Berechtigung entsprechenden, damit bist Du am flexibelsten.

Eventuell reicht es Dir aber auch erstmal alle Einträge ins Menü z.B. einzutragen und diese dann "auszugrauen"/auszublenden, falls der Eintrag nicht verfügbar ist.

Viele Grüße

[RWarnecke]

Zitat:

Zitat von mirage228

Was verstehst Du unter Berechtigungen? Sowas wie "registriert" und "nicht registriert" bei Shareware Programmen?

Nein, so meinte ich es nicht. Ich habe da an Userberechtigungen gedacht, wie Admin der alles kann und User der nur lesen kann. Sowas meine ich mit Berechtigungen. Oder Personal Edition, Professional Edition, Enterprise Edition.

[mirage228]

Wenn Funktionalität komplett nur in einigen Editionen vorkommt, könntet Du diese in eine eigene BPL auslagern (diese prüft dann beim Initialisieren, ob eine korrekte Lizenz vorliegt, wie bei Delphi).

Was sich nicht so auslagern lässt würde ich erstmal komplett einbauen und dann je nach Rechten wieder sukszessive dynamisch deaktivieren/entfernen. (Habe mal gelesen, dass das Windows Startmenü das genauso macht; sprich erst alles drin und dann je nach Rechten Einträge wieder raus...)

Viele Grüße

[RWarnecke]

Zitat:

Zitat von mirage228

Wenn Funktionalität komplett nur in einigen Editionen vorkommt, könntet Du diese in eine eigene BPL auslagern (diese prüft dann beim Initialisieren, ob eine korrekte Lizenz vorliegt, wie bei Delphi).

Ok, die Funktionen kann ich auslagern, aber wie mache ich das mit den Komponenten ? Muss ich dann die Komponenten zur Laufzeit erzeugen ? Hast Du dazu Informationsmaterial, wo ich das Vorgehen nachlesen kann ?

Zitat:

Zitat von mirage228

Was sich nicht so auslagern lässt würde ich erstmal komplett einbauen und dann je nach Rechten wieder sukszessive dynamisch deaktivieren/entfernen. (Habe mal gelesen, dass das Windows Startmenü das genauso macht; sprich erst alles drin und dann je nach Rechten Einträge wieder raus...)

Dieses sukzessive dynamische deaktivieren/entfernen, wollte ich eigentlich nicht machen, weil ich doch dann wieder an der Übersichtlichkeit verliere.

[oki]

Hi,

also ich habe das mit der lizenz auch noch nicht gerafft, aber meine Meinung sollst du trotzdem haben.
Ich bevorzuge bei eigenen Komponenten die Variante mit published Member. Dafür gibt es mehrere Gründe. Das es nachher mit dem OI schön einfach geht ist nur einer der Vorteile. Hier was mich veranlasst das so für die Designzeiteinstellungen zu machen:
- einfache Bedienung über OI,
- schneller Überblick über alle wesentlichen Einstellungen zur Komponente und kein suchen im Code (am Besten noch was übersehen),
- published-Einstellungen über den OI hindern einen nicht Änderungen zur Laufzeit vorzunehmen, alles Public verhinder die Einsellung mittels OI,
- alle Einstellungen werden sofort nach dem Create wirksam, Fehler bei der Platzierung im Code werden vermieden,
- Einstellungen zu Komponenten bleiben auch nach längerer Zeit und größen Projekten übersichtlich und leicht auffindbar.

Ups, meine Frau ruft zum Abendbrot. Ich muß gehorchen :mrgreen:

Dann bis später

Gruß oki

[RWarnecke]

Zitat:

Zitat von oki

- alle Einstellungen werden sofort nach dem Create wirksam,...

Da kann ich nicht so ganz zustimmen. Das die Komponenten nach dem Create wirksam werden, kann ich so regeln, dass ich alle Komponenten erzeuge in FormCreate.

Zitat:

Zitat von oki

Fehler bei der Platzierung im Code werden vermieden,

Was meinst Du damit genau ?

Zitat:

Zitat von oki

- Einstellungen zu Komponenten bleiben auch nach längerer Zeit und größen Projekten übersichtlich und leicht auffindbar.

Da gebe ich Dir recht, aber bei einem gut strukturierten Sourcecode, sollte auch das kein Problem sein.

[oki]

Hi,

Zitat:

oki hat folgendes geschrieben:
- alle Einstellungen werden sofort nach dem Create wirksam,...
Da kann ich nicht so ganz zustimmen. Das die Komponenten nach dem Create wirksam werden, kann ich so regeln, dass ich alle Komponenten erzeuge in FormCreate.

Das meinte ich so, dass es dann immer so ist. Man muss sich halt im FormCreate nicht mer drum kümmern. Spart einfach Source und wird imho übersichtlicher. Ich code im OnCreate dann immer nur das, was wirklich zur Laufzeit gesetzt werden muss. Nicht mehr und nicht weniger. So weis ich, dass alles was im OnCreate steht wirklich absolutes Laufzeitzeugs ist. Aber grundsätzlich ist es egal, da geb ich dir recht. War auch nur mein Argument, ich habs halt so lieber.
Für andere Programmierer ist es imho übersichtlicher und die müssen nicht ständig fragen warum ich dies und jenes zur Laufzeit mache und anderes nicht. Der Umgang für andere Programmierer mit meinen Komponenten erscheint mir so auch leichter. Sie finden alle wichtigen Eigenschaften im OI und die sind dann so ziemlich selbsterklärend. Lange Beschreibungen was sie wann und wo initialisieren mussen fallen eifach flach.

Zitat:

oki hat folgendes geschrieben:
Fehler bei der Platzierung im Code werden vermieden,
Was meinst Du damit genau ?

Halt wie oben beschrieben. Dadurch dass öffentliche Eigenschaften automatisch beim creieren gesetzt werden kann nichts vergessen werden oder zum falschen Zeitpunkt initialisiert werden. Kann ich grad schlecht beschreiben. Vielleicht folgendes Beispiel. Es gibt eine Eigenschaft Active und weitere Eigenschaften, die für die Ausführung von Active notwendig sind. Alles einmal im OI eingestellt und Achtive auf True, und alles läuft.
In der Laufzeitvarialte könnte der Fehler passieren, dass jemand erst Active auf True setzt, und danach erst eine relevante Eigenschaft belegt. Dann schlägt Active fehl weil zu diesem Zeitpunkt die dazugehörige Eigenschaft noch nicht korrekt belegt ist (als Beispiel mal ein Dateipfad ??).

Zitat:

oki hat folgendes geschrieben:
- Einstellungen zu Komponenten bleiben auch nach längerer Zeit und größen Projekten übersichtlich und leicht auffindbar.
Da gebe ich Dir recht, aber bei einem gut strukturierten Sourcecode, sollte auch das kein Problem sein.

Natürlich bemühen wir uns alle ordentlich strukturierten Code zu schreiben. Aber ehrlich, gelingt uns das immer? Leider habe ich oft Projekte oder Themen auf dem Tisch die realisiert werden müssen, teilweise unter Zeitdruck, die eben nicht im Vorfeld komplett designt sind. Da ergeben sich oft Änderungen mitten im Projekt die vieles an Struktur zu nichte machen. Dann alles komplett neu zu schreiben reicht oft die Zeit nicht. Es kommt immer wieder der Verweis auf das nächste Release. "Da räumen wir dann mal richtig auf!" :stupid: Denkste!
Denk in diesem Zusammenhang auch mal daran, dass eventuell andere Programmierer deinen Code verstehen oder deine Komponenten verwenden sollen. Ich denke, mit dem OI ist dann vieles leichter.

Wie gesagt, dass ist alles nur meine bescheidene Meinung und kein Gesetz. Ich denke auch, dass es ein bewährtes Prinzip ist den OI zu verwenden. Ich kenne jedenfalls keinen Programmieren (von den Guten) die behauptet haben der OI ist blöd und sie coden soundso alle per Hand. Ne, sie benutzen den OI; schnell, einfach, übersichtlich, und sicher. Und nebenbei liefert er automatisch einen schnellen Überblick über die Eigenschaften einer Komponente und erschließt deren Funktion einfacher.

Gruß oki

[Panthrax]

Beispielvorschlag:

Delphi-Quellcode:

unit StdComps; // Standard-Komponenten

interface

type
  TMyComp = class
    { ... }
  end;

implementation

{ ... }

end.

Delphi-Quellcode:

unit ExtComps; // erweiterte oder andere Komponenten

interface

uses
  StdComps;

type
  TMyComp = class(StdComps.TMyComp)
    { ... }
  end;

implementation

{ ... }

end.

Delphi-Quellcode:

{$Define StandardVersion}
{.$Define ExtendedVersion}
program Demo;

{$AppType Console}

uses
  {$IfDef StandardVersion}StdComps{$EndIf}
  {$IfDef ExtendedVersion}ExtComps{$EndIf};

{ ... }

var
  MyComp: TMyComp;

begin
  { ... }
end.

[RWarnecke]

Ich programmiere im Moment noch alles komplett alleine. Ich wollte ja auch nicht sagen, dass der OI schlecht ist. Ich muss sagen, ich liebe den IO. So wie Du es beschrieben hast, kann man da alles schnell einfach und übersichtlich konfigurieren. Das steht für mich ausser Frage. Es geht mir hauptsächlich in dieser Diskussion darum, wege aufzuführen, wie ich Komponenten variabel halten kann.

Wenn ich unterschiedliche Versionen programmiert habe, konnte ich es bis jetzt immer mit Compilerschalter regeln. Nun möchte ich ein Programm schreiben, wo es einmal eine Personal Edition geben soll und einmal eine Professional Version geben soll. Da gibt es ja halt nun mal auch Komponenten, die mal angezeigt werden und nicht angezeigt werden müssen. Das kann ich ja nicht über Compilerschalter lösen oder ?

Edit - roter Kasten : So wie es Panthrax geschrieben hat, so habe ich es mir vorgestellt.

[oki]

Und der Compiler meckert in ExtComps nicht, dass es die Klasse TMyComp schon gibt?

Ich dachte, dass mit den Compilerschaltern wäre klar.
Was hält dich davon ab alles in der Komponente zu deklarieren.

Delphi-Quellcode:

type
  TMyComp = class
    { ... }
  published
    {$IfDef StandardVersion}
    property StdProp1 ...
    property StdProp2 ...
    {$EndIf}
    {$IfDef ExtendedVersion}
    property ExtProp ...
    {$EndIf}
  end;

Ich hatte deine Frage erst so verstanden, dass du fragst was wir davon halten, ob die Eigenschaften einer Komponente in den published oder public Teil sollten.

Gruß oki

[RWarnecke]

Nein, es geht darum, wie ich bestehende Komponenten dementsprechend einsetze. Ich habe bis jetzt noch keine eigene Komponente entwickelt. Deshalb ist die Grundidee, so wie es Panthrax geschrieben hat.

[oki]

ok, dann habe ich das verstanden. Das man eine Klasse definieren kann, bei der die abgeleitete Klasse den gleichen Bezeichner hat wie sein Vorfahre ist mir aber neu. Ich dachte, da mault der Compiler.

Gruß oki

[DeddyH]

Wieso sollte der Compiler maulen, das sind ja unterschiedliche Namespaces.

[oki]

Zitat:

Zitat von DeddyH

Wieso sollte der Compiler maulen, das sind ja unterschiedliche Namespaces.

Das stimmt :gruebel:

Solange man die Klassen nicht registrieren muss sollte das dann funzen. Ich dachte immer, das würde so Probleme geben. Aber wenn Delphi das auf Grund des Namespace (andere Unit) durchgehen läßt solls mir recht sein.

Gruß oki

[RWarnecke]

Gibt es noch andere Möglichkeiten ? Oder gibt es noch etwas schlechtes oder auch gutes an den bereits vorgestellten Möglichkeiten ?

[markus5766h]

Hallo, beschränken sich die verschiedenen Berechtigungen auf die Verwendung einer Komponente
oder auf den Zugriff auf verschiedene Funktionen der Komponente ?
bsp. ListView, ListView.SubItems ...