Codejock SkinFramework & SL1 - bitte PDR "boosten"!

[Tom]

Es gibt nach Aussage des Alaska Supports "Inkompatiblitäten", wenn man Xbase 1.9 SL1 und das Codejock SkinFramework zum "Skinnen" einer Applikation benutzt. Diese "Inkompatiblitäten" haben übrigens nichts damit zu tun, dass in SL1 unter Windows 7/Vista u.U. falsche Hintergrundfarben bei Checkboxen, Radiobuttons und 3-State-Boxen erscheinen - obwohl exakt dieselben Parts betroffen sind.

Wie auch immer. Der Support hat mir mitgeteilt, dass man den Fehler nicht beheben wird, solange nicht genug Entwickler davon betroffen sind. Also möchte ich diejenigen, die das betrifft, darum bitten, den entsprechenden PDR zu "boosten". Danke.

http://www.alaska-software.com/scripts/ ... PDRID=6335

[Jan]

Ähm, wie bitte? Ich habe das ja noch nicht einmal verstanden, das ein Fehler im Datenbanktreiber, der wirklich massiv ist, seit 3 Jahren nicht korrigiert wurde, nur weil ich als Begründer der PDR keine technische Unterstützung habe. Aber wenn das wirklich die Begründung ist (Subscription ohne technische Unterstützung), dann müsste doch bei jemandem, der diese gekauft hat, das sofort behoben werden.

Oder habe ich da irgendwo einen Gedankenfehler?

Jan

[Manfred]

So wie ich das jetzt auf den ersten Blick sehe, geht es um Codejock. Und warum sollte Alaska sich darum kümmern, das ein Zusatztool klappt, solange Xbase++ klappt? techn. Support hin oder her. Der gilt nun mal nicht für Probleme im Zusammenhang mit Fremdprodukten. Das jetzt zu Deiner Frage.
Ansonsten finde ich es auch albern, wie da reagiert wird. (so wie ich es jetzt verstehe)

Weiterhin denke ich aber auch jetzt, dass die Idee von Tom auch nicht weiter hilft. Wir könnten jetzt alle Boosten und Alaska denkt sich dann auch: "Watt soll der Sch....." das glauben wir eh nicht.

[Tom]

Hallo, Jan.

Der "Gedankenfehler" ist m.E. nicht bei Dir vorhanden, sondern anderswo. Aber, ja - so, wie Du es schilderst, sollte es sich wohl darstellen.

Die beigefügte "SKINTEST.PRG" veranschaulicht das Problem (benötigt wird Codejock SkinFramework und der "office2007"-Stil). Das Problem tritt unter Vista und Windows 7 mit aktiviertem "Aero-Theme" (und davon abgeleiteten) auf. Die Screenshots zeigen das Fehlverhalten nach der Betätigung des "Skin"-Buttons.

[Tom]

Hallo, Manfred.

Dieses "Zusatztool" nutzt nur eine Funktionalität, die in Windows seit XP sowieso zur Verfügung steht. Diesen Effekt kann man unter Xbase auch mit anderen "Skinning-Tools" sehen. Der Fehler liegt also nicht bei denen, sondern in Xbase++. Meines Erachtens tritt dieser "Schwarzer-Hintergrund-Effekt" auch in Zusammenarbeit mit anderen Active-X-Komponenten auf. Manchmal wird da eine falsche Hintergrundfarbe "durchgereicht".

[Martin Altmann]

Moin,
das Verhalten war doch auch bei normalen XP, Bonbonstil und Xbase++ aufgetreten, wenn die Owner bei Radiobuttons nicht stimmten!
Ist das hier vielleicht auch so?

Viele Grüße,
Martin

[Tom]

Hallo, Martin.

Das war auch meine Vermutung, aber angeblich hat das nichts miteinander zu tun. Für die falschen Hintergrundfarben, die aus anderen Gründen bei Checkboxen, Radiobuttons und 3-States auftreten können, gibt's einen eigenen PDR (6333), für den es intern auch schon einen Hotfix gibt, der im nächsten Rollup enthalten sein soll. Dieser fixt aber nicht das Problem u.a. mit dem SkinFramework.

[Wolfgang Ciriack]

