Item in DrawItem ändern?

[Mattze]

Hallo,

ich glaube, dass es nicht geht, aber ich frage trotzdem...

Kann man in einer Listbox den gerade zu zeichnenden Item in der DrawItem noch ändern?
(Z. Bsp. ganz einfach Listbox.items[index]:='xyz' machen.
Da der item ja bei dieser Zuweisung neu gezeichnet wird, ruft DrawItem sich immer wieder selber auf. Kann man das verhindern?)

Gruß
Mattze

[mkinzler]

Es macht auch keinen Sinn, dass so zu machen. Was hast Du den vor?

[Mattze]

Hallo Markus,

ich schreibe mir gerade eine eigene Listbox (von TCustomListbox abgeleitet), die, natürlich, etwas mehr kann.
Geht auch schon ganz gut.

Nun fiel mir ein, dass ein Ereignis OnBeforeItemDraw vielleicht nicht schlecht wäre.
Das funktioniert auch - nur eben nicht die Änderung des items selber.

Eine Anwendung wäre z. Bsp. die Auflistung von Passwörtern mit einem Stellvertreterzeichen, die dann nur im Hint oder auf Anforderung im Klartext angezeigt werden.
Oder eben eine parallele Stringlist mit anderen Strings, die in irgendeiner Abhängigkeit die originalen der Listbox bei der Anzeige ersetzen.
Also, wenn es denn ginge, würde man schon eine Anwendung dafür finden. <ggg>

Das Problem ist aber, wie gesagt, das OnBeforeItemDraw.
Da drinnen kann man fast alles machen, nur eben nicht das item verändern.
Ist verständlich! Ich würde mich auch wundern, wenn es ginge, aber fragen kann man ja mal...

Gruß
Mattze

[mkinzler]

Um das Passwort bei der Anzeige durch Sternchen o.ä. zu ersetzen musst du den Inhalt/die Items nicht ersetzen, sondern nur etwas anderes "Zeichnen".

[Sir Rufo]

Zitat:

Zitat von mkinzler (Beitrag 1263080)

Um das Passwort bei der Anzeige durch Sternchen o.ä. zu ersetzen musst du den Inhalt/die Items nicht ersetzen, sondern nur etwas anderes "Zeichnen".

:thumb:

[Mattze]

Hallo Marcus,

tolle Antwort.
Mir ist durchaus klar, dass man das mit dem Passwort anders regelt.
Aber schließlich wolltest Du ein Bsp. dafür, wozu man das verwenden KÖNNTE.

Das eigentliche Problem ist das OnBeforeItemDraw, das am Anfang von ItemDraw aufgerufen werden soll - wie gesagt.
Da kann man alles machen, nur nicht den Inhalt von Items[index] verändern. Deshalb die Frage.

Gruß
Mattze

[Sir Rufo]

Zitat:

Zitat von Mattze (Beitrag 1263083)

Hallo Marcus,

tolle Antwort.
Mir ist durchaus klar, dass man das mit dem Passwort anders regelt.
Aber schließlich wolltest Du ein Bsp. dafür, wozu man das verwenden KÖNNTE.

Das eigentliche Problem ist das OnBeforeItemDraw, das am Anfang von ItemDraw aufgerufen werden soll - wie gesagt.
Da kann man alles machen, nur nicht den Inhalt von Items[index] verändern. Deshalb die Frage.

Gruß
Mattze

Ähm nochmal, warum willst du die Daten verändern, wenn du nur die Anzeige verändern willst?

So gesehen kann in den Items stehen was will und du kannst auch beim Zeichen zeichnen was du willst. Darum versteht hier niemand, aus welchem Grund du bei der Anzeige die Daten verändern möchtest.

Es macht einfach keinen - absolut keinen - Sinn

[Mattze]

Hallo,

1. Die Frage ist nicht warum, sondern ob es überhaupt geht. Ich will es ja gar nicht machen! Es wäre halt interessant für mich. Aus rein logischen Gründen würde ich sagen, dass das gar nicht gehen kann.
2. Ich möchte gerne vermeiden, dass ich das in einigen Jahren versuche, weil ich mich nicht mehr daran erinnert habe, dass es nicht gehen kann. Und dann eine aufwendige (und sinnlose) Fehlersuche starte...

