XbpListBox einzelne Items einfärben

[__WEY]

Hallo zusammen

Gibt es eine Möglichkeit einzelne Items einer Listbox einzufärben? Leider gibt es für die methode additem keinen Parameter dafür...

Liebe Grüsse WEY

[brandelh]

Das geht über Owner-Drawing, suche mal in der Hilfe nach dem Begriff "Owner-Drawing",
ich habe es noch nicht gemacht, aber TOMs Beispiele für den Browser haben auch Farben ausgetauscht - neben anderen Dingen.

[Tom]

Ja, gibt es, mit Ownerdrawing. Einfach den DrawItem-Slot von XbpListbox mit einer Funktion belegen, die als Parameter den Presentation Space des zu zeichnenden Elements und ein Info-Array u.a. mit dem Zeichenbereich bekommt. XbpListBox:DrawMode muss auf XBP_DRAW_OWNER gesetzt werden. In der Funktion holst Du Dir das zu zeichnende Element mit ::GetItem(aInfo[XBP_DRAWINFO_ITEM]) und ermittelst dort dann die passende Farbe. Die setzt Du für den PS. Und dann "zeichnest" Du den Inhalt mit GraCaptionStr(). Lässt sich auch um Grafiken und Icons usw. ergänzen. Das kann dann im Ergebnis z.B. so aussehen (ist eine ComboBox, spielt aber keine Rolle):

[AUGE_OHR]

Gibt es eine Möglichkeit einzelne Items einer Listbox einzufärben? Leider gibt es für die methode additem keinen Parameter dafür...

die "XbpImageListBox" ist wohl mal auf einer Devcon verteilt worden.

es wäre gut wenn Alaska solche Demos mal "frei" geben würde ...

[Jan]

Alaska veröffentlicht in Kürze das XBPack 3, in dem auch irgendwas mit Listview drin ist.

Jan

[brandelh]

Hi,

ListView ist nicht gleich ListBox.
War die ListBox nicht in einem der vorhandenen Packs erweitert worden ?
ich finde hier nur das erste:

Code: Alles auswählen

 This is the README for Xbase Part Pack #1
 * 
 * Release: 1.90.355
 * Date:    August 15th 2009

     1. XbpImageButton  and
     2. XbpImageTabPage

Das zweite scheine ich mir noch nicht geladen zu haben und aktuell ist die Site noch nicht in Betrieb.
Weiß jemand was in der Zweiten war ?

Auf jeden Fall kann man aber - siehe Toms Bespiel - per Ownerdrawing die Farben setzen.

[Martin Altmann]

Moin Hubert,
da waren die beiden Klassen XbpProgressBar und XbpFormattedLabel drin.

Viele Grüße,
Martin

[AUGE_OHR]

ListView ist nicht gleich ListBox.

YUP ... aber wenn die ListBox :multiColumn := .T. "richtig" machen würde wäre es dem ListView im Report Modus sehr ähnlich.

War die ListBox nicht in einem der vorhandenen Packs erweitert worden ?

das kam zusammen mit dem "Office" Menu. Das "Pack" hatte aber keine "Anbindung" an XppFD.EXE ( Formdesigner ) da die *.DAT Datei nicht mitgeliefert wurde.

[hschmidt]

Hallo Tom,

Deine Darstellung der Combobox finde ich sehr interessant. Wie hast Du denn die Spalten hinbekommen?
Ich habe damit seinerzeit viel herumprobiert (Stichwort :multiColumn) und habe dann in der Hilfe den Hinweis gefunden, dass der Mehrspaltenmodus für das Listbox-Element von XbpCombobox-Objekten nicht unterstützt wird.

Aber irgendwie scheint es ja doch zu gehen...

Viele Grüsse

Hans

[Tom]

Hallo, Hans.

Diese Listbox ist nicht mehrspaltig. DrawItem bekommt ein - mit Var2Char umgewandeltes - Array, das in der Methode zurück in ein Array umgewandelt wird. Mit MeasureItem wird die Zeilenhöhe gesetzt, damit sie mit der Höhe des SLE übereinstimmt. In der Zeile malt die Methode abhängig vom Inhalt des Arrays zunächst den Text, dann die Box (die auch von Arraydaten abhängig gefärbt wird) und schließlich, sofern vorhanden, ein Symbol, das aus einer DLL geladen wird. Die Position der einzelnen Elemente wird über die Breite der Listbox ermittelt (es gibt also eine Mindestbreite, für die das noch funktioniert). Alle relevanten Prozesse (Positionsermittlung, Erzeugung des Icons usw.) finden einmalig in der Init-Methode statt. That's it.

[hschmidt]

Aahh, vielen Dank Tom,

das wäre ja vielleicht ein Grund, sich doch mit Ownerdrawing zu beschäftigen. Bislang hatte ich noch keine Veranlassung, mich darin einzuarbeiten.
Ich habe das Thema immer nur am Rande mitverfolgt und auch so verstanden, dass sich Ownerdrawing und Styles nicht vertragen.
Liege ich da richtig?

Hans

[Tom]

Hallo, Hans.

Ich habe das Thema immer nur am Rande mitverfolgt und auch so verstanden, dass sich Ownerdrawing und Styles nicht vertragen.

