Da hast du recht. Ich versuch's mal:
Ich hab es mit einem eigenen EditLink gemacht. Das Advanced Demo (Editor.pas und GridDemo.pas) zeigt prinzipiell, wie es geht. Für meine Problemstellung war natürlich unwichtig, andere Komponenten als Editoren zu nutzen. Für mich war der Zugriff auf das im EditLink hinterlegte Edit-Feld (bei mir dann vom Typ TEdit) völlig ausreichend. Insbesondere habe ich also in meinem eigenen TPropertyEditLink die Prozedur EditKeyDown deklariert, um in dieser dann auf die Cursortasten reagieren zu können. In der Funktion PrepareEdit meines TPropertyEditLink's habe ich dann dem OnKeyDown den neuen KeyDown-Handler zugewiesen und das war's schon fast.
Damit kann man also nun im KeyPress des VirtualStringTree's (heißt bei mir VST1) auf jede Taste so reagieren, dass man sich den Tastencode (z.B in einer globalen Variablen PressedKey: Char) merkt und dann über VST1.EditNode(...) den neuen Editor generieren lässt. Im PrepareEdit weist man dann den gemerkten TastenCode dem TPropertyEdit.FEdit.Text zu - man will ja schließlich, dass das im VST1 gemerkte erste Zeichen nicht nur den Editor startet, sondern dort gleich als erstes Zeichen übernommen wird.
Von nun an befindet man sich also dann im TEdit (erstes Zeichen steht also schon drin) und kann nach den weiteren eingegebenen 'normalen Zeichen' über die oben beschriebene TPropertyEditLink.EditKeyDown bei Betätigung der Cursortasten gleich aus dem Editor aussteigen (FTree.EndEditNode). Vor dem Ausstieg aber FEdit.Modified auf true setzen, damit die Änderung auch für voll genommen wird und über PostMessage(FTree.Handle, WM_KEYDOWN, Key, 0) die Message absetzen, dass die Ausstiegs-Cursortaste auch nebenbei noch im Tree wie eine Cursortaste wirkt.
Ich hoffe mit den beiliegenden Code-Schnipseln kann man verstehen, wie es funktioniert.
Gruß
menschjens