Mehr steckt da im Grunde nicht dahinter. Es ist für mich immer bloß sehr interessant, Grenzen zu finden (oder zu sehen). Manchmal kann man die dann auch gut verallgemeinern und fällt beim nächsten Mal nicht wieder auf solche "Dummheit" rein.

Gruß
Mattze

[Popov]

Sollte nicht gehen:

Delphi-Quellcode:

procedure GetFiles(Path: String; List: TStrings);
var
  Search: TSearchRec;
begin
  //Path := IncludeTrailingBackslash(Path);
  if FindFirst(Path + '*.*', faAnyFile, Search) = 0 then
  repeat
    List.Add(Path + Search.Name);
  until FindNext(Search) <> 0;
  FindClose(Search);
end;

procedure TForm1.FormCreate(Sender: TObject);
const
  Path = 'c:\';
begin
  ListBox1.Style := lbOwnerDrawFixed;
  ListBox1.Sorted := True;
  GetFiles(Path, ListBox1.Items);
end;

procedure TForm1.ListBox1DrawItem(Control: TWinControl; Index: Integer;
  Rect: TRect; State: TOwnerDrawState);
const
  PfadeVerstecken = True; //<<<<
var
  FileName: String;
begin
  with (Control as TListbox) do
  begin
    if PfadeVerstecken then
      FileName := ExtractFileName(Items[Index])
    else
      FileName := Items[Index];

    Canvas.TextRect(Rect, Rect.Left + 2, Rect.Top, FileName);

    //Items[Index] := '[Mattze] ' + FileName; //Endlos, wg. Aktualisierung
  end;
end;

ListBox1DrawItem reagiert auf Änderung, dann gibt es eine Änderung im Item, also ruft sich ListBox1DrawItem wieder auf, dann gibt es eine Änderung im Item, usw.

Den Inhalt ändern, der gezeichnet werden soll, ist ja kein Problem (siehe Beispiel).

[Sir Rufo]

Zitat:

Zitat von Mattze (Beitrag 1263086)

Hallo,

1. Die Frage ist nicht warum, sondern ob es überhaupt geht. Ich will es ja gar nicht machen! Es wäre halt interessant für mich. Aus rein logischen Gründen würde ich sagen, dass das gar nicht gehen kann.
2. Ich möchte gerne vermeiden, dass ich das in einigen Jahren versuche, weil ich mich nicht mehr daran erinnert habe, dass es nicht gehen kann. Und dann eine aufwendige (und sinnlose) Fehlersuche starte...

Mehr steckt da im Grunde nicht dahinter. Es ist für mich immer bloß sehr interessant, Grenzen zu finden (oder zu sehen). Manchmal kann man die dann auch gut verallgemeinern und fällt beim nächsten Mal nicht wieder auf solche "Dummheit" rein.

Gruß
Mattze

Denk einfach daran, dass dein Füller/Kugelschreiber auch nicht mit dir diskutiert, was du gerade im Kopf/Sinn hast ;)

[Mattze]

Hallo Popov,

genau wegen des dann eintretenden "Endlosaufrufs" von DrawItem meinte ich, dass das logischerweise nicht gehen kann.
Der Hintergrund ist, dass die Listbox automatisch bei einer Änderung des Inhaltes den entsprechenden Item neu zeichnet.
Also, sobald items[index]:='irgendwas' gemacht wird, schreibt sie die Änderung und das soll sie ja auch.

Wie gesagt, etwas anderes als den Itemtext auszugeben ist kein Problem. Mache ich ja in meiner Listview ständig.
Es wäre eben nur interessant, ob man das irgendwie hinbiegen kann.

Gruß
Mattze

PS: Richtig, Sir Rufo! Aber fragen kann man ja mal...
So wurden schon viele Sachen geklärt und oft weiß man selber gar nicht, was man eigentlich wirklich will.

[mkinzler]

.onItemDraw() ist nun mal für das Zeichnen von Einträgen (Darstellung) zuständig. Hier sollte man nichts an den Daten ändern.
Wenn Dir das Radio/Fernseher zu laut/leise ist regelst Du ja auch die Lautstärke über den Regler oder der Fernsteuerung und rufst nicht beim Sender an und verlangst, dass Sie die daten ändern sollen (Film/Musik). 8-)

