ListView Position der Node-Selection/Editbox ändern

[dGeek]

Ist es möglich, die Node-Selection eines Nodes einer TreeView in der Position zu verändern?

Wenn ein Node sagen wir mal einen ganzen Satz beinhaltet, dann ist es nicht sonderlich kompliziert mit der Maus in den Editiermodus dieses Nodes zu gelangen.
Enthält der Node aber nur sehr wenige Zeichen oder eben gar keine, ist die Fokus-Box nur ein paar Millimeter weit.

Im AdvancedCustomDrawItem-Event steht schon folgendes:

Delphi-Quellcode:

var
 aFocusRect: TRect;
begin
 aFocusRect := Node.DisplayRect(True);
 
 if Stage = cdPostPaint then
  begin
   aFocusRect.Width := TTreeView(Sender).Width - aFocusRect.Left;
   DrawFocusRect(DC, aFocusRect);
  end;

 //
end;

Das erweitert die Selektierung bis zum rechten Ende des TreeView. Aber egal wo ich klicke, ich gelange nur in den Editiermodus, wenn ich an der originalen Stelle der Fokus-Box klicke.
Visuell ist die Fokus-Box also größer und wie gewünscht, aber technisch hat sie wohl noch die Originalgröße.

[nahpets]

Sowas löse ich sehr unelegant:

Ist mir der Text zu kurz, hänge ich einfach ein paar Leerzeichen dran, solang der Text nicht irgendwo inhaltlich ausgewertet werden muss, ist das (halbwegs) ok.

Eventuell nimmst Du statt des Leerzeichens auch das geschützte Leerzeichen (#160), dann werden die künstlichen "Lücken" gleichmäßig lang.

[himitsu]

Ist ja auch klar. Nur weil DU Irgendwas beiter zeichnest, ist die Eingabebehandlung der Maus nicht ebenfalls geändert.


Aber ich würde mich eher fragen, wer auf die saublöde Idee gekommen ist, dass RowStyle nicht das macht, was es machen sollte. :roll:
TTreeView.RowStyle

Zitat:

Zitat von nahpets (Beitrag 1353484)

solang der Text nicht irgendwo inhaltlich ausgewertet werden muss, ist das (halbwegs) ok.

Genau andersrum, denn wenn jemand die Oberlächenwerte auswertet, dann ist das nicht OK.
Das geht dann auch gleich bei der Lokalisierung weiter, wo dann plötzlich was Anderes in der Oberfläche steht, oder bei Buttons/Menüs, wenn dort automatisch ein & eingefügt wurde.

Man kann nicht umsonst an jeden einzelnen Node "interne" Extradaten (Data) hängen.

[himitsu]

[del]

[Aviator]

Stichwort VirtualTreeView. Der sollte sowas (eventuell mit der Option toFullRowSelect) eigentlich problemlos können (und noch viel viel mehr). Habe es nicht explizit ausprobiert, meine aber, sowas schonmal gemacht zu haben.

Es sei denn hier geht es um FMX. Dann habe ich nix gesagt. :stupid:

[nahpets]

Zitat:

Zitat von himitsu (Beitrag 1353486)

Zitat:

Zitat von nahpets (Beitrag 1353484)

solang der Text nicht irgendwo inhaltlich ausgewertet werden muss, ist das (halbwegs) ok.

Genau andersrum, denn wenn jemand die Oberlächenwerte auswertet, dann ist das nicht OK.
Das geht dann auch gleich bei der Lokalisierung weiter, wo dann plötzlich was Anderes in der Oberfläche steht, oder bei Buttons/Menüs, wenn dort automatisch ein & eingefügt wurde.

Man kann nicht umsonst an jeden einzelnen Node "interne" Extradaten (Data) hängen.

Naja, genau deshalb schrieb ich ja auch "halbwegs" und ganz am Anfang, dass ich das dann sehr unelegant löse.
Mir ist also durchaus klar, dass das unprofessionell ist, aber wenn man es nur für Software benötigt, die man selbst nutzt, mag das angehen.

Selbstverständlich nutze ich, wenn ich über 'nen Treeview auf irgendwelche Daten zugreifen muss, Das Attribute Data. Derweil: Damit ist die Verwaltung so wunderbar einfach und man muss da nicht rgendwie rumhampeln, um an die gewünschte Information zu kommen.