Wenn man mit SL1 und Vista/7 unter Verwendung eines Themes wie "Aero" arbeitet, funktionieren z.B. per ColorBlock für Spalten gewählte Vordergrundfarben in Browses nicht mehr. Das ist, wie Steffen Pirsig auf unserem Treffen in Hannover ausgeführt hat, der Tatsache geschuldet, dass Microsoft für diese Situation klare Vorgaben (Vorschriften) macht, von deren Einhaltung/Nichteinhaltung abhängig ist, ob eine Software - in diesem Fall der Compiler - noch zertifizierbar ist oder nicht. Anders gesagt: Bei der Verwendung von Themes gibt es in betriebssystemkonformen Browses eigentlich keine Vordergrundfarben mehr. Dafür gibt es auch eine einleuchtende Erklärung: Da das Theme bestimmt, mit welchen Farben die Hervorhebung arbeitet, könnte die direkte Farbauswahl hier dazu führen, dass man z.B. blaue Schrift vor blauem Hintergrund hätte - also nichts mehr erkennen könnte.

Anders gesagt: Themes stellen hier, bezogen auf die gestalterische Freiheit des Programmierers, einen Rückschritt dar. Die entstehenden Applikationen wirken zwar einheitlicher, aber die Gestaltungsmöglichkeiten sind geringer. Vorsichtig gesagt. Ohne Vordergrundfarben in Browses bin ich so gut wie aufgeschmissen, denn wir verwenden Browses u.a. für umfangreiche Planungssysteme, bei denen Farben wichtige Rollen spielen.

Mit Ownerdrawing kann man in diesen Prozess eingreifen, und zwar auf verschiedenen Ebenen. In einem Browse kann die Applikation z.B. die Zeichnung der Zelleninhalte (Vordergründe) übernehmen, um so die Betriebssystemeinschränkungen zu umgehen. Letztlich kann man das sehr weit treiben, wie in meiner Listbox gezeigt, die zwar viel kann, aber eben nicht mehr richtlinienkonform ist. Hier übernehme ich auch das Highlighting und sogar, über MeasureItem, die Auswahl des Anzeigebereichs. Das mache ich in Browses nicht. Meine App würde in dieser Situation vermutlich kein MS-Zertifikat bekommen, aber dafür kann sie alles, was sie können soll, und sie sieht toll aus. Das ist mir, um ehrlich zu sein, auch wichtiger.

"Nicht vertragen" ist also nicht ganz richtig - es hängt davon ab, wo man ansetzt. Wenn man mit OWNERADVANCED das Zeichnen für alle Situationen (Hintergrund, Vordergrund, Hervorhebung usw.) übernimmt, hat man keine Schwierigkeiten, denn das OS beeinflusst nicht mehr, wie die Daten aussehen (dafür ist die App dann an dieser Stelle nicht mehr "konform"). Wenn man tiefer ansetzt und z.B. nur die Vordergründe zeichnet (etwa in Browses, um Vordergrundfarben zu reaktivieren), kann man mit Systemfarben in Konflikt geraten. Solche Fälle müsste man dann abfangen, oder man überlässt es dem Benutzer, hier Farben zu wählen. Man kann das ganze aber auch umgekehrt sehen: Ownerdrawing erlaubt es, z.B. unter XP oder Windows 2000 (oder wenn überhaupt keine Themes genutzt werden) intern so zu arbeiten, dass es trotzdem "nach Theme aussieht", denn auch die Gradientenhervorhebung mit hübschem Rand usw. lässt sich nachstellen.

Solche Listboxen wie die von mir gezeigte dürfte es also eigentlich nicht geben, denn sie entsprechen nicht mehr den Spezifikationen für solche Controls. Wenn einem das egal ist (was für mich gilt), nutzt man sie trotzdem.

[hschmidt]

Hallo Tom,

vielen Dank für diese ausführlichen Erläuterungen.
Wie gesagt hatte ich bislang zum Thema Ownerdrawing keine Notwendigkeit erkennen können und habe das Gefühl, dass es vielen hier so geht.....

Hans

[Tom]

Hallo, Hans.

Wer mit dem Standardverhalten und -aussehen der Parts/Controls auskommt, hat auch keine Notwendigkeit, sich mit Ownerdrawing zu befassen. Außerdem gibt es natürlich Alternativen - man kann sich Active-X-Komponenten kaufen, die dann das leisten, was hauseigene Controls standardmäßig (!) nicht mehr können. Aber Ownerdrawing ist unterm Strich eigentlich ziemlich simpel umzusetzen. Man muss sich ein wenig mit der GRA-Engine auseinandersetzen, man sollte etwas (ist nicht viel) über Presentation Spaces wissen - und eine Lösung dafür finden, dass Ownerdrawing in separierten Threads stattfindet, dass also keine Verbindung z.B. zu Workareas vorhanden sind. Alles andere ist Fleißarbeit.

[AUGE_OHR]

Ich habe das Thema immer nur am Rande mitverfolgt und auch so verstanden, dass sich Ownerdrawing und Styles nicht vertragen.

es gibt die Methode GraBackground() welche den "visual Style" anzeigt.
bei Xbase++ erfolgt die "Anzeige" des "visual Style" nun "auf" einem XbPart sodas evtl. Hintergrundfarbe des XbPart "überdeckt" werden.

Dies Verhalten ist IMHO falsch den "visual Style" sollte im "selben Layer" angezeigt werden sodas es sich wie bei der Vordergrund Farbe, welche für die "Schrift" zuständig ist, verhält ( OVERPAINT ).

hier nun mal SOURCE für eine Ownerdraw ComboBox, eine Listbox sollte sich schnell aus dem Beispiel ableiten lassen.