[Mattze]

Hallo,

tschja, so ist das eben. Vieles ist für vieles zuständig und manches sogar für mehr als man denkt und vermuten würde.

Die Möglichkeiten muss man halt ausloten.

Gruß
Mattze

[mkinzler]

Natürlich kann man auch mit einem Teelöffel eine Tunnel durch die Alpen graben. :stupid:

[Mattze]

Eben!

Aber es gibt auch positive Beispiele.
Hat sicherlich jeder schon mal erlebt.
Man weiß nicht, wie man weiterkommt und macht und macht...
Letztendlich war es dann nur eine klitzekleine einfache Sache, von der man nie für möglich gehalten hätte, dass sie funktioniert!

Gruß
Mattze

[Popov]

Gehen, geht alles, nur wie sinnvoll ist das?

Delphi-Quellcode:

type
  TTest = class
    Text: String;
  end;

procedure AddItem(LB: TStrings; Str: String);
var
  Test: TTest;
begin
  Test := TTest.Create;
  Test.Text := Str;
  LB.AddObject('', Test);
end;

procedure ModItem(LB: TStrings; AIndex: Integer; Str: String);
begin
  if (AIndex >= 0) and (AIndex < LB.Count) then
    TTest(LB.Objects[AIndex]).Text := Str;
end;

function ItemStr(LB: TStrings; AIndex: Integer): String;
begin
  Result := TTest(LB.Objects[AIndex]).Text;
end;

procedure DelItem(LB: TStrings; AIndex: Integer);
begin
  if (AIndex >= 0) and (AIndex < LB.Count) then
    TTest(LB.Objects[AIndex]).Free;
end;

procedure GetFiles(Path: String; List: TStrings);
var
  Search: TSearchRec;
begin
  //Path := IncludeTrailingBackslash(Path);
  if FindFirst(Path + '*.*', faAnyFile, Search) = 0 then
  repeat
    AddItem(List, Path + Search.Name);
  until FindNext(Search) <> 0;
  FindClose(Search);
end;

procedure TForm1.FormCreate(Sender: TObject);
const
  Path = 'c:\';
begin
  ListBox1.Style := lbOwnerDrawFixed;
  ListBox1.Sorted := True;
  GetFiles(Path, ListBox1.Items);
end;

procedure TForm1.ListBox1DrawItem(Control: TWinControl; Index: Integer;
  Rect: TRect; State: TOwnerDrawState);
const
  PfadeVerstecken = True; //<<<<
var
  FileName: String;
begin
  with (Control as TListbox) do
  begin
    if PfadeVerstecken then
      FileName := ExtractFileName(ItemStr(Items, Index))
    else
      FileName := ItemStr(Items, Index);

    Canvas.TextRect(Rect, Rect.Left + 2, Rect.Top, FileName);

    ModItem(Items, Index, '[Mattze] ' + FileName);  //<<<<<<<<<<<<<
  end;
end;

procedure TForm1.RefreshBtnClick(Sender: TObject);
begin
  ListBox1.Refresh;
end;

Also hier kann man den Inhalt ändern, ohne Endlosschleife, weil nicht der Item-String genutzt wird, sondern der String im Objekt abgelegt ist. Dadurch merkt die ListBox nicht sofort, wenn sich der Inhalt ändert.

Trotzdem, etwas sinnvolles wird nichts draus, da bei jeder Aktualisierungs die Änderung vorgenommen wird.

[Mattze]

Hallo Popov,

das wäre tatsächlich eine ernstzunehmende Idee.
Statt über die Items, die die Listbox automatisch aktualisieren, geht man über die Objekte.
Wenn man das Drawitem von CustomListbox sowieso in seiner Komponente überschreibt, kann man das auch gleich umdrehen. Sprich: Die normalen Listeinträge (soweit möglich) als Zusatzinfos verwenden und die Objecte als die "normalen" Einträge. Wenn die geändert werden, wird Drawitem nicht automatisch aufgerufen.

Wobei...

Na ja, jedenfalls erst mal ein schönes Wochenende allen!

Gruß
Mattze

[DeddyH]

Und dann verwendet der Benutzer der Komponente ebenfalls die Objects-Eigenschadt, und alles geht den Bach runter.

