Seite 1 von 1

Browses

Verfasst: Fr, 29. Aug 2014 18:16
von Wolfgang Ciriack
Größtes Problem sehe ich zur Zeit bei Browses. Die Presentationparameter bezüglich Zellen/Zeilenhöhe scheinen überhaupt keine Auswirkung mehr zu haben, dafür wirken sie auf den Header falsch/oder anders.
Auch das der Satzpointer nicht mehr mit dem hilited Satz synchron ist ist ein Showstopper.
Ich benutze zwar eXPress++, aber vielleicht hat ja schon jemand ohne eXpress ähnliches festgestellt ?

Re: Browses

Verfasst: Fr, 29. Aug 2014 18:30
von Fischkopp
Hallo, Wolfgang
Auch das der Satzpointer nicht mehr mit dem hilited Satz synchron ist ist ein Showstopper.
das kann ich so bestätigen, der gleiche Code unter 1.9 funktioniert :(

Mal sehen, wann da was wie kommt im September

Re: Browses

Verfasst: Fr, 29. Aug 2014 20:50
von Jan
Hallo Wolfgang,

mit den Browses hatte ich in früheren CTP-Versionen große Probleme. Aber inzwischen geht das eigentlich.

Das mit dem Hilite ist richtig. Es soll aber in der Final einen Schalter geben mit dem man das auf ursprünglichers Verhalten umstellen kann. Warum Alaska hier mit alten Vorgehensweisen bricht ist mir allerdings unverständlich.

Jan

Re: Browses

Verfasst: Sa, 30. Aug 2014 20:40
von Werner_Bayern
Den Schalter gibt es längst:

Code: Alles auswählen

navigationMode
wichtig auch

Code: Alles auswählen

rowPhyPos

Re: Browses

Verfasst: So, 31. Aug 2014 8:07
von Wolfgang Ciriack
Hallo Werner,
danke für den Hinweis.

@Jan,
funktioniert bei dir denn z.B. das Scrollen mit dem Mausrad richtig ?

Re: Browses

Verfasst: Mo, 01. Sep 2014 9:04
von Jan
Hallo Wolfgang,

das muß ich mal ausprobieren. Ich weiß aber, das Till da was dran geschraubt hat. Weder unter 1.9 noch unter 2.0 klappt nämlich das Scrollen auf manchen Touchpads. Ab CTP4R3 oder R4 lief das aber dann.

Jan

Re: Browses

Verfasst: Mo, 01. Sep 2014 9:32
von Wolfgang Ciriack
Danke Jan,
ist immer ein wenig problematisch zu sagen, das funktioniert nicht, wenn eXpress dazwischen hängt.
Na dann probieren wir mal noch ein bischen rum und warten wir mal ab, was die final 2.0 bringt #-o

Re: Browses

Verfasst: So, 02. Nov 2014 22:00
von Werner_Bayern
Wolfgang Ciriack hat geschrieben:@Jan,
funktioniert bei dir denn z.B. das Scrollen mit dem Mausrad richtig ?
Geht bei mir immer noch nicht (556) :(

Re: Browses

Verfasst: Mo, 03. Nov 2014 7:13
von Jan
Ich bin noch in heftigen Diskussionen mit Till, weil manche PP nicht oder zumindest anders als unter 1.9 fuktionieren. Das mit den Zeilenhöhen habe ich inzwischen hinbekommen. Aber die Zeilenfarben und die Gitterlinien bekomme ich immer noch nicht hin.

Da muß Alaska noch so einiges nacharbeiten ...

Jan

Re: Browses

Verfasst: Mo, 03. Nov 2014 10:19
von UliTs
Wenn die PPs fehlerfrei umgesetzt würden, wäre ich sehr dafür, dass dann auf Rückwärtskompatibilität verzichtet würde. Fehler braucht man schließlich nicht erhalten :D .

Uli

Re: Browses

Verfasst: Mo, 03. Nov 2014 10:29
von Jan
Hallo Uli,

da stimme ich Dir zu. Aber im Moment funktionieren die PP in 2.0 entweder garnicht oder falsch. Wenn das korrigiert wird, und in dem Zug gleich die alten Fehler mit behoben werden, wäre ich durchaus zufrieden.

Mal schauen, was Till da noch drehen kann.

Jan

Re: Browses

Verfasst: Mo, 03. Nov 2014 10:38
von Tom
Wenn das korrigiert wird, und in dem Zug gleich die alten Fehler mit behoben werden, wäre ich durchaus zufrieden.
Die Frage ist, ob das geht. Man musste bis einschließlich in Version 1.9 SL1 die Präsentationsparameter reichlich verbiegen, um etwas hinzubekommen, das eigentlich anders/leichter gehen sollte - ich denke da an Browses ganz ohne Zellen-/Zeilenränder. Dafür musste man XBP_PP_COL_DA_CELLFRAMELAYOUT auf "XBPFRAME_BOX" setzen und XBP_PP_COL_DA_FRAMELAYOUT auf "XBPFRAME_NONE", sonst hat es - meiner Erinnerung nach - nicht funktioniert (und dann war mit visuellen Stilen das Verhalten wieder anders). Um das weiterhin zu gewährleisten und zugleich das Verhalten der Parameter zu korrigieren, müsste man eigentlich zusätzlich neue einführen.

Re: Browses

Verfasst: Mo, 03. Nov 2014 12:46
von Jan
Tom,

stimmt, unter 1.9 gab es Bugs.

Aber unter 2.0 auch, und zwar andere. Z. B. bekomme ich keine normalen Gitterlinien hin. Nur senkrechte, und nur breite. Keine schmalen, keine waagerechten. Und wenn man {XBP_PP_COL_DA_CELLFRAMELAYOUT , XBPFRAME_NONE} einbaut, zusammen mit Zeilencursor, dann wird beim Scrollen JEDE Zeile markiert ... Nicht besonders angenehm, damit zu arbeiten ...

Jan

Re: Browses

Verfasst: Mo, 03. Nov 2014 19:08
von AUGE_OHR
Frage : wie verhält sich ein XbpBrowse() mit Ownerdraw in der v2.x Release ?

als wir 2012 die erste Preview bekommen haben funktioniert ein "normales" XbpBrowse() gar nicht ...
ich habe dann alles auf Ownerdraw umgestellt und zumindest in den beta Versionen ( bis 519 ) kein Problem gehabt.

Re: Browses

Verfasst: Mo, 03. Nov 2014 19:20
von satmax
Wenn man Toms Owner Draw Beispiel (#6) nimmt:

fährst Du mit dem Cursor nach unten verschwindet die Zeilentrennung (der Strich), fährst mit dem Cursor wieder nach oben kommt sie wieder...

Re: Browses

Verfasst: Mo, 03. Nov 2014 21:37
von AUGE_OHR
satmax hat geschrieben:Wenn man Toms Owner Draw Beispiel (#6) nimmt:
fährst Du mit dem Cursor nach unten verschwindet die Zeilentrennung (der Strich), fährst mit dem Cursor wieder nach oben kommt sie wieder...
ah ... ja ...
nun müsste man mal die Werte von aInfo [ XBP_DRAWINFO_RECT ] von der v1.9x und der v2.x vergleichen ob die gleich sind. wenn ja sollte man mal testen ob jetzt XBP_DRAWACTION_DRAWFRAME ( OwendrawAdvance ) funktioniert ...

Re: Browses

Verfasst: Di, 04. Nov 2014 7:00
von satmax
Wenn ich in Toms Beispiel folgendes ändere werden die Trennlinien wieder richtig dargestellt:

Code: Alles auswählen

* und noch eine Trennlinie:
GraSetAttrLine( oPS, ::aLineAttrs )
// GraLine(oPs,{ aInfo[ XBP_DRAWINFO_RECT,1 ]-3,aInfo[ XBP_DRAWINFO_RECT,2 ]-3},{aInfo[ XBP_DRAWINFO_RECT,3 ]+3,aInfo[ XBP_DRAWINFO_RECT,2 ]-3 } )

// wird zu :
GraLine(oPs,{ aInfo[ XBP_DRAWINFO_RECT,1 ],aInfo[ XBP_DRAWINFO_RECT,2 ]},{aInfo[ XBP_DRAWINFO_RECT,3 ],aInfo[ XBP_DRAWINFO_RECT,2 ] } )
V1.9x kann ich leider nicht so einfach wieder aktivieren... Habe mich entschlossen voll auf die V2 zu setzen.

Re: Browses

Verfasst: Di, 04. Nov 2014 9:04
von Tom
Das war auch ein bisschen getrickst/gerätselt, da aInfo[XBP_DRAWINFO_RECT] den Bereich zurückliefert, in dem gezeichnet werden darf, aber nicht die tatsächlichen Abmessungen der Zelle. Diese liefert aInfo[XBP_DRAWINFO_AREA]:CellRect(aInfo[XBP_DRAWINFO_ITEM]). So wäre es richtig:

Code: Alles auswählen

METHOD XbpBrowseCustom:CustomDrawCell( oPS, aInfo )
LOCAL ...
LOCAL aRect := aInfo[XBP_DRAWINFO_AREA]:CellRect(aInfo[XBP_DRAWINFO_ITEM])

...

GraLine( oPs, { aRect[1], aRect[2]}, {aRect[3], aRect[2] })
Den Offset von 3 Pixeln hatte ich interpoliert.

Re: Browses

Verfasst: Di, 04. Nov 2014 9:56
von Tom
Am Rande: Bei der Beschreibung von Tils Vortrag im Rahmen der "Xbase-Tracks" in Frankfurt zum Thema "Verwendung der WebUI in Desktop-Anwendungen" steht wortwörtlich:

Vergessen Sie die bisher dagewesenen Möglichkeiten, Steuerelemente mit Hilfe des Owner-Drawing-Merkmals, Windows GDI oder der Xbase++-Grafics Engine zu visualisieren.

http://www.alaska-software.com/conferen ... ssions.cxp

Tatsächlich glaube ich kaum, dass mir die WebUI all das ermöglicht, was ich inzwischen mit Ownerdrawing schaffe, was übrigens längst nicht mehr nur aus "aufgebohrten" Browses besteht, die flexibel alle möglichen gemischten Daten darstellen können, sondern auch aus komplett eigenen Controls, die mal simple Statics waren. Ownerdrawing bedeutet, dass im Moment des Zeichnens entschieden wird, was wie zur Darstellung kommt, und zwar sogar unabhängig von der Datenquelle (wodurch ein "InvalidateRect" plötzlich viel mächtiger wurde als ein "RefreshAll", das übrigens im ungünstigen - also normalen - Fall deutlich langsamer ist). Die WebUI zieht diese Entscheidung wieder zurück zur Datenquelle. Das kann ein Fortschritt sein, muss es aber nicht. Was mich ärgert: Dass mir vor wenigen Jahren ein Merkmal als bahnbrechend verkauft wurde, mit dem ich mich, vorsichtig gesagt, sehr intensiv auseinandergesetzt habe, um mir nun zu erklären, dass ich die viele Arbeit, die ich da investiert habe, "vergessen" soll. Das werde ich mitnichten tun. Aber ich setze mich natürlich trotzdem mit der WebUI auseinander. Schade finde ich, dass es offenbar keine Verbesserungen am Rendering der GRA-Engine gab, das ziemlich lachhaft ist. Antialiasing oder ähnliches hat da nie funktioniert, und auch die "Precision"-Parameter liefen immer ins Leere. Ein Kreis war da nie ein Kreis. Und er ist auch mit der 2.0 keiner. :cry:

Re: Browses

Verfasst: Di, 04. Nov 2014 10:10
von Jan
Hallo Tom,

als ich mich vergangenes Jahr auf meinen Forentreffen-Vortrag zur Workbench vorbereitet habe, hatte ich ein intensives Gespräch mit Steffen. In dem er mir erklärte, das die HTML-Elemente kommen sollen. Der dbf-Viewer in der Workbench ist schon so ein HTML-Element. Das wichtige an der Sache ist: Steffen hat auf meine Anfrage dazu betont, das die XBParts inkl. OwnerDrawing bestehen bleiben werden, HTML aber dazu kommen soll

Du solltest also (hoffentlich!) Investitionsschutz genießen. Wobei mich an der ganzen Sache unglaublich ärgert, das der Code im XbpBrowse gebrochen wurde. Und Alaska es nicht hinbekommt, das zu korrigieren.

Jan

Re: Browses

Verfasst: Di, 04. Nov 2014 10:45
von Tom
Hartmut Mehdorn hat ja vergleichbare Probleme. :wink:

Die Komplexität ist auch nicht zu unterschätzen. Browses sind komplexe Controls, die aus vielen Elementen bestehen und sehr eigen auf Nachrichten reagieren. Wir, die Entwickler, die mit Browses arbeiten, experimentieren schon seit Jahren und Jahrzehnten damit herum, um Verbesserungen zu ermöglichen, das Look and Feel zu verschönern usw. Ich habe schon Dutzende Varianten von Präsentationsparametern gesehen, die ich für falsch gehalten habe, die aber funktionierten, und zig sehr originelle Ansätze im Bereich Ownerdrawing. Es gibt in meinen Anwendungen Browses, die keiner von Euch als Browses identifizieren könnte. :wink: Das alles arbeitet mit dem grundsätzlichen Eventhandling, dem eigenen Eventhandling, dem in einem separaten Thread laufenden UI-System, möglicherweise vorhandenen visuellen Stilen und vielen anderen Komponenten zusammen, nicht zuletzt mit Datenquellen. Es interagiert mit anderen Controls. Ein selbstgebautes Haus, das gewachsen ist, ohne dass man je den Schritt gewagt hätte, es abzureißen und neu aufzustellen: Der Fluch der Kompatibilität. Insofern habe ich ein gewisses Verständnis dafür, dass Neues auch Rückschritte enthält. Ich hätte das nicht anders erwartet. Ein Major-Update ohne zusätzliche Arbeit für die Entwickler wäre keines, oder? :wink:

Re: Browses

Verfasst: Di, 04. Nov 2014 18:36
von AUGE_OHR
satmax hat geschrieben:Wenn ich in Toms Beispiel folgendes ändere werden die Trennlinien wieder richtig dargestellt:
ah ... dann wurde wohl wirklich am "Frame" (XBP_DRAWACTION_DRAWFRAME) geschraubt und funktioniert jetzt in der v2.x "anderes" als in der v1.9x

Re: Browses

Verfasst: Di, 04. Nov 2014 19:45
von satmax
Tom hat geschrieben: Ein Major-Update ohne zusätzliche Arbeit für die Entwickler wäre keines, oder? :wink:
Hallo Jimmy, ich denke besser wie Tomm kann man das nicht ausdrücken. :D

Re: Browses

Verfasst: Sa, 15. Nov 2014 9:54
von Jan
Till hat gerade über die neue WebUI gesprochen. Das dürfte in zwei Schritten laufen.

Einerseits kann man HTML und CSS nutzen, um OwnerDrawing zu machen. Und dabei z. B. die (CSS-)Formatierung ausgliedern, so das eine saubere Trennung zwischen Logik und Optik entsteht. Die CSS kann man entweder über die .arc einbinden, oder extra mitliefern. Einbinden macht die Sache sicher, extern läßt dem Anwender die Möglichkeit, die Optik selber seinen Bedürfnissen anzupassen (oder auch zu zerschießen :-( ).

Zusätzlich gibt es die Möglichkeit, die gesamte Oberfläche in eine HTML umzubauen. Da ist Alaska aber noch nicht ganz fertig mit. Die wollen noch einen eigene Browser schaffen, mit dem man dann die Desktop-Anwendung als HTML ausgeben kann.

Grundsätzlich fehlt aber noch eine ganze Menge Doku und Samples. Vieles ist schon da, wird nur nirgends erwähnt. Macht die Arbeit nicht einfacher ...

Jan

Re: Browses

Verfasst: So, 16. Nov 2014 16:44
von Wolfgang Ciriack
nun müsste man mal die Werte von aInfo [ XBP_DRAWINFO_RECT ] von der v1.9x und der v2.x vergleichen ob die gleich sind. wenn ja sollte man mal testen ob jetzt XBP_DRAWACTION_DRAWFRAME ( OwendrawAdvance ) funktioniert ...
Die Werte in aInfo[XBP_DRAWINFO_RECT] sind schon unterschiedlich, in meinem Beispiel
1.9: [3,745,760,772]
2.0: [3,739,760,766], das heißt 6 Pixel Unterschied.