Hallo,

kennt jemand ein vernünftiges Tutorial, in dem die Erstellung visueller WinForms-Komponenten erklärt wird? Insbesondere eine Aufstellung der möglichen Vorfahren und ihrer Methoden (und welche Methoden man überschreiben sollte) wäre interessant.

Gruß
xaromz

Meinst Du die Erstellung von eigenen visuellen Komponenten? wie hier: http://www.dsdt.info/grundlagen/ide/...ch=komponenten

Hallo,

Zitat von raffo32:

Meinst Du die Erstellung von eigenen visuellen Komponenten? wie hier: http://www.dsdt.info/grundlagen/ide/...ch=komponenten

Nein, ich meine die Erstellung von visuellen Komponenten in Delphi.Net.

Gruß
xaromz

Zitat von raffo32:

Meinst Du die Erstellung von eigenen visuellen Komponenten? wie hier: http://www.dsdt.info/grundlagen/ide/...ch=komponenten

Raffo32 hat primär gefragt, ob Du eigene Komponenten erstellen willst, nämlich in der Art, wie es in dem Link am Ende beschrieben wird.

Dafür bietet Delphi.NET folgendes Vorgehen:

• ein neues Package-Projekt anlegen: Datei > Neu > Weitere > Delphi für NET-Projekte > Package
• dazu eine Komponenten-Vorlage anlegen: Datei > Neu > Weitere > Delphi für NET-Projekte > Komponente für Windows Forms

Dies ist die Vorlage für eigene Komponenten, die zunächst direkt erzeugt werden:
type TComponent = class(System.ComponentModel.Component) Diese Vorlage kannst Du nach eigenen Vorstellungen abwandeln, z.B. von Panel abgeleitet:
type TComponent = class(System.Windows.Forms.Panel) Welche Vorfahren verwendet werden und welche Methoden überschrieben werden sollten, hängt natürlich von Deinen Vorstellungen und Wünschen ab. Dafür gelten die gleichen Regeln wie bei Delphi für Win32:

• Wähle als Vorlage in der bisherigen Komponenten-Hierarchie eine Komponente, die möglichst viele Deiner Eigenschaften und Methoden bereits berücksichtigt.
• Ändere nur das, was unbedingt zusätzlich benötigt wird.

Alternativ gibt es noch die Variante User Control, bei der vorhandene Controls kombiniert, mit neuer Funktionalität versehen und wie ein neues (eigenes) Control verwendet werden.

Ein Tutorial kenne ich nicht. Ich habe mich orientiert an: Doberenz/Gewinnus: Borland Delphi 2005 für NET, Hanser-Verlag, ISBN 3-446-40202-0, Seite 717 ff.

Ich schlage vor, Du versuchst erst einmal, mit diesen Hinweisen weiterzukommen, und danach sagst Du genauer, was für eine Komponente Du erstellen willst mit welchen Eigenschaften und Methoden.

Gruß Jürgen

Hallo,

Zitat von Jürgen Thomas:

Raffo32 hat primär gefragt, ob Du eigene Komponenten erstellen willst, nämlich in der Art, wie es in dem Link am Ende beschrieben wird.

Da ich eine visuelle Komponente erstellen will, natürlich.

Zitat von Jürgen Thomas:

Welche Vorfahren verwendet werden und welche Methoden überschrieben werden sollten, hängt natürlich von Deinen Vorstellungen und Wünschen ab. Dafür gelten die gleichen Regeln wie bei Delphi für Win32:

• Wähle als Vorlage in der bisherigen Komponenten-Hierarchie eine Komponente, die möglichst viele Deiner Eigenschaften und Methoden bereits berücksichtigt.
• Ändere nur das, was unbedingt zusätzlich benötigt wird.

Ok, dann will ich mal ausfühlricher werden: Ich möchte eine Komponente von Win32 nach .Net portieren. Die Originalkomponente ist von TCustomControl abgeleitet. In .Net habe ich Windows.Forms.Control genommen. Ist das der richtige Vorfahr?
Zu "welche Methoden ich überschreiben muss": Wenn ich weiß, welche Methoden es gibt, und was diese machen, dann weiß ich auch, welche ich überschreiben muss. Leider fehlt mir hier eine Übersicht.

Zitat von Jürgen Thomas:

Alternativ gibt es noch die Variante User Control, bei der vorhandene Controls kombiniert, mit neuer Funktionalität versehen und wie ein neues (eigenes) Control verwendet werden.

Das will ich nicht.

Zitat von Jürgen Thomas:

Ein Tutorial kenne ich nicht. Ich habe mich orientiert an: Doberenz/Gewinnus: Borland Delphi 2005 für NET, Hanser-Verlag, ISBN 3-446-40202-0, Seite 717 ff.

Habe ich mir auch durchgelesen. Leider ist dieses Kapitel das Papier nicht wert, auf dem es gedruckt ist (Vielleicht ist das für Anfänger interessant, aber wenn ich mir das Beispiel ansehe: Ein Timer und eine Methode, die Visible umschaltet ). Welche Methoden bietet mir denn Windows.Forms.Control, die ich überschrieben/anpassen kann? In der VCL kann man ja schön im QT nachsehen, aber bei .Net könnte ich nur mit Reflection arbeiten. Für die Entwicklung irgendwie nicht so toll.

Zitat von Jürgen Thomas:

Ich schlage vor, Du versuchst erst einmal, mit diesen Hinweisen weiterzukommen, und danach sagst Du genauer, was für eine Komponente Du erstellen willst mit welchen Eigenschaften und Methoden.

Ich kann Dir genau sagen, welche Komponente ich erstellen (portieren) will.

P.S. Falls es so rüber gekommen sein sollte, dass ich gerade anfangen will, Komponenten zu entwickeln, und mir die Grundlagen fehlen: Nein, ich will mein Wissen nur auf WinForms ausdehnen.

Gruß
xaromz

Oha, da hast Du Dir ja einiges vorgenommen:

Zitat von xaromz:

Ich kann Dir genau sagen, welche Komponente ich erstellen (portieren) will.

Falls es so rüber gekommen sein sollte, dass ich gerade anfangen will, Komponenten zu entwickeln, und mir die Grundlagen fehlen: Nein, ich will mein Wissen nur auf WinForms ausdehnen.

Naja, weil ich Deinen Namen hier schon bei vielen Beiträgen gelesen habe, wusste ich nicht recht, was ich mit Deiner Frage anfangen sollte, und habe deshalb soviel für Anfänger geschrieben. (In dem Fall führte natürlich mein Hinweis auf Doberenz/Gewinnus nicht weiter.)

Bei Deinen Vorkenntnissen weißt Du doch aber ziemlich gut, wie Du vorgehen musst. Dein Problem dürfte in erster Linie die hervorragende Borland-Hilfe für NET sein. Statt dessen musst Du Dich mit der .NET Framework SDK-Dokumentation befassen; als Ausgangspunkt empfehle ich System.Windows.Forms.RichTextBox.

Wenn Du Zugriff auf den Quelltext von MWKEdit hast, dann kannst Du meiner Ansicht nach wirklich so vorgehen, wie Du es von Delphi/Win her gewöhnt bist: zunächst Eigenschaften und Methoden hinzufügen.

Schwierig wird vor allem die ungewohnte Behandlung der Ereignisse werden. Ich hatte mal eine kurze Anleitung in einem DP-Beitrag eingegeben, die Khabarakh leicht geändert hatte, aber ansonsten als brauchbar bezeichnete. Leider finde ich diesen Beitrag nicht mehr; ich kann Dir - wenn gewünscht - dies zukommen lassen (öffentlich oder als PN).

Ich hoffe, ich habe jetzt etwas helfen können. Jürgen

Hallo,

Zitat von Jürgen Thomas:

Bei Deinen Vorkenntnissen weißt Du doch aber ziemlich gut, wie Du vorgehen musst. Dein Problem dürfte in erster Linie die hervorragende Borland-Hilfe für NET sein. Statt dessen musst Du Dich mit der .NET Framework SDK-Dokumentation befassen; als Ausgangspunkt empfehle ich System.Windows.Forms.RichTextBox.

Danke, das war der Denkanstoß, den ich gebraucht habe .

Zitat von Jürgen Thomas:

Wenn Du Zugriff auf den Quelltext von MWKEdit hast, dann kannst Du meiner Ansicht nach wirklich so vorgehen, wie Du es von Delphi/Win her gewöhnt bist: zunächst Eigenschaften und Methoden hinzufügen.

Nachdem ich die Komponente selbst geschrieben habe, sollte das kein Problem darstellen.

Zitat von Jürgen Thomas:

Schwierig wird vor allem die ungewohnte Behandlung der Ereignisse werden. Ich hatte mal eine kurze Anleitung in einem DP-Beitrag eingegeben, die Khabarakh leicht geändert hatte, aber ansonsten als brauchbar bezeichnete. Leider finde ich diesen Beitrag nicht mehr; ich kann Dir - wenn gewünscht - dies zukommen lassen (öffentlich oder als PN).

Was meinst Du mit "ungewohnte Behandlung"?

Zitat von Jürgen Thomas:

Ich hoffe, ich habe jetzt etwas helfen können. Jürgen

Ja, hast Du.

Gruß
xaromz

Moin xaromz
Schnappe dir einfach mal den Refletor und "surfe" durch die FCL. Das ist praktisch so als würdest du in den VCL Sourcen wühlen, nur ein wenig geordneter, weil typenbezogen.

Was Jürgen mit Events meint ist ein kleiner Kulturschock von Delphianern wenn sie es mit .Net zu tun bekommen.
In Delphi32 hieß ein event OnClick und war einfach nur eine property eines Funktionszeigers.
In .Net heißt er dann Click und ein Event ist dort ein eigener Membertyp.
Er ähnelt ener Property, doch anstatt get_/set_ haben seine Accessor die prefixe add_ und remove_.
Konsumenten deiner Klasse können also nur Delegateinstanzen hinzufügen oder ihre eigenen entfernen, aber nicht direkt den ganzen Event besetzen und somit auch nicht andere Eventhandler überschreiben.
In C# sähe das so aus:

markieren

Code:

public event DeinDelegate DeinEvent;

protected virtual void OnDeinEvent()
{
   DeinDelegate deinEvent = DeinEvent;
   if(deinEvent != null)
     deinEvent(someParameter);
}

Entgegen den Hirnies in die die MSDN Docs zu dem Thema schrieben, solltest du bei der Abfrage ob dein Event leer ist nicht das Eventfeld hernehmen.
Delegates sind immutable, d.h. wenn jemand zwischen deiner Null-Prüfung und dem Ausführen den letzten Verweis eines Handlers in einem anderen Thread entfernt, würde dein Feld null sein. Und du würdest versuchen einen null-Zeiger auszuführen.
Deshalb packe ich es immer in eine lokale Variable und prüfen die bevor ich sie ausführe.

btw: Am 25.10. ist mal wieder DP Stammtisch in M., da kannst du mich ja persönlich ausquetschen.

@xaromz
Beachte: Events sind unter NET immer Multicast-Events.

Zitat von Elvis:

Was Jürgen mit Events meint ist ein kleiner Kulturschock von Delphianern wenn sie es mit .Net zu tun bekommen.

So schön hätte ich es niemals formulieren können.

Zitat von Elvis:

Am 25.10. ist mal wieder DP Stammtisch in M.

In Berlin hätte ich liebend gern auch einen Stammtisch. Ich werde mal danach fragen.

Gruß Jürgen

Hallo,

Zitat von Elvis:

Schnappe dir einfach mal den Refletor und "surfe" durch die FCL. Das ist praktisch so als würdest du in den VCL Sourcen wühlen, nur ein wenig geordneter, weil typenbezogen.

Das wollte ich schon lange mal machen.

Zitat von Elvis:

Was Jürgen mit Events meint ist ein kleiner Kulturschock von Delphianern wenn sie es mit .Net zu tun bekommen.
In Delphi32 hieß ein event OnClick und war einfach nur eine property eines Funktionszeigers.
In .Net heißt er dann Click und ein Event ist dort ein eigener Membertyp.
Er ähnelt ener Property, doch anstatt get_/set_ haben seine Accessor die prefixe add_ und remove_.
Konsumenten deiner Klasse können also nur Delegateinstanzen hinzufügen oder ihre eigenen entfernen, aber nicht direkt den ganzen Event besetzen und somit auch nicht andere Eventhandler überschreiben.

Ach so, das ist gemeint. Das ist mir schon bekannt, aber:

Zitat von Elvis:

Entgegen den Hirnies in die die MSDN Docs zu dem Thema schrieben, solltest du bei der Abfrage ob dein Event leer ist nicht das Eventfeld hernehmen.
Delegates sind immutable, d.h. wenn jemand zwischen deiner Null-Prüfung und dem Ausführen den letzten Verweis eines Handlers in einem anderen Thread entfernt, würde dein Feld null sein. Und du würdest versuchen einen null-Zeiger auszuführen.
Deshalb packe ich es immer in eine lokale Variable und prüfen die bevor ich sie ausführe.

das ist ein guter Hinweis.

Zitat von Elvis:

btw: Am 25.10. ist mal wieder DP Stammtisch in M., da kannst du mich ja persönlich ausquetschen.

Ich werd 'ne große Zange mitbringen .

Gruß
xaromz