[mkinzler]

Ist doch egal, Hauptsche man hat etwas geschafft, was eigentlich nicht gehen sollte, weil es keinen Sinn macht!

[himitsu]

In TTest ist ja noch Platz für ein weiteres Objects-Feld ... darf der Endanwender nur nicht vergessen, daß er jetzt wo anders suchen muß.

[DeddyH]

Und aus diesem Grund ist das in meinen Augen inakzeptabel.

[mkinzler]

In meinen Augen auch, aber das könnte auch daran liegen, dass ich kein so Genie wie Popov oder Mattze bin, sondern nur ein durchschnittlicher Programmierer, der alles an den Stellen macht, die dafür vorgesehen sind!

[Mattze]

Hallo Marcus,

ich halte mich nicht für ein Genie oder solltest Du zynischherweise das Gegenteil gemeint haben?
Gab es da nicht mal sowas wie Nettikette auf deren Einhaltung ein Moderator zu achten hat?

Entschuldige, aber ich dachte tatsächlich, man könne in diesem Forum Fragen stellen über Dinge, die man nicht weiß und die einem aufgefallen sind. Und dass das ohne Beleidigung möglich ist.

Wenn Dich etwas stört, dann antworte doch einfach nicht!

Mattze

[Perlsau]

Naja, bei völlig sinnfreien Anliegen wie dem deinen kann es schon mal geschehen, daß man was entgegnet, das den Anfänger verletzen könnte. Anders ausgedrückt: Bevor du was unterstellst, solltest du erst einmal zu klären suchen, ob dein Winken mit der Netiquette nicht vielmehr auf Einbildung beruht ...

Zitat:

Zitat von Mattze (Beitrag 1263144)

Wenn Dich etwas stört, dann antworte doch einfach nicht!

Ist dir vielleicht aufgefallen, daß ausnahmslos alle Antworter dir die Sinnlosigkeit deines Vorhabens bescheinigt haben? Vielleicht sollte man auf deine Fragen besser gar nicht mehr antworten?

[EWeiss]

Zitat:

Zitat von mkinzler (Beitrag 1263142)

In meinen Augen auch, aber das könnte auch daran liegen, dass ich kein so Genie wie Popov oder Mattze bin, sondern nur ein durchschnittlicher Programmierer, der alles an den Stellen macht, die dafür vorgesehen sind!

Nehme niemand in Schutz desto trotz kann ich nicht erkennen das hier irgend jemand Beleidigt wurde.

gruss

[Popov]

Ich glaube es war Sir Edmund Hillary, der erste erfolgreicher Besteiger des Mount Everest, den man fragte, wieso er diesen Berg bestiegen hat? Er antwortete: weil er da ist.

Es gibt keinen nützlichen Grund einen solchen Berg zu besteigen. Keinen. Auch gibt es keinen nützlichen Grund nach Exoplaneten zu suchen, denn selbst wenn man welche finden würde, die man als Mensch bewohnen kann, die Entfernungen sind einfach zu gewaltig. Und das ist nicht nur eine Frage der Zeit und Technik.

Natürlich kann man hier und da sich fragen welchen Sinn etwas hat, aber genau so wie z. Brainstorming konzeptionell davon ausgeht, dass es keine dumme Ideen gibt, sondern aus einer weniger guten Idee durchaus eine gute Idee entstehen kann, kann man sich darüber unterhalten ob es weniger guten Code gibt? Oder führt jeder Code dazu seine Grenzen zu erweitern?

[himitsu]

Adrenalinkick, Ruh, Ehere, ein erfüllter Traum und man hat einen geilen Ausblick.

Es hat auch absolut keinen Sinn das Haus zu verschieben, nur weil es im Keller zu dunkel ist und dennoch macht das Keiner, da es "bessere" Lösungen gibt.

[Mattze]

Hallo,

ICH halte die Frage nach den Grenzen eines Konzepts für durchaus berechtigt, auch wenn sie zunächst einmal dem einen oder anderen sinnfrei erscheint!

Übrigens: Eigentlich dürfte es nicht gehen, aber erstaunlicherweise scheint es doch zu funktionieren.

Delphi-Quellcode:

  
  if (index>Ftempindex) and Assigned(FOnBeforeDrawItem) then begin
    FOnBeforeDrawItem(Self, Index, Rect, State);
    FTempIndex:=index;
    exit;
  end;