Habe gerade dafür gevoted, allerdings ist meine Subscription im April abgelaufen (man bekommt ja auch keine Info von Alaska, dass man sie erneuern müsste), daher müsste ich fast den Neupreis bezahlen und warte daher, bis Alaska mal wieder etwas Neues interessantes bringt. Somit weiss ich nicht, ob meine Stimme da zählt.

[Herbert]

Ja, da "verliert" Alaska viel Geld. Mir gings genau so.

[AUGE_OHR]

Es gibt nach Aussage des Alaska Supports "Inkompatiblitäten", wenn man Xbase 1.9 SL1 und das Codejock SkinFramework zum "Skinnen" einer Applikation benutzt.

aha ... das ist ja "neu" das die SL1 so was schlimmes tut ...

Diese "Inkompatiblitäten" haben übrigens nichts damit zu tun, dass in SL1 unter Windows 7/Vista u.U. falsche Hintergrundfarben bei Checkboxen, Radiobuttons und 3-State-Boxen erscheinen - obwohl exakt dieselben Parts betroffen sind.

aha ... und welche "Farbe" sollten die haben ... ?
Skinframework wählt ein anderes Theme und damit einen anderen visual Style und damit hat Xbase++ SL1 ein "Problem".
Xbase++ versucht an solchen Stellen den GraBackground() zu finden den Alaska bei den 3 XbParts falsch als visual Style definiert.

Wie auch immer. Der Support hat mir mitgeteilt, dass man den Fehler nicht beheben wird, solange nicht genug Entwickler davon betroffen sind. Also möchte ich diejenigen, die das betrifft, darum bitten, den entsprechenden PDR zu "boosten". Danke.

so so ... ich "booste" seit 2 Jahren an dem Thema und nun kommt Alaska und meint man müsse erst "genügend" Votes haben ?

DAS IST EINE FRECHHEIT

Alaska hatte mehrfach "betont" das es Codejock unterstützen wird und wenn Codejock "Fehler" von Xbase++ aufdeckt dann merkt man erst das Xbase++ nicht "über den Tellerrand" sieht.
vom Skinframework ist auch Ownerdraw Menu betroffen, aber das weiss Alaska ja auch erst seit 2 Jahren ...

http://www.alaska-software.com/scripts/ ... PDRID=6335

hab "geboosted"

[AUGE_OHR]

... Also möchte ich diejenigen, die das betrifft, darum bitten, den entsprechenden PDR zu "boosten". Danke.
http://www.alaska-software.com/scripts/ ... PDRID=6335

nicht nur die sondern auch alle anderen möchte ich bitten dafür zu voten.

ich "denke" das der Hintergrund des BUGs der selbe ist, wie der für die Probleme mit "Transparenz"
GraBackground() würde ich gerne mit Ownerdraw verwenden aber da bekommt man, gerade mit "Transparenz", oft nur ein schwarzes Rechteck

ideal wäre es natürlich wenn Alaska, bei der Behebung der BUGs in "visual Style", auch gleich die DWM Funktionen für Win7 Aero integrieren würde ...

[Tom]

Hallo, Jimmy.

Man erklärte mir - irgendwann im Frühherbst des vergangenen Jahres -, dass die beiden Probleme nichts miteinander zu tun hätten, und dass das von Dir genannte im nächsten Hotfix-Rollup behoben sei.

[psp]

auch ohne Codejock können wir die schwarzen Objekte hervorrufen

[adrian]

Wir hatten auch solche Phänome bei Kunden, doch ohne Codejock, nach löschen der Manifest-Datei wurde alles wieder korrekt dargestellt.

adrian

[AUGE_OHR]

... nach löschen der Manifest-Datei wurde alles wieder korrekt dargestellt.

Manifest-Datei -> XP "visual Style" ...

Man erklärte mir - irgendwann im Frühherbst des vergangenen Jahres -, dass die beiden Probleme nichts miteinander zu tun hätten, und dass das von Dir genannte im nächsten Hotfix-Rollup behoben sei.

wenn es (endlich) behoben wird dann ist ja alles gut ...

die ganze "visual Style" Geschichte ist ja nicht erst seit Codejock sondern wurde ausgiebig in der "beta" Phase von mir "an-gemeckert".
besonders die "schwarzen" Rechtecke hat man sofort bemerkt und in der nächsten "beta" dann behoben.

