procedural zu OOP [Erledigt]

[Martin Altmann]

Markus,
sieht wirklich gut aus

Viele Grüße,
Martin

[Werner_Bayern]

Hallo Werner,

Aber machbar ist damit ein "Browse" wie im Anhang dargestellt...

Servus Markus,

nur um es Klarzustellen: Ich würde dafür auch bezahlen, da steckt ja sicherlich eine enorme Programmierleistung dahinter.

[Tom]

Hallo, Werner.

Ich will Markus' Programmierleistung nicht kleinreden, aber wenn man das Prinzip des Ownerdrawing und ein paar essentielle GRA-Funktionen verstanden hat, ist es soooo kompliziert dann auch wieder nicht. Es gibt zwei relevante Methoden in XbpListBox, nämlich DrawItem und MeasureItem. DrawItem fängt das Zeichnen der Elemente ab. Man zerlegt dort dann den Text, der angezeigt werden soll, und malt ihn einfach in den Presentation Space (GraCaptionStr ist die Funktion der Wahl) - alle hierfür erforderlichen Infos enthält der Parameter "aInfo". Und in MeasureItem manipuliert man abhängig von der Zeilenanzahl im jeweiligen Element einfach die Höhe der Zeile, fertig. Siehe Beispielcode weiter oben.

[Markus Walter]

Ich will Markus' Programmierleistung nicht kleinreden

Das möchte ich Dir auch nicht raten...

Aber im Ernst. Es ist wirklich nicht kompliziert, wenn man das Ownerdrawing mal verstanden hat (und damit verbunden auch den Einsatz von Gra...-Funktionen zum Zeichnen, bzw. malen von Text). Ich habe leider kein einfaches Beispiel zur Hand, dass ich aus dem Hut zaubern kann. Auch weil ich Express einsetze und erst gar kein "Plain"-Xbase-Sample gemacht hatte. Was als Endprodukt in meiner Anwendung drin ist, ist auch recht komplex geworden, weil ich z. B. auch RTF-Texte im Control zeichne.

Vielleicht kann ich nächste Woche mal mein Testprogramm auf Plain-Xbase umstellen, aber ich kann nicht versprechen, dass ich das zeitmäßig schaffe.

Es gibt aber im Wesentlichen 3 Punkte, die zu beachten sind:
- Eine XbpListbox hat keine "Datenbindung" zu einer Tabelle, d. h. durch Bewegen in der Listbox wird kein Satzzeiger in der Tabelle bewegt.
- Ownerdrawing geht sinnvoll nur, wenn alle "benötigten" Daten in einem Array stehen, weil a) das zeichnen im GuiThread passiert und darin kein Zugriff auf die geöffneten Tabellen besteht und b) das Zeichnen generell schnell sein muss, sprich ohne großartige "Berechnungen" auskommen muss
- Bedingt durch einen Fehler in Xbase, die Listbox immer wieder komplett neu gefüllt werden muss, wenn man Daten einer "Zeile" ändern will, Daten hinzufügen oder Löschen möchte

Damit ist diese Art Listbox nicht mehr für alle Einsatzzwecke geeignet. Ich führe die benötigten Daten in einem Array, der mit der Tabelle synchron gehalten wird...

[Werner_Bayern]

Ich will Markus' Programmierleistung nicht kleinreden, aber wenn man das Prinzip des Ownerdrawing und ein paar essentielle GRA-Funktionen verstanden hat, ist es soooo kompliziert dann auch wieder nicht.

Servus Tom,
danke, werde mich beizeiten damit beschäftigen, ist halt blöd, wenn ich das Rad neu erfinden muss. Hat sicherlich ja schon jeder mal benötigt.
Sowas sind ja eigentlich Basics, klar, auch mich würde es reizen, sowas selber per Hand zu codieren, aber die Kunden haben dafür kein Verständnis, die wollen es nur so haben. Meine Zeit muss ich in die Business-Logik stecken.

Oder ich greife doch noch zu einem 3rd-Tool. Aber die Einarbeitungszeit ist dann auch nicht wieder ohne...

[AUGE_OHR]

hi,

das "Original" XBP_DRAW_OWNER Sample findest du unter

public.xbase++.gui
Re: Colour in xbpbrowse() cells
30. August 2010
J.A. Diego Kerejeta

als Highlight.zip

in der Wissenbasis findest du DLL / LIB für eine "5 Sterne" Ownerdraw XbpColumne

Code: Alles auswählen

#include "Xbp.ch"
#pragma Library( "XppUi2.lib" )

CLASS DXE_StarColumn FROM XbpColumn
EXPORTED:
   VAR oStar

INLINE METHOD create( oParent, oOwner, aPos, aSize, aPP, lVisible )
   ::XbpColumn:create( oParent, oOwner, aPos, aSize, aPP, lVisible )

   ::drawMode        := XBP_DRAW_OWNER 
   ::dataArea:customDrawCell := {| oPS, aInfo, oSelf | ShowStar(oPs,aInfo,oSelf) }

RETURN self

jetzt muss man "nur" in der Function ShowStar() ein wenig "malen" ...

[AUGE_OHR]

- Eine XbpListbox hat keine "Datenbindung" zu einer Tabelle, d. h. durch Bewegen in der Listbox wird kein Satzzeiger in der Tabelle bewegt.

das ist nicht richtig so
http://msdn.microsoft.com/en-us/library ... ource.aspx

There are two ways to fill the ComboBox and ListBox controls.

For example, you can add objects to the ComboBox by using the Add method.
You can also add objects to a ComboBox by using the DataSource, DisplayMember, and ValueMember properties to fill the ComboBox.

es wäre also durchaus möglich, wie zeigt z.b. dieser Code zeigt http://msdn.microsoft.com/en-us/library ... ember.aspx und das ist nicht "nur" .NET bezogen.

[Markus Walter]

Jimmy,

Du solltest die Leute nicht verwirren. Für einen Xbase-Entwickler hat eine XbpListbox keine "Datenbindung", die einem XbpBrowse vergleichbar wäre. Was anderes zu behaupten ist Blödsinn (auch wenn das Originalcontrol vielleicht auf irgendeinem Wege mit irgendwelchen Datenquellen verbunden werden kann).

Wenn man also Inhalte einer Datentabelle damit "browsen" will, muss man einiges dafür tun, was bei einem XbpBrowse quasi automatisch geht.

[AUGE_OHR]

Du solltest die Leute nicht verwirren. Für einen Xbase-Entwickler hat eine XbpListbox keine "Datenbindung", die einem XbpBrowse vergleichbar wäre. Was anderes zu behaupten ist Blödsinn (auch wenn das Originalcontrol vielleicht auf irgendeinem Wege mit irgendwelchen Datenquellen verbunden werden kann).

viele XbParts haben nicht die "vollen" Eigenschaften über welches das Control "eigentlich" verfügen.
so fehlen z.b. sämtliche Vista / Win7 Common Control v6.x Future welche man mit XP Manifest "anfordert".

nur weil es für Xbase++ User "unbekannt" oder nicht "dokumentiert" ist es heisst es nicht das es das nicht gibt oder Blödsinn ist.
Xbase++ ist nicht das non-plus-ultra sondern man muss auch mal über den Tellerrand schauen um sich weiter zu entwickeln.

[Tom]

Hallo, Jimmy.

Diese Listbox mit Databinding gibt es ausschließlich für das .NET-Framework. Windows-Standardcontrols haben grundsätzlich keine Verbindung zu wie auch immer gearteten Datenquellen. Wenn man das benötigt, muss es in der Wrapperklasse implementiert werden, wie hier für .NET geschehen. GUI-Elemente vom Fenster über das Static und das SLE bis hin zur Listbox verfügen über Captions oder Puffer, die die derzeit repräsentierten Daten beinhalten. Für die Aktualisierung dieser Captions oder Puffer muss die Anwendung bzw. die Wrapperklasse sorgen. Ein Sonderfall ist das Browse, das aber kein Windows-Standardcontrol ist. Dem liegt die paradigmatische Entscheidung zugrunde, dass die Anwendung entscheiden können muss, wie sich Manipuliationen in einem Control auf die echte Datenquelle auswirken sollen. Würde sich etwa jede Manipulation eines in einem SLE angezeigten Textes unmittelbar auf die "angehängte" Tabelle auswirken, wäre ein sehr viel höherer Aufwand nötig, um solche Manipulationen rückgängig machen zu können, und das Control könnte schnell in einen nichtdefinierten Zustand geraten, wenn mit der Datenquelle irgendwas passiert, sie etwa im Netz von einem anderen Nutzer geändert oder gar gelöscht wird. Deshalb werden alle Controls explizit mit Daten versorgt/bestückt, die dann aus unterschiedlichesten Quellen stammen können. Umgekehrt muss die Anwendung dafür Sorge tragen, dass Manipulationen in die Datenquelle zurückwandern, insofern das gewünscht ist.

Bei Xbase-Parts, die die Datalink-Methode kennen, wird uns sprachspezifisch ein vereinfachter Datenzugriff erlaubt, der architekturbedingt bei Xbase++ dann auch die direkte Verwendung von Tabellendaten ermöglicht. Dass dies möglich ist, liegt vor allem daran, dass Xbase++ Tabellenfelder und Speichervariablen gleich behandelt.

Eine Listbox mit direkter Tabellenanbindung hielte ich ganz persönlich für nicht besonders sinnvoll, jedenfalls als Standard. Eine Listbox ist ja auch kein Control zur Datenmanipulation (wie etwa SLE und MLE - oder prinzipiell ein Browse).

[AUGE_OHR]

Diese Listbox mit Databinding gibt es ausschließlich für das .NET-Framework.

Databinding gibt IMHO ab Common Control v6.x für Vista / Win7, aber Xbase++ "beherrscht" auch mit XP Manifest nur die v5.x Controls.

ich hatte ja die Frage zu den Versions Nummer in WinUser.h / CommCtrl.h gestellt wo die Konstanten vorhanden sind.
so wie ich das verstanden habe "könnte" es sein das die XbParts durchaus schon die Fähigkeit besitzen (wenn die richtige CommCtrl.h eingebunden wurde) ... man müsste sie dann "nur" aktivieren.

hierzu müsste der "dwStyle" um *_OWERDATA erweitert werden was man mit

Code: Alles auswählen

Beispiel ListView

nStyle :=     nOr(::dwLvStyle, LVS_OWNERDATA )
@user32:SetWindowLongA(hWnd , GWL_STYLE , nStyle )

erreichen könnte ( wenn dwStyle "Exported" ist um man "Zugriff" hat)

allerdings nützt einem das noch nicht wenn die Windows Message ( WM_* ) nicht "abgefangen" wird.
hierzu benötigt man nun wieder SubClassing welches man mit ot4xb machen kann.

... und dann müsste man "nur" noch den Xbase++ "Wrapper" dafür schreiben

[Tom]

Databinding gibt IMHO ab Common Control v6.x für Vista / Win7

Nö.

[AUGE_OHR]

Databinding gibt IMHO ab Common Control v6.x für Vista / Win7

Nö.

da ich ListBox noch nicht als "native" Control angefangen habe und mein ListView mit LVS_OWNERDATA Databinding noch nicht fertig ist kann ich den Gegenbeweis (noch) nicht antreten.

die Konstanten sind aber jeweils unter dem Abschnitt WINVER zu finden. deshalb gehe ich davon aus das man die Common Control v6.x für Vista / Win7 mit XP Manifest benutzen muss.

[AUGE_OHR]

Databinding gibt IMHO ab Common Control v6.x für Vista / Win7

Nö.

da ich ListBox noch nicht als "native" Control angefangen habe und mein ListView mit LVS_OWNERDATA Databinding noch nicht fertig ist kann ich den Gegenbeweis (noch) nicht antreten.

so langsam geht es los ... http://www.xbaseforum.de/viewtopic.php? ... 1&start=57