Andere Zeichensätze

[brandelh]

Die Speicherung unter UTF8 scheitert schon daran, dass offensichtlich sowohl GetData() als auch EditBuffer() einen Unicode
String (falls man den per Hand eingeben kann) genauso wie die Eingabe über die Zwischablage sofort auf ANSI / OEM umwandelt.
Sonst kann ich mir das nicht erklären was wir erlebt haben

PS: da der XppFD nicht so reagiert, muss dieser entweder mit einer wesentlich neueren Xbase++ Version oder mit einem anderen Produkt erstellt worden sein

[Martin Altmann]

PS: da der XppFD nicht so reagiert, muss dieser entweder mit einer wesentlich neueren Xbase++ Version oder mit einem anderen Produkt erstellt worden sein

Letzteres!

Viele Grüße,
Martin

[Michael Rudrich]

also wenn das der Fall ist, daß der Form Designer mit einem anderen Produkt
erstellt wurde --
Das haut dem Faß den Boden weg...

Ich mein: Das was der Designer kann sollte das generierte Programm auch genauso machen, oder
gebt Ihr mir da nicht recht??

Wäre interessant zu wissen was Alaska dazu sagt - ich darf sie aber leider nicht fragen...

Gruß
Michl

[Manfred]

Hi Michael,

sprech doch mal Friedhelm Göder an, der hat doch einen kompletten Designer neu geschrieben, mit allem Pfurz und Feuerstein.

[Martin Altmann]

Hallo Michl,
wieso darfst Du Alaska nicht fragen? Bist Du zur Persona non grata degradiert
Fragen darfst Du bestimmt, warum denn auch nicht?

Viele Grüße,
Martin

[Michael Rudrich]

so ungefähr..

Roger hatte mit Til zu tun, hat ihm dann geschrieben daß er sich an mich wenden kann wegen
Tests, da ich die richtige Systemumgebung habe, -- worauf Til ihm geantwortet hat daß sie
von mir seit 2002 nichts mehr gehört haben.. (klar, denn es war ja auch mein Geist der auf
der DevCon drei Sessions gehalten hat..) ) und daß ich meine Subskiption nicht verlängert
habe..

GRuß
Michl

[brandelh]

PS: da der XppFD nicht so reagiert, muss dieser entweder mit einer wesentlich neueren Xbase++ Version oder mit einem anderen Produkt erstellt worden sein

Letzteres!
Viele Grüße,
Martin

Allerdings hat er den selben Dateianfang wie die selbst erstellten EXE Dateien und moniert eine fehlende XPPRT1.DLL sowie weitere DLL Dateien.

War es nicht VX, das eingekauft wurde ?
Die XbParts sehen ja im FD genauso aus wie im späteren Programm ...

[Michael Rudrich]

Hi..
ich bin mir eigentlich auch ziemlich sicher, daß er in XBase geschrieben ist...
deshalb wunderts mich ja umso mehr daß er im RUN Mode das richtig kann und im
generierten Prg dann nicht mehr..

Gruß
Michl

[Manfred]

Halt Stopp,

hatten wir da nicht im August in OS drüber diskutiert? Ja sicher ist der in purem Xbase geschrieben.

[Jan]

Der Formdesigner ist in Xbase++ geschrieben, VX in Delphi von nach Zypern abgetauchten Ukrainern (oder sowas).

Jan

[AUGE_OHR]

ich habe eben mal probiert "10.Arial Unicode MS" als Schriftart einem SLE zuzuordnen (Win XP SP3).

Code: Alles auswählen

oSle := XbpSLE():new( drawingArea, , {12,48}, {288,36},;
                         { { XBP_PP_BGCLR, XBPSYSCLR_ENTRYFIELD },;
                            { XBP_PP_COMPOUNDNAME, "10.Arial Unicode MS" } } )
oSle:bufferLength := 66
oSle:tabStop := .T.
oSle:create()

diese Funktion gibt auch genau diesen Fontnamen zurück:

oXbp:activate := {|| msgbox(oSle:setFontCompoundName()) }

... vielleicht mache ich da aber auch was falsch.

es fehlt die Codepage und das geht dann nicht "so".
... später mehr ...keine Zeit jetzt...

[Michael Rudrich]

die CodePage??

hmm.. wieso gehts dann im Form Designer?
Ist sie da auf einmal vorhanden?

Merkwürdig..

- Michl

[AUGE_OHR]

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 ...

[Michael Rudrich]

keine Ahnung, frage ALASKA ...

Witzig !

aber zu deiner Frage ... wenn ich "raten" darf :
das was du als XbpSLE "siehst" ist nicht das womit XppFD "arbeitet"

Soso -

es mag sein daß Alaska uns nicht alle Fähigkeiten des API Controls gibt.. das ist mir eigentlich auch relativ schnuppe..
alles was ich will ist in das Control das einzugeben, was andere 'wrapper' dieses Controls auch erlauben -und sogar der
"Wrapper" den Alaska beim Formdesigner selber nutzt..

- Michl

[brandelh]

Hallo Jimmy,

aber ein XbpSLE (bzw. das M$ SLE darunter) ist doch kein common control !

Intern werden ja meist nur API Funktionen aufgerufen. Davon gibt es Ansi und Unicode Versionen.
Solange also z.B. bei der Konvertierung von DBF/ANSI (geht ja automatisch) bzw. anderen
internen Aufrufen immer nur die ANSI Version benutzt wird, kann es auch nicht richtig gehen.