im neuen DrawItem am Anfang tut es.
(FTempIndex ist eine Integer-Variable aus dem private-Bereich der neuen Listbox-Komponente und wird in Create mit -1 initialisiert.)

Es gibt noch beim ersten (und zweiten?) vertikalen Scrollvorgang ein kleines Problem, aber sonst sieht es schon gut aus und das ist verschmerzbar.

Gruß
Mattze

PS: Warum gibt es für Perlsau eigentlich nur Genie oder Anfänger?

[Dejan Vu]

Ich finde Mattzes Ansinnen, Fragestellung, Argumenation und Vorgehensweise absolut ok. Dieses 'völlig sinnfreie Anliegen' ist ein sehr wichtiger Bestandteil einer für viele vermutlich komplett überflüssigen Tätigkeit, die unsere Gesellschaft zwar weiterbringt ('Fortschritt'), aber jedoch im eigentlichen Sinne unproduktiv und für Laien teilweise auch blödsinnig ist.

Diese offensichtlich für Einige bekloppte Tätigkeit nennt sich: Forschen und basiert in erster Linie auf Wissensdurst. Und dieser Durst nach Wissen kann nur gestillt werden, wenn Vorbehalte ("Das braucht man doch nicht", "Geht auch anders", "völlig Sinnfrei") mal außen vor gelassen werden. Diese Vorbehalte kommen in der Anwendung zum Einsatz (und sind Antrieb von so etwas wie Wirtschaftlichkeit), haben in der Forschung jedoch nichts zu suchen.

Für Einige scheint Forschung und Programmieren nichts miteinander zu tun zu haben.

Zum Thema: Endllosschleifen in ereignisgesteuerten Programmabläufen lassen sich zuverlässig über Markierungen vermeiden. Grundsätzlich geht da so:

Delphi-Quellcode:

Procedure MyEventHandler(SomeObject : TSomeObject);
Begin
  If IsHandled[SomeObject] then exit;
  IsHandled[SomeObject] := true;
  Try
    DoSomeThingWith(SomeObject); // <<< Löst das Ereignis 'MyEvent' erneut aus
  Finally
    IsHandled[SomeObject] := false;
  End
End;

Eine andere Vorgehensweise ist die, einen die Schleife auslösenden Aufruf nur dann auszuführen, wenn es unbedingt nötig ist. Ein Beispiel ist ein Grid, welches die Spaltenbreite automatisch anpasst, wenn der darzustellende Text breiter als die augenblickliche Spaltenbreite ist. Dann wird die Breite ja nur gesetzt, wenn die Spalte noch nicht breit genug war. Hier findet zwar ein rekursiver Aufruf statt, aber nach dem ersten Aufruf ist Schluss, da die Breite ja beim 2. Aufruf passt.

Delphi-Quellcode:

procedure TForm1.StringGrid1DrawCell(Sender: TObject; ACol, ARow: Integer;
  Rect: TRect; State: TGridDrawState);
var
  sg : TStringGrid;
begin
  if not (Sender is TStringGrid) then exit;
  sg := TStringGrid(Sender);
  w := sg.Canvas.TextWidth(sg.Cells[aCol, aRow]);

  if w>sg.ColWidths[aCol] then 
    sg.ColWidths[aCol] := w; // <<< löst ein erneuten Aufruf von DrawCell aus!
  ...
end;

Hier würde ich vermutlich den zweiten Ansatz nehmen, denn der Text muss ja nur verändert werden, wenn noch nicht geändert wurde.

Eigentlich ist das 2.Pattern eine Spezialisierung des 1.Patterns, denn das [Delphi]IsModified[SomeObject][/delpi] wird ja durch die Änderung des Objekts abgebildet.

[himitsu]

Zitat:

Zitat von Dejan Vu (Beitrag 1263164)

Ich finde Mattzes Ansinnen, Fragestellung, Argumenation und Vorgehensweise absolut ok.

OnDraw ist zum Malen da und hat nichts an den Daten zu ändern.

