Michael Rudrich hat geschrieben:die CodePage??
hmm.. wieso gehts dann im Form Designer?
Ist sie da auf einmal vorhanden?
Merkwürdig...
keine Ahnung, frage ALASKA ...
Ohne Codepage geht "gar nichts" und bei den Presentation Parameter kann man ja "so" (Syntax) keine Codepage angeben, oder ?
am "einfachsten" ist das "live" zu sehen z.b. mit einem RbDown
Code: Alles auswählen
::oChina:rbDown := {| aPos, uNIL, oSelf | ChangeFont(SELF) }
STATIC PROCEDURE ChangeFont(oArtikel)
LOCAL OldFnt
LOCAL oFontDlg
LOCAL oFnt := NIL
OldFnt := oArtikel:oChina:setFont()
oArtikel:oChina:hide()
oFontDlg := XbpFontDialog():new(oArtikel) // Objekt erzeugen
oFontDlg:familyName := OldFnt:familyName
// Font-Dialog konfigurieren
oFontDlg:create() // Dialog anfordern
oFnt := oFontDlg:display() // Dialog aktivieren
Setappwindow(oArtikel)
Setappfocus(oArtikel)
IF oFnt <> NIL
MSGBOX("Font :"+LTRIM(STR(oFnt:nominalPointSize))+"."+;
oFnt:compoundName+CHR(13)+" Codepage :"+;
LTRIM(STR(oFnt:codePage)) )
oArtikel:oChina:setFont(oFnt)
ELSE
oArtikel:oChina:setFont(OldFnt)
ENDIF
oArtikel:oChina:configure()
// Daten neu einlesen
oArtikel:oChina:setdata()
oArtikel:oChina:show()
auch kann man bei dem Beispiel sehen das man erst den Font setzten muss VOR dem :setdata()
Ich habe, hier im Forum, auch beschrieben wie man das "live" auf eine XbpBrowse Columne anwendet.
aber zu deiner Frage ... wenn ich "raten" darf :
das was du als XbpSLE "siehst" ist nicht das womit XppFD "arbeitet"
XbpSLE ist ein "Wrapper" für ein Windows "Single-line-Edit", auch FlatEdit genannt, aus der Win API (Comctl32 v5.x bzw Mscomctl v6.x )
Leider "gibt" uns Alaska auch bei dem "Control" nicht alle "Fähigkeiten", welches die "neueren" API Versionen ja haben ...
wenn ich das "richtig" verstanden habe ist der wesentliche Unterschiede der API v5.x ANSI vs. v6.x UNIcode ?!
Diese "Umstellung" war wohl mit der SL1 geplant, wie "visual Style", was dazu gestrickt wurde,
aber wie auch bei den activeX XbParts wurden nicht "alle" Fähigkeiten (von Mscomctl.OCX) ausgenutzt. (Progressbar ... s.u.)
Die Codejock Controls (1/11) machen im Prinzip das selbe wie die M$ Controls. Auch die "Namen" der Methode und Property sind "meistens gleich"
Das Wissen habe ich nun auf das "Original" MsComCtl.OCX angewendet und die Demo´s hier im Forum veröffentlicht (Progressbar,Tabpage, Treeview, Listview)
Es ist also "im Prinzip" möglich ... und wenn es ein User schafft sollte es ALASKA doch auch "bringen" ...
p.s. XClass "nutzt" wohl auch "alle" Möglichkeiten des MsComCtl.OCX
Alle diese v6.x Controls sind UNIcode fähig, also wenn es dann nicht funktioniert muss es am (Xbase++) "Wrapper" liegen.
Dies ist auch ein Grund warum ich die Codejock Tools verstärkt einsetzte den in der registrierten Version bekommt man auch eine UNICode Version.
zusammen mit der HX_CLass (siehe Forum Wissensbasis) als "Wrapper" muss man theoretisch "nur" meine #Include HX_CLASS.CH einfügen
um die XbParts gegen die Codejock Controls "auszutauschen"
Damit wäre dann auch das Thema UNIcode "ready" bewältigt und ich muss nicht auf eine Lösung von ALASKA warten (XP Manifest / ArialUNI.TTF, NationMsg "locale" ... usw) die ich noch mit "chinesischem" OS() so habe ...