Ich denke ohne durchgängige UNICODE Unterstützung wird das mit den internationalen Zeichen nicht sauber funktionieren
(also nicht besser als heute, wo man immer ANSI + CODEPAGE braucht).
Allerdings habe ich auf meiner Tastatur nicht die Möglichkeit wirklich interessante Zeichen einzutippen und die ALT+xxxx Methode geht nur bei den normalen Zeichen, die sowieso zur Verfügung stehen.
Vom Aussehen des Fonts scheint es aber schon so, dass tatsächlich der Arial Unicode MS verwendet wird.

Das würde z.B. auch erklären, warum du auf einem chinesischen OS mit dieser Tastatur schöne Zeichen bekommst, aber keine deutschen Umlaute. Intern verwendet das Programm dann wahrscheinlich ANSI China

[Koverhage]

Hallo Hubert,

Du kannst doch über OSK (Bildschirmtastatur) alles eingeben was Du möchtest, Nur die verwendete Sprache einstellen,
dann erscheinen die Buchstaben auf der Tastatur.

osk.jpg (57.5 KiB) 8276 mal betrachtet

[brandelh]

Hallo Klaus,

die ist mir jetzt auch neu. Aber auch mit 106 Tasten bekomme ich keine chinesischen Schriftzeichen.

[Michael Rudrich]

Zur EIngabe von Chinesischen Schriftzeichen:
Einfach Systemsteuerung - Regions und Sprachoptionen - Sprachunterstützung fpr Chinesisch einstellen und
dann in der Taskleiste jeweils umstellen

- MIchl

[Koverhage]

Hubert,

habe ich auch erst in der aktuellen CHIP gelesen das es dieses Teil gibt.
Aber das gibt schöne Möglichkeiten, wenn man z.B. Wingdings einstellt, sieht man die Symbole auf der Tastatur und kann
die dann direkt eingeben (per Mausklick) und schreibst aber mit Deiner Tastatur weiter wie gewohnt.

[Ewald]

@ Jan,
damit habe ich schon einige Monate verbracht und bin immer noch nicht am Ende.
Ich habe mal vor Monaten das Thema Fontobjekte im Browse hier angefangen.
Was du hier siehst ist eine ganz normale DBFNTX. Der gesamte Quellcode dazu war in ein paar Zeile Express++ geschrieben. So wie es darin steht läßt es sich auch drucken.
Nur mit der Einabe hader ich noch ein wenig. Es sind alles Zeichen > chr(127). Und da kann man Tastaturen anschließen wie man will, die bewegen sich alle < chr(127). Ich habe das damals über die Zwischenablage eingefügt.
Im Moment schreibe ich mir eine Funktion, die die Tastaturcodes umsetzt. Nach dem Motto, wenn ich den kyrillischen Zeichensatz habe und auf das "a" drücke, möchte ich gerne das Zeichen für chr(147) in der Variable bzw. in der Datenbank stehen haben. Ich habe mir Testweise eine kyrillisch Tastatur zugelegt und war ganz erstaunt, dass eingentlich nur die Zeichen auf den Tasten anders sind, die Auswirkung aber die gleiche wie bei einer deutschen Tastatur ist. Irgendwo hatte ich gewünscht, dass da ein Knopf dran ist, der bewirkt, dass so eine Tastatur die Zeichen über chr(127) schreibt.
Warum das übrigens mit den Formulardesigner im Testmodus funktioniert konnte mir vor einem Jahr auch niemand beantworten - komisch komisch.

Gruß
Ewald

[AUGE_OHR]

aber ein XbpSLE (bzw. das M$ SLE darunter) ist doch kein common control !

ich denke schon ... was den sonst ?

Das würde z.B. auch erklären, warum du auf einem chinesischen OS mit dieser Tastatur schöne Zeichen bekommst, aber keine deutschen Umlaute. Intern verwendet das Programm dann wahrscheinlich ANSI China

Ja das wäre die Erklärung. Ich glaube zwar das ich mit ConvToXXXX() ausprobiert habe, aber ich werde es nochmals testen.

[Michael Rudrich]

@ Ewald...

und wie machst Du daß das so stehen bleibt wenn Du aus der Zwischanablage kopierst?
Wenn ich chinesische Zeichen kopiere, dann stehen ?? im Feld
Es sei denn ich stelle mein Windows so um daß alle nicht Unicode fähigen Programme in chinesisch anzeigen
Dann geht es

- Michl

[AUGE_OHR]

@ Ewald...
und wie machst Du daß das so stehen bleibt wenn Du aus der Zwischanablage kopierst?
Wenn ich chinesische Zeichen kopiere, dann stehen ?? im Feld

ich heisse zwar nicht Erwald aber probier mal folgendes

SHANGhai.JPG (126.87 KiB) 8165 mal betrachtet

danach Wordpad (Write) öffnen und "einfügen". achte dabei mal auf die Font Einstellung wenn es eingefügt ist.

[Michael Rudrich]

bei mir steht SimSun drin ...
und die Zeichen werden auch dargestellt..
es kann dann aber kein öäüß mehr - logo, denn das sind chars > 127
Die Frage ist wie andere es machen in ein EINZIGES SLE sowohl als auch einzugeben..

. Michl

[brandelh]

Hi,

Zeichen von 0 bis 255 können per Tastatur locker eingegeben werden (entweder direkt z.B. äöü oder per ALT+xxxx).
Erst darüber gibt es laut der "Zeichentabelle" keine direkte Eingabemöglichkeit mehr.
Allerdings sind auch in ANSI nur die ersten 127 Zeichen (= 7 Bit ASCII) immer gleich (auch in Unicode),
danach kommt es auf die Codepage an. Die meisten ANSI Tabellen kennen deutsch Umlaute (auch wenn die für was
anderes gelten ...) und damit fällt es nicht auf, aber wenn nicht, dann kommt halt ein anderes Zeichen.

Erst bei reiner Unicode Darstellung (also ohne ANSI Konvertierung) wird sich das erledigt haben.