locked
Speichern von vereinzelt griechischen Buchstaben zwischen lateinischen wie das 'ω' in Tabellen RRS feed

  • Frage

  • Hallo,

    in der Chemie gibt es vereinzelt Verbindungen in denen auch griechische Buchstaben wie z. B. das kleine Omega ω verwendet werden: " α, ω-dihydroxypoly ... "

    Das α kann ich durch a ersetzen, beim ω wird es schon schwieriger (z.B. omega).

    Access nimmt diese Sonderzeichen. FoxPro (9.2) nicht. Mache ich etwas falsch oder geht es prinzipiell nicht. Was ist bei anderen Datenbanken anders.

    Vielen Dank für jede Antwort

    Gruß Heinrich

    Mittwoch, 10. April 2013 11:10

Alle Antworten

  • Das ist ein Zeichensatzproblem.

    Foxpro arbeitet nicht mit Unicode, sondern ANSI-Codepages. Es ist daher nicht unmöglich aber etwas umständlich, griechische Buchstaben mitzubenutzen.

    Was man für griechische Buchstaben braucht ist vor allem ein Zeichensatz, der verschiedene sogenannte Skripte enthält, Arial ist so einer.

    Starte VFP, und tippe im Befehlsfenster:

    _screen.FontCharSet=

    Nach dem gleich tippe noch ein Leerzeichen, dann dürfte Intellisense "Font Picker" anbieten, click dahin, dann kommt der Fontauswahldialog. Wähle Arial als Schriftart, danach kannst Du unten in dem Dialog ein Skript wählen. Arial hat alles mögliche von Arabisch bis Vietnamesisch.

    Für griechisch wird bei mir unter Vista dann letztlich _screen.FontCharSet = 161 eingestellt. Danach ist chr(225) dann z.B. das kleine Alpha und ? chr(225) schreibt also ein alpha auf den Screen. Formulare haben diese Eigenschaft FontCharSet auch, daneben außerdem die Controls, Textbox, z.B.

    Die Codepage kann man bei Erstellung einer DBF angeben, FontCharSet nicht, insofern kannst man zwar auch griechische Buchstaben speichern, aber allein an der Codepage der DBF und den Daten darin wird nicht ersichtlich, welches FontCharSet genutzt werden muss, um die Daten wieder so anzuzeigen, wie sie gemeint sind.

    Das vergleicht sich etwa damit, den Font "Symbols" zu nutzen, dann kriegt man dieselbe Anzeige auch nur mit dem Symbols Font, den Daten/Bytes sieht man das aber nicht an.

    Arbeiten mit Unicode ist insofern bequemer und eineindeutiger, man ist dann nur auf Unicode Fonts angewiesen - nur kannst Du das unter Foxpro vergessen.

    Tschüß, Olaf.


    Olaf Doschke (Setmics)

    Donnerstag, 11. April 2013 13:25
  • vielleicht ist da was Hilfreiches bei:

    http://www.west-wind.com/presentations/foxunicode/foxunicode.asp

    Gruß,

    Winfried

    Donnerstag, 11. April 2013 13:59
  • Hallo Olaf,

    vielen Dank für die Tipps. Nach ausführlichen Tests, die Anzeige funktioniert auch problemlos in Verbindung mit FontCharSet und Listboxen. War schon sehr euphorisch, nur habe ich nicht daran gedacht, dass beim griechischen Zeichensatz die deutschen Umlaute fehlen. Auch habe ich den Export (ferngesteuert) nach Excel nicht lösen können. Da meine Anwendung auf sehr vielen und unterschiedlichen Masken mit vielen Exportfunktionen aufbaut, habe ich mich entschlossen die Finger davon zu lassen und die griechischen Buchstaben, sofern notwendig, lateinisch auszuschreiben. Der Gedanke an zu spät erkannte Problemen war zu groß.

    Noch eine Frage die mich schon länger beschäftigt und als Antwort wirklich ganz unverbindlich: Wie lange (Jahre) werden die Foxpro-Anwendungen unter neuesten Windows-Versionen noch laufen?

    Kann es sein, viele Foxpro-Entwickler wurden ja quasi auf die Straße gesetzt, dass die, oder eine andere Softwareschmiede, doch noch ein System entwickeln, mit dem man seine vielen Masken einschließlich viel dBase-Code, ohne grundsätzliche Neuprogrammierung, mit vertretbarem Änderungsaufwand und natürlich in der dBase-Sprache (mit integrierter Datenbank) weiterverwenden bzw. in das neue System transportieren kann.

    Oder ist dies hierfür das falsche Forum. Es gibt ja auch Händler die mit Bedauern sagen, dass sie ein Produkt nicht mehr liefern können und trotzdem einen Hinweis bzw. eine Ersatzteiladresse für ein Produkt, ein Projekt, in dem sehr viel Arbeit steckt, liefern. Halte dies immer noch für besser als alles mit sehr viel Frust und schlechtem Nachgeschmack in den Müll zu werfen.

    Nochmals vielen Dank und beste Grüße

    Heinrich

    Sonntag, 14. April 2013 17:01
  • Hallo Winfried,

    vielen Dank für den Link. Wie bereits Olaf geantwortet, habe ich vorerst auch in Anbetracht deutscher Umlaute und meiner vielen unterschiedlichen Exportfunkton nach Excel die Finger davon gelassen. Totzdem werde ich mir in Ruhe die Beschreibungen von Rick Stahl zu Gemüte führen um endlich die Zusammenhänge / Verhaltensweisen mit Codepage, strconv() u. a. besser zu verstehen.

    Nochmals vielen Dank und beste Grüße

    Heinrich

    Sonntag, 14. April 2013 17:21
  • Wenn Du aus meinem Forumsnamenszusatz "Microsoft Community Contributor" schließt, ich sei ein Microsoft Mitarbeiter, dann liegst Du falsch, aber kein Problem.

    Was ich aber als ehemaliger MVP und auch ohne Microsoft Insiderwissen sagen kann, ist, das da von Microsoft Seite der Wegweiser zu Visual Studio und MS SQL Server geht und das Produkt nicht zur Weiterpflege oder Neuauflage verkauft wurde. Es steckt darin Softwaretechnik, die auch in SQL Server floss, das war z.B. ein Argument, was gegen die Offenlegung der Sprache und speziell der interna steckt.

    Es gibt ein paar Ansätze Foxpro neu nachzuempfinden, aber der Markt dazu ist so klein, deswegen hat sich ja wohl VFP9 schon so zäh verkauft, dass MS es eben eingestellt hat.

    Es gibt noch dBASE selbst. Wenn Du daher kommst, ist das vielleicht etwas für Dich. Das ganze ist nun unter der Regie einer kleinen Firma namens dBase LLC, nicht mehr von Ashton-Tate, die ja '91 von Borland geschluckt wurden, die wiederum selbst vor sich hindümpeln, sich zwischenzeitlich mal Inprise nannten und nun eine Tochterfirma von Micro Focus sind, was aber wohl kaum einer kennt.

    Die xBase Ecke sieht insgesamt keiner rosigen Zukunft entgegen.

    Wenn Du schon Excel-Automation ansprichst, was spräche denn gegen Access? Access hat sich seit Version 2.0 auch stark gemausert (das war damals 1993 bei erscheinen der ersten FPW2.6 Version die aktuelle Access Version). Es mangelt soweit ich weiß immer noch an OOP-Konzepten, aber - Sorry, wenn ich jetzt in ein Fettnäpchen trete - davon machen VFP Entwickler eh weniger gebrauch. für Access spricht die Integration von DB und Frontend, Möglichkeit der Office-Automatisierung und MS SQL Server Datenanbindung.

    Ms schlägt noch Visual Studio Lightswitch als Umstieg vor, aber dann nimm lieber gleich VB.NET oder C#.

    Wie lang VFP läuft? Es läuft auf Win8, auf dem Desktopteil. WinRT (der "Kachelteil", der auch auf ARM Prozessoren läuft) von Windows8 kommt aber sowieso (noch?) nicht gut an, wenn man sich so umhört.

    MS macht höchstens noch Sicherheitsupdates für VFP9, und nur noch bis 13.01.2015, wenn Dich das Datum interessiert: Suche nach Visual Foxpro Support Policy. Aber nicht erst dann wird es "Glück" sein, ob VFP9 noch läuft. Soweit ich weiß, werden Produkte aber bereits bei austritt aus dem Mainstream Support nicht mehr auf Funktionstüchtigkeit unter neuen Windowsversionen mit in deren Test eingebunden. D.h. es war schon "Glück", dass VFP9 unter Win8 lief. Es war aber auch schon "Glück" daß alte VFP Versionen unter XP/Vista/Win7 liefen. Schon wegen Aero ist alles vor VFP9 nicht empfehlenswert, aber es läuft einiges, ich weiß nicht, ob auch ältere Versionen unter Win8 laufen, aber Berichte über VFP9 auf Win8 gab es schon zu Zeiten der Betaversionen und -Previews. Das zeigt aber auch, das Microsoft es nicht darauf anlegt, ein Produkt lahmzulegen, sie würden sich damit auch ins eigene Fleisch schneiden. Jeder Windows-Kunde kommt nunmal mit einem Softwareportfolio daher, was er auch im neuen Windows nutzen möchte, oder er updatet eben nicht.

    Wenn es Dir auf die Zahl potentieller Kunden für Dein Programm ankommt, dann spielt wohl eher die Verbreitung der einzelnen Windowsversionen eine Rolle. Wenn Du Deinem Kunden die Windowsversion vorgeben kannst oder er nichts gegen Nutzung einer virtuellen Machine hat, was sich ja auch immer nahtloser ins System einklinkt, wenn also eine zusätzliche alte Windowslizenz vorliegt oder vom Preis her auch nichts ausmacht, so wie heutzutage ein DOS mit drin ist, um eine FP2.6 oder ältere Anwendung laufen zu lassen, dann kannst Du auch noch 10-20 Jahre VFP betreiben.

    Ganz grundsätzlich technisch hängt das funktionieren von VFP doch an der OS Version, nicht am Jahr. Insofern läßt sich da kein wirkliche Prognose erstellen.

    Wenn alle nur noch Smartphones und Tablets nutzen wollen, wird Dir das auch nicht viel helfen.

    Was Deine Entscheidung angeht: Klar, Codepages haben ihre Grenzen, Codepage 1253 wäre noch zu nennen, hat aber eben auch keine deutschen Umlaute mehr. Access hat da durch seine Unicode-Unterstützung die Nase vorn, wenn es darauf ankommt.

    Tschüß, Olaf.


    Olaf Doschke (Setmics)

    Sonntag, 14. April 2013 19:32
  • Hallo Heinrich,

    wenn es tatsächlich nur um das Speichern in einer Tabelle geht, kannst Du sicherlich auch Unicode verwenden, selbst mit Index, wenn auch vielleicht nicht korrekt sortiert.

    Probleme gibt's eigentlich nur bei Ein- und Ausgabe. Aber unter Verzicht auf die vorgebebenen Elemente wie TextBox und Label ließe sich da auch was machen: einfach per GDI/GDI+ als Grafik auf den Bildschirm zeichnen. Und für die Eingabe müssten eh spezielle Tastenkombinationen für die Sonderzeichen vereinbart werden.

    Gruß,

    Winfried

    Montag, 15. April 2013 09:08
  • Hallo Olaf,

    vielen Dank für Deine sehr ausführliche und ernüchternde Antwort zu: Was nach FoxPro?

    Was ist eigentlich mit xbase (++) oder polarfox?

    Kannst Du nicht mit Deinen Beziehungen ernsthaft anregen, dass in einer Zeitschrift wie z. B. FoxRock die es auch in Deutsch gibt, oder auch an anderer geeigneter Stelle, die möglichen Alternativen für normale Foxpro-Entwickler vergleichend aufzeigt werden. Jeweils mit Vor- und Nachteilen. Welch realistischer Aufwand zu treiben ist und ob eine neue Programmiersprache und mit welchem Aufwand bzw. Tiefe zu lernen ist. Ist eine Datenbank integriert oder muss eine solche noch womöglich sehr umständlich parallel installiert und dann noch mühsam eingebunden werden. (Hatte selbst mal Riesenprobleme mit SQL-Express, viele Fehlermeldungen und ließ sich nach dem Frust nicht mehr ordentlich deinstallieren). Wie sieht es bei einem möglichen Vertrieb, incl. Datenbank, mit den Lizenzgebühren aus?

    Man hat bislang einiges gelesen jedoch mit wenig Hintergrundinformationen, vage Worte über den tatsächlichen Aufwand bei einem Wechsel und ebenso wenig über die dafür erforderlichen Sprach- / Programmierkenntnisse (im Vergleich zu dBAse bzw. VFP9) und in welcher Tiefe.

    Vor einigen Jahren musste ich bei einer FoxPro-Veranstaltung (Konferenz) feststellen, dass es unter den Teilnehmern viele mit fundierten dBase- bzw. FoxPro-Kenntnissen gab, die entsprechend diese Sprache beherrschten aber Kontakt bzw. ausgereiftere Kenntnisse zu anderen Sprachen, wie auch ich, vermissen ließen. Dies lag wohl an der Einfachheit der Sprache, Großzügigkeit bei der Programmierung die viele Fehler verzeiht, die notwendige Datenbank gleich mitliefert und zusätzlich bei einem möglichen Vertrieb, incl. Datenbank, keine Probleme aufwirft.

    Die Antwort kann ja auch ausfallen: Verabschiede Dich von der dBase-Welt lerne Java nimm die oder jene Datenbank. Der Aufwand die neue Sprache (bei fundierten dBase/FoxPro-Kenntnissen) in der Tiefe so zu beherrschen, dass die FoxPro-Anwendung nachgebaut werden kann, ist beträchtlich (> 1 Jahr).

    Die dBase bzw. FoxPro-Anwendungen die ich kenne, wurden meist für einen isolierteren Kreis in mehr oder weniger großen Firmen, auch für Einzelpersonen entwickelt. Bedingung für deren Erfolg war u. a. die unkomplizierte Installation, ohne riesigem Equipment und Abhängigkeiten (Großdatenbanken, firmeninterne IT).

    Eine solche Gegenüberstellung für FoxPro-Alternativen  wäre eine heiß begehrte und sehr oft angeklickte Veröffentlichung. Vielleicht hast auch Du die Muße einen solchen über kurz oder lang zu veröffentlichen.

    Nochmals vielen Dank und beste Grüße

    Heinrich

     

     

    Montag, 15. April 2013 15:32
  • Eine Kurzübersicht habe ich mal bei Experts-Exchange geschrieben. Der einzige Artikel dort über Foxpro.

    Ich bin nicht Rainer Becker, der FoxRock herausgibt. Ich weiß, dass in dem Magazin auch schon ausführlicher der Advantage Database Ansatz vorgestellt wurde, DBCs und DBFs fortzuführen, aber selbst wenn ich mehr Einfluss auf ihn hätte dies und andere Alternativen mehr in den Vordergrund zu stellen, ich könnte wenig dazu schreiben. Ich selbst bzw. die Firma, in der ich arbeite, geht jetzt den Weg in die DotNET Welt, weil unsere Endkunden insgesamt doch mehr in der Microsoft-Welt als in der dBase Welt verwurzelt sind und dort bleiben möchten bis müssen.

    In dem Artikel bei Experts-Exchange habe ich auch nur eingesammelt, was als Alternativen gehandelt wurde und mal grob nach der Art sortiert, ich habe mich mit keinem davon so ausführlich auseinandergesetzt, daß ich es empfehlen könnte. Die wenigsten Ansätze gehen um fortführung bestehenden dBase Codes. Zu den Alternativen müßten sich einzelne Leute finden, die sie näherbringen, da bin ich der falsche Ansprechpartner.

    Die Frage ist doch in den meisten Fällen gar nicht, was Foxpro ersetzen könnte, sondern womit man seine Zielgruppe halten kann oder welche man sonst noch ohne viel Eigenaufwand bedienen könnte. Davon hängt doch alles weitere ab.

    Tschüß, Olaf.


    Olaf Doschke (Setmics)

    Donnerstag, 18. April 2013 08:39
  • Hallo Winfried,

    vielen Dank für den Hinweis. Eigentlich habe ich nur ein Programm / Anwendung geschrieben, die ich nun schon seit vielen Jahren update bzw. durch neue Versionen ersetze. Mit dBase habe ich angefangen, weiter mit foxpro 2.5 bis zu 9. Einmal habe ich eine Grafik (Diagrammauswertung) von Windows (95?) in mein Programm eingebaut und die funktionierte bei einem Umstieg zu einer neueren Windows-Version (XP?) nicht mehr. War für mich ein Horror. Seitdem lasse ich die Finger von diesen Ausflügen. Gleiches Problem hatte ich einmal mit einem von Windows angebotenen Fenster zu Dateiauswahl. Gab plötzlich beim Umstieg auf Windows 7 Fehlermeldungen. Mein Problem ist, dass ich nicht erkannt habe, was von FoxPro und was von Windows ist.

    Ich werde jetzt die neue Version meines Programms bis Anfang nächsten Jahres mit meinem geliebten FoxPro auf die Reihe bringen und wie mit Olaf diskutiert, zwischenzeitlich nach möglichen Alternativen, sofern es sie überhaupt gibt, suchen. So etwas wie Foxpro habe ich eben leider noch nicht gefunden. Ein in sich geschlossenes Paket. Alles vorhanden. Man kann die fertige (mit Foxpro erstellte) Anwendung, in der sich alles in einem Verzeichnis befindet, problemlos von einem Laufwerk, von einem PC auf einen anderen PC kopieren ohne dass eine neue Datenanbindung oder Neuinstallation erforderlich wäre. Foxpro könnte fast von S. J. sein. Einfach, intuitiv und unkompliziert.

    Ich habe mir nur Windows 8 auf dem Notebook installiert um mein Programm auch unter dieser Windowsversion zu testen. Die Installation von Windows 8 war eine Katastrophe und nach endlich geglückter Installation musste ich im Internet nach dem Ausschalter (Herunterfahren) suchen. An Steve Balmer gerichtet: Auch in Bereitschaft ist der Akku schnell leer. Ist der Weg von Microsoft weg vom Einfachen? Ist es mit seinen Programmiertools einschließlich getrennten Datenbanken ähnlich?

    Echte und erfahrene Programmierer, wie Ihr es seid und mir vielfach geholfen haben, beherrschen mehrere Sprachen und entwickeln umfangreichste Software die sich in Regionen bewegt, in denen auch eine komplizierte und umfangreiche Installation, bei der auch schwerwiegendere Probleme (einschließlich der nötigen IT-Unterstützung) auftauchen können, eine untergeordnete Rolle spielt.

    Vielen Dank und beste Grüße

    Heinrich

    Samstag, 20. April 2013 12:16