Und ja, ich kenn einige Komponenten, welche jedesmal im OnDraw irgendwelche Daten überschreiben, oder erst dort Operationen ausführen, welche eigentlich in ein OnChange reingehören würden.
Das Verhalten solcher Komponenten ist völlig undurchschaubar, da gedade das Paintereignis an unbestimmter Stelle ausgeführt wird und wozu soll ein einmaliges Ereignis bei jeder Zeichenoperation ausgeführt werden?

Vorallem der Code in #16 ist ein gutes Beispiel.
Jenachdem wie oft das Ding gezeichnet werden muß, steht jedesmal was Anderes drin.


Und ja, wenn man was am Ausgabeformat oder den Daten ändert, dann muß sich das Ding doch neu zeichnen.
Drum macht man sowas auch nicht in einer Zeichenoperation.

Wenn man vollkommene Freiheit haben will, dann nimmt man eben sowas wie das VirtualTreeView oder (falls die Komponente es kann) versetzt die komponente in einen virtuellen Modus,
wo man im OnPaint alles anzeigen kann, was man will.
Aber auch da gilt, daß man z.B. an der Item-Größe nicht erst im OnPaint rumzuspielen hat.

[Mattze]

Hallo himitsu,

und damit sind wir genau da, woher meine Frage überhaupt kam - Virtualtreeview.
Ich habe mich gefragt, warum der das kann und z. Bsp. die Listbox nicht.
Beantworten kann ich diese Frage nicht richtig, aber für die Listbox habe ich es halt "irgendwie" auch hinbekommen.
Wie gesagt, ich hätte gedacht, dass das überhaupt nicht möglich ist, schon theoretisch nicht!

Aber nach Deinem Hinweis habe ich gemerkt, dass das ganz und gar nicht sauber ist und das unselige OnBeforeItemDraw wieder entfernt.
Fragt sich eben nur, warum das dann manche Komponenten überhaupt zulassen?

Gruß
Mattze

[himitsu]

Nja, diese Komponenten sind halt extra darauf ausgelegt, daß dort die Anzeige nicht aus enthaltenen Daten kommt.

Aber auch dort bleibt das Grundsätzliche Verhalten bestehen.
- entweder die Daten werden vor/beim Einfügen bereits angepasst
- oder es wird bei der Anzeige nur die Zeichenoperation geändert, aber so Sachen wie die Größe sollten dabei unangetastet bleiben.

Stell dir mal vor du fängt auf einem A4-Blatt an mit Malen und mittendrin kommst du auf die Idee "ach was, ich nehm jetzt doch A3".
Bzw. jedes Mal, wenn sich jemand dein Bild anguckt, tauschst du das Papier dahinter ... morgen vielleicht mal A8.

Zitat:

Zitat von Mattze (Beitrag 1263169)

Fragt sich eben nur, warum das dann manche Komponenten überhaupt zulassen?

Man denkt nicht daran, daß jemand auf diese Idee kommen könnte und baut somit keinen Code ein, welcher das abfängt.

Wenn es nicht geht, dann wird derjenige es schon mitbekommen, wenn es dann irgendwo kanllt. :stupid:

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1263170)

Stell dir mal vor du fängt auf einem A4-Blatt an mit Malen und mittendrin kommst du auf die Idee "ach was, ich nehm jetzt doch A3".
Bzw. jedes Mal, wenn sich jemand dein Bild anguckt, tauschst du das Papier dahinter ... morgen vielleicht mal A8.

Bis es dann passt. Und wenn es nicht passt, wird es passend gemacht. Das kann man vorher machen (und man sollte es ja in diesem konkreten Beispiel auch), aber wenn man es im OnPaint machen will, wieso nicht? Man lädt Daten ja auch im Getter (lazy load) wieso keine dynamische Anpassung im paint? Bloß weil man 'es nicht macht'? ;-) Es geht, ist einfach, direkt und sicher (wenn man weiß, was man macht).

[Perlsau]

Da stellt sich mir doch glatt die Frage: Wie bringt man merkbefreiten Kandidaten bei, daß sie merkbefreit sind?

[Dejan Vu]

Zitat:

Zitat von Perlsau (Beitrag 1263197)

Da stellt sich mir doch glatt die Frage: Wie bringt man merkbefreiten Kandidaten bei, daß sie merkbefreit sind?

Guten Morgen. Die Frage stellt sich mir auch gerade...