Komponente von TCustomEdit

[baba]

Moin, moin,

ich beabsichtige eine eigene Komponente von TCustomEdit abzuleiten. Dies ist nun auch nicht weiter schweer, wie komme ich aber an die
Zeichenroutine um den Rahmen zu ändern. (Ich beabsichtige einen mit gerundeten Ecken, wie bei OSX zu verwenden)

Unter Delphi setze ich hier auf:

Code: Alles auswählen

procedure TsEdit.WMNCPaint(var Message: TMessage);

Dies funktioniert unter Lazarus nicht, wird nicht aufgerufen.

Gibt es hierzu ein Beispiel? Die original-Routine von TEdit würde reichen, wo finde ich diese?

Baba.

[pluto]

In einer von meinen versuchen wurde es aufgerufen. Ich glaube da war beim TMemo, das nützt dir aber trozdem wenig, weil das Handel was zu brauchst ist nicht gesetzt in den Daten Typ.

Leider hat das TEdit meine ich auch kein Canvas. Mir ist es noch nicht gelungen das Memo Optisch zu verändern.
Geschweige denn das TEdit.

Am einfachsten währe ein eigenes zu schreiben. Das von Lazarus kann man nicht so gut anpassen. Oder du nimmst GTK2 da hast du abgerundete ecken.

[Socke]

Ein erster Ansatz wäre:

Code: Alles auswählen

uses LMessages;
{...}
procedure TsEdit.LMPaint(var Message: TLMPaint); message LMPaint;

Es gibt ein paar Unterschiede zwischen dem Delphi und Lazarus Message-System. So heißen die Messages nicht WMMessage sondern LMMessage.

MfG Socke

[pluto]

Aber das bringt einen Trotzdem nicht weiter ! Weil die hdc Variablen nicht belegt werden.

[Socke]

Aber das bringt einen Trotzdem nicht weiter ! Weil die hdc Variablen nicht belegt werden.

Mir war nur aufgefallen, dass baba als Prozedurnamen WMNCPaint und TMessage verwendet hatte. Meine erste Idee war, TLMPaint zu verwenden, da dies ja extra für's Zeichnen gedacht ist.
Aber wenn man eh keine Zeichenfläche (sei es Canvas oder DeviceContext hat) wird das mit dem Zeichnen eh schwer...

Gibt es hierzu ein Beispiel? Die original-Routine von TEdit würde reichen, wo finde ich diese?

Nach ein bisschen Nachforschung: TCustomEdit ist von TWinControl abgeleitet. Alle Controls, die ein Canvas besitzen, werden idr. von TCustomControl (von TWinControl abgeleitet) abgeleitet. Also hat TCustomEdit kein Canvas. Dieses braucht es auch nicht, da es sich selbst nicht zeichnet, das übernimmt das Widgetset (d.h. Windows, GTK, etc.). Es gibt also keine Zeichnen-Routine.
Wenn du ein Edit-Feld haben willst, dass sich selbst zeichnet, muss du es wahrscheinlich selbst schreiben (fpGUI zeichnet soviel ich weiß zwar auch alles selbst aber da wird die Klassen-Hierarchie ähnlich aussehen).

MfG Socke
P.S. mein Code-Vorschlag ist eh falsch und weder für das Interface noch für die Implementation geeignet

[pluto]

Aber wenn man eh keine Zeichenfläche (sei es Canvas oder DeviceContext hat) wird das mit dem Zeichnen eh schwer...

Das war beim TMemo der Fall vor ein paar Wochen.
Es gibt dort zwar zwei Parameter aber die sind leider nicht gesetzt bzw. Ich glaube das man damit nix anfangen kann weil die beiden ein Negativen wert haben. Sonst könnte man dort drauf zeichnen. Diesen Fehler habe ich aber auch schon hier gepostet im Forum. Bisher noch keine Antworten.(Siehe meinen BUG Thread Fehler 6 *G*)

Also hat TCustomEdit kein Canvas. Dieses braucht es auch nicht, da es sich selbst nicht zeichnet, das übernimmt das Widgetset (d.h. Windows, GTK, etc.). Es gibt also keine Zeichnen-Routine.

naja, die WinApi bzw. LinuxApi sollte das schon möglich machen.

Wenn du ein Edit-Feld haben willst, dass sich selbst zeichnet, muss du es wahrscheinlich selbst schreiben

So ein Aufwand ist das aber nun auch nicht. Für meine GUI habe ich mal eins geschrieben.
Evltl. beheben die ja noch den Fehler. Das entsprechende Event wird aber aufgerufen.

Mir war nur aufgefallen, dass baba als Prozedurnamen WMNCPaint und TMessage verwendet hatte. Meine erste Idee war, TLMPaint zu verwenden, da dies ja extra für's Zeichnen gedacht ist.

Stimmt ist mir mir gar nicht aufgefallen. Wobei einige WM_Botschaften auch unter der LCL unter Linux aufgerufen werden.
Nicht alle, aber einige.

[Christian]

Evltl. beheben die ja noch den Fehler. Das entsprechende Event wird aber aufgerufen.

Da gibts keinen Fehler. Ein Edit Feld wird komplett vom SO bzw Widgetset verwaltet, da kann man nicht drauf rummalen auch nciht mit der API.

Mir war nur aufgefallen, dass baba als Prozedurnamen WMNCPaint und TMessage verwendet hatte. Meine erste Idee war, TLMPaint zu verwenden, da dies ja extra für's Zeichnen gedacht ist.

Er wollte ja auch den Rahmen zeichenen er hat schon das richtige Event genommen WMPaint zeichnet nur auf die zeichenfläche, nicht den Rahmen.

[pluto]

Da gibts keinen Fehler. Ein Edit Feld wird komplett vom SO bzw Widgetset verwaltet, da kann man nicht drauf rummalen auch nciht mit der API.

Komisch unter Windows geht das mit der API !

[Christian]

OK, ich glaube aber kaum das man das in allen Widgetsets hinbekommt.

[pluto]

Nein das ist halt der Punkt.
Unter Windows in Delphi soll das so gehen.
Leider aber nicht unter Linux. Warum eigentlich nicht ?
währe doch ein Großer Vorteil.

[baba]

Nach ein bisschen Nachforschung: TCustomEdit ist von TWinControl abgeleitet. Alle Controls, die ein Canvas besitzen, werden idr. von TCustomControl (von TWinControl abgeleitet) abgeleitet. Also hat TCustomEdit kein Canvas. Dieses braucht es auch nicht, da es sich selbst nicht zeichnet, das übernimmt das Widgetset (d.h. Windows, GTK, etc.). Es gibt also keine Zeichnen-Routine.

... die Nutzung von Widget´s ist sicher sinnvoll um eine Plattformunabhängigkeit zu erreichen und ich habe mich schon gewundert, warum es kaum Komponenten gibt die sich mit der Optik befassen. Dieser breite 3D Rahmen, a la Win 3.1, den das Editfeld verwendet, sieht auf einem PDA sehr befremdlich aus, ganz abgesehen davon das einiges an Platz verschwendet wird, sobald mehrere Edit´s unter einander stehen.

Ich werde erst einmal die 0.9.26 abwarten und dann wohl eine eigene Edit-Komponente schreiben.

Baba.

[pluto]

Wenn du vorhast eine eigene Edit Komponente zu schreiben, mach dazu mal ein Thread auf. Dann könnten wir alle gemeinsam Punkte sammeln.

ps: Irgenwie fangen jetzt schon einige an selber Komponenten zu schreiben. währe es nicht vorteilhaft wenn man die bestehenden Komponenten irgendwie verwenden könnte/würde ? z.b. in den sie erweitert werden ?
Aber leider geht das ja genau nicht. z.b. beim TEdit oder beim TMemo.
Bei einigen Komponenten mag das gehen.

@baba
wie währe es wenn du eine eigene Klasse erstellst, den Rand abschaltest und per Canvas dann um die Komponente herum einen Rand malst ?
z.b. könnte diese Klasse von TCustomControl abgeleitet werden. Das Edit Plazierst du einfach in der Mitte.
Währe eine Notlösung. Ich hoffe du weißst was ich meine. Du könntest auch eine TShape Komponente nehmen und das TEdit darauf Packen.

[baba]

Wenn du vorhast eine eigene Edit Komponente zu schreiben, mach dazu mal ein Thread auf. Dann könnten wir alle gemeinsam Punkte sammeln.

Werde ich machen, im Moment sammele ich noch Informationen wie so etwas am besten umzusetzen ist. (Plattformunabhängig)

wie währe es wenn du eine eigene Klasse erstellst, den Rand abschaltest und per Canvas dann um die Komponente herum einen Rand malst ?
z.b. könnte diese Klasse von TCustomControl abgeleitet werden. Das Edit Plazierst du einfach in der Mitte.
Währe eine Notlösung. Ich hoffe du weißst was ich meine. Du könntest auch eine TShape Komponente nehmen und das TEdit darauf Packen.

Gute Idee! Funktioniert leider unter WinCE nicht, da dort "BorderStyle := bsNone" ignoriert wird.

Baba.

[pluto]

eider unter WinCE nicht, da dort "BorderStyle := bsNone"

das war wieder klar...

[Christian]

Die Edits in WinCE sehen nun mal so aus, genau wie alle anderen Komponenten. Komponenten selber malen ist vorsinnflutlich dabei kommen nur Augenkrebsanwendungen heraus die hinterher keiner will. So ziemlich ejdes Betriebsystem ist zur zeit skinnbar wenn ich also will das mein Desktop anders ausseh dann nehm ich keine andere Anwendung sondern einfach einen anderen Skin. Borderstyle unter WInce ist nat ein Bug und sollte im Bugtracker erfasst und behoben werden.