Browses
Moderator: Moderatoren
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2945
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Browses
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 ?
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 ?
Viele Grüße
Wolfgang
Wolfgang
Re: Browses
Hallo, Wolfgang
Mal sehen, wann da was wie kommt im September
das kann ich so bestätigen, der gleiche Code unter 1.9 funktioniertAuch das der Satzpointer nicht mehr mit dem hilited Satz synchron ist ist ein Showstopper.
Mal sehen, wann da was wie kommt im September
Grüße aus Berlin
Reiner
Reiner
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Browses
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2128
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Browses
Den Schalter gibt es längst:
wichtig auch
Code: Alles auswählen
navigationMode
Code: Alles auswählen
rowPhyPos
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2945
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Browses
Hallo Werner,
danke für den Hinweis.
@Jan,
funktioniert bei dir denn z.B. das Scrollen mit dem Mausrad richtig ?
danke für den Hinweis.
@Jan,
funktioniert bei dir denn z.B. das Scrollen mit dem Mausrad richtig ?
Viele Grüße
Wolfgang
Wolfgang
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Browses
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2945
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Browses
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
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
Viele Grüße
Wolfgang
Wolfgang
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2128
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Browses
Geht bei mir immer noch nicht (556)Wolfgang Ciriack hat geschrieben:@Jan,
funktioniert bei dir denn z.B. das Scrollen mit dem Mausrad richtig ?
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Browses
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
Da muß Alaska noch so einiges nacharbeiten ...
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: Browses
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 .
Uli
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Browses
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Browses
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.Wenn das korrigiert wird, und in dem Zug gleich die alten Fehler mit behoben werden, wäre ich durchaus zufrieden.
Herzlich,
Tom
Tom
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Browses
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Browses
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.
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.
gruss by OHR
Jimmy
Jimmy
- satmax
- 1000 working lines a day
- Beiträge: 831
- Registriert: Do, 02. Dez 2010 19:34
- Wohnort: Biberbach in Österreich
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 1 Mal
- Kontaktdaten:
Re: Browses
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...
fährst Du mit dem Cursor nach unten verschwindet die Zeilentrennung (der Strich), fährst mit dem Cursor wieder nach oben kommt sie wieder...
Gruß
Markus
Markus
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Browses
ah ... ja ...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...
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 ...
gruss by OHR
Jimmy
Jimmy
- satmax
- 1000 working lines a day
- Beiträge: 831
- Registriert: Do, 02. Dez 2010 19:34
- Wohnort: Biberbach in Österreich
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 1 Mal
- Kontaktdaten:
Re: Browses
Wenn ich in Toms Beispiel folgendes ändere werden die Trennlinien wieder richtig dargestellt:
V1.9x kann ich leider nicht so einfach wieder aktivieren... Habe mich entschlossen voll auf die V2 zu setzen.
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 ] } )
Gruß
Markus
Markus
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Browses
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:
Den Offset von 3 Pixeln hatte ich interpoliert.
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] })
Herzlich,
Tom
Tom
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Browses
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.
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.
Herzlich,
Tom
Tom
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Browses
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Browses
Hartmut Mehdorn hat ja vergleichbare Probleme.
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. 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?
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. 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?
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Browses
ah ... dann wurde wohl wirklich am "Frame" (XBP_DRAWACTION_DRAWFRAME) geschraubt und funktioniert jetzt in der v2.x "anderes" als in der v1.9xsatmax hat geschrieben:Wenn ich in Toms Beispiel folgendes ändere werden die Trennlinien wieder richtig dargestellt:
gruss by OHR
Jimmy
Jimmy
- satmax
- 1000 working lines a day
- Beiträge: 831
- Registriert: Do, 02. Dez 2010 19:34
- Wohnort: Biberbach in Österreich
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 1 Mal
- Kontaktdaten:
Re: Browses
Hallo Jimmy, ich denke besser wie Tomm kann man das nicht ausdrücken.Tom hat geschrieben: Ein Major-Update ohne zusätzliche Arbeit für die Entwickler wäre keines, oder?
Gruß
Markus
Markus
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Browses
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2945
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 14 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Browses
Die Werte in aInfo[XBP_DRAWINFO_RECT] sind schon unterschiedlich, in meinem Beispielnun 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 ...
1.9: [3,745,760,772]
2.0: [3,739,760,766], das heißt 6 Pixel Unterschied.
Viele Grüße
Wolfgang
Wolfgang