mit Codejock Skinframework bekommt die Xbase++ Application aber sein "eigenes Theme"
und das wird nicht immer beachtet und statt dessen erhält man den "System visual Style" mit GraBackground()

Codejock Skinframework "fordert" also die "gesamte" Integration (voller API Umfang)
von "visual Style" statt "nur" eine Anpassung an die (paar) XbParts damit man es "voll" nutzen kann.

also warten wir auf den Hotfix-Rollup um zu sehen ob die Jungs von Alaska nun ihren Job vollendet haben
und man nun auch Ownerdraw mit "eigenem Skin" verwenden kann.

[AUGE_OHR]

hi,

ich denke ich habe PDR 6335 mit Skinworkframe und Checkbox gelöst

CJ_Checkbox_OK.PNG (15.39 KiB) 6833 mal betrachtet

nun hatte ich in anderen Programmen noch die schwarzen Checkbox ... was ist der Unterschied

Antwort : Der Class Code von der funktionierenden Version wurde vom Formdesigner generiert .

hm ... und wo ist nun der Unterschied ?

Code: Alles auswählen

   ::CheckBox1    := XbpCheckBox():new( ::drawingArea, , {32,100}, {100,20}, { { XBP_PP_BGCLR, -255 } } )

der Formdesigner gibt Presentation Parameter an !
ich habe also bei den anderen Programmen die XbpCheckbox() um XBP_PP_BGCLR erweitert und damit funktioniert es

p.s. habe es noch nicht mit Radio Buttons versucht.

[AUGE_OHR]

so nun hab ich mir auch die Radiobutton vorgenommen.

Code: Alles auswählen

   ::Static1      := XbpStatic():new( ::drawingArea, , {28,12}, {128,64}, { { XBP_PP_BGCLR, -255 } } )
   ::Static1:caption := "Gruppe"
   ::Static1:clipSiblings := .T.
   ::Static1:type := XBPSTATIC_TYPE_GROUPBOX

   ::RadioButton1 := XbpRadioButton():new( ::Static1, , {4,24}, {120,20} )
   ::RadioButton1:caption := "Radiobutton"
   ::RadioButton1:selection := .T.
   ::RadioButton1:tabStop := .T.
   ::RadioButton1:selected := {|| NIL }

   ::RadioButton2 := XbpRadioButton():new( ::Static1, , {4,4}, {120,20} )
   ::RadioButton2:caption := "Radiobutton"
   ::RadioButton2:tabStop := .T.
   ::RadioButton2:selected := {|| NIL }

das produziert der Formdesigner.

wenn man da nun, mit Codejock Skinframework, ein Theme lädt bekommt man Problem mit der Optik der RadioButtons.
also dachte ich mir, wie bei XbpCheckBox(), doch mal an die RadioButtons einen Presentation Parameter anzuhängen

Code: Alles auswählen

   ::RadioButton1 := XbpRadioButton():new( ::Static1, ,{4,24}, {120,20}, { { XBP_PP_BGCLR, -255 } } )

oder direkt auf der ::drawingArea

Code: Alles auswählen

   ::RadioButton1 := XbpRadioButton():new( ::drawingArea, , {4,24}, {120,20}, { { XBP_PP_BGCLR, -255 } } )

aber es gibt bei beiden schwarz

und nun die Lösung (?)

Code: Alles auswählen

   ::Static1      := XbpStatic():new( ::drawingArea, , {28,12}, {128,64} )
   ::Static1:caption := "Gruppe"
   ::Static1:clipSiblings := .T.
   ::Static1:type := XBPSTATIC_TYPE_GROUPBOX
// oder auch
// ::Static1:type := XBPSTATIC_TYPE_TEXT

   ::RadioButton1 := XbpRadioButton():new( ::Static1, , {4,24}, {120,20} )
   ...
   ::RadioButton2 := XbpRadioButton():new( ::Static1, , {4,4}, {120,20} )

also hier darf der Parent ::Static1 KEIN Presentation Parameter haben damit es mit SkinFrameWork passt...

bitte um Rückmeldung ob die PDR 6335 noch weiter Problem macht, Danke.

[Armin]

Hallo Wolfgang,

(man bekommt ja auch keine Info von Alaska, dass man sie erneuern müsste)

Wir haben gerade eine Info bekommen, dass wir erneuern sollten...

Gruß, Armin