String Formatierung - lesen und Darstellen von Symbolen

mattik · 20. August 2012, 23:03

zuko schrieb:

mattik hat dir ja schon erklärt das beides Unicodes sind.

Keine Sorge, Lucas muss und kann ich nicht mehr viel erklären. Die Diskussion, ob 63275 Unicode ist oder nicht, ist etwas müßig. In erster Linie ist es eine Zahl. Ja, es ist ein Unicode-Codepunkt. Aber ein spezieller, der wiederum nicht viel mehr ist als eine Zahl (weil ihm keine Glyphe zugeordnet ist). Apple hat die Zahl für eine enum gewählt, und anscheinend nicht zufällig (kann man z.B. hier im Kommentar lesen).

Und ehrlich gesagt verstehe die Beschwerden über dieses Forum nicht. Die Frage im OP wurde in den ersten beiden Antworten von DroneDeveloper und Lucas erschöpfend beantwortet: Es geht nicht - der Rest der Diskussion ging dann um die Verwirrung zwischen den Unicodes 0xf72b und 0x2198. Das ist doch jetzt auch ordentlich geklärt, oder? Mein ursprünglicher Beitrag sollte nur etwas Hintergrund dazu geben, warum das so ist.

Es kann sein, dass es bei stackoverflow sehr viele, sehr gut gemeinte und sehr freundliche Antworten gibt, aber häufig leider auch sehr falsche.

zuko · 21. August 2012, 12:45

mattik schrieb:

zuko schrieb:

mattik hat dir ja schon erklärt das beides Unicodes sind.

Keine Sorge, Lucas muss und kann ich nicht mehr viel erklären. Die Diskussion, ob 63275 Unicode ist oder nicht, ist etwas müßig. In erster Linie ist es eine Zahl. Ja, es ist ein Unicode-Codepunkt. Aber ein spezieller, der wiederum nicht viel mehr ist als eine Zahl (weil ihm keine Glyphe zugeordnet ist). Apple hat die Zahl für eine enum gewählt, und anscheinend nicht zufällig (kann man z.B. hier im Kommentar lesen).

Und ehrlich gesagt verstehe die Beschwerden über dieses Forum nicht. Die Frage im OP wurde in den ersten beiden Antworten von DroneDeveloper und Lucas erschöpfend beantwortet: Es geht nicht - der Rest der Diskussion ging dann um die Verwirrung zwischen den Unicodes 0xf72b und 0x2198. Das ist doch jetzt auch ordentlich geklärt, oder? Mein ursprünglicher Beitrag sollte nur etwas Hintergrund dazu geben, warum das so ist.

Es kann sein, dass es bei stackoverflow sehr viele, sehr gut gemeinte und sehr freundliche Antworten gibt, aber häufig leider auch sehr falsche.

Wenn ich mir deine Antwort durchlese muss ich mit meinem bescheidenem Wissen feststellen das dieses hohe Ross in Bezug auf die Qualität von Stacksoverflow unangebracht ist.
Zunächst einmal werden wird die Frage in den beiden ersten Antworten nicht erschöpfend beantwortet weil die Formatierung des Logs nicht das primäre Problem ist.
Das Problem liegt darin das den Funktionstasten bei einer Abfrage kein Glyph zugeordnet ist.
Anders verhält es sich aber bei der Eingabe eines MenuItem keyEquivalenten in der XiB in Xcode. Dort ist den Funktionstasten ein Glyph zugeordnet.

Das muss man wissen, aus der Doku geht das nicht hervor.

Laut Doku wirft die Abfrage des MenuItem keyEquivalent einen NSString aus. Das suggeriert das die Glyph Darstellung auch für die Funktionstasten schon erledigt wurde.

Jetzt fängt das Rätselraten an. Denn wenn man sich ausgeworfenen NSString darstellt egal ob im Log oder im Textfeld oder sonstwo...wird ein anderer Glyph wiedergegeben.
Sprich man muss über die (Funktion Key Unicode) Konstanten ermitteln welche Funktionstaste dem keyequivalenten entspricht und den Glyphen selber zuordnen.

Das alles hat nichts mit "wenig Mühe geben" oder "Frage verständlich formulieren" zu tun.
Entweder man weiß es oder nicht, denn die Doku ist diesbezüglich nicht eindeutig und in den Fachbüchern, die mir zur Verfügung stehen wird die Frage auch nicht behandelt.

Hört doch einfach auf das rumgezicke in diesem Forum mit fadenscheinigen Begründungen zu entschuldigen. Ob eine Frage letztendlich beantwortet wurde tut nichts zur Sache weil der Ton die Musik macht. Ich möchte hier nichts schlecht reden aber in diesem Forum herrscht der unfreundlichste Ton den ich bisher erlebt habe.
Und in Bezug auf die Qualität würde ich nicht sagen das es Stacksoverflow irgendetwas voraus hat. Eher im Gegenteil 80% der Fragen die ich recherchiere werden über Google auf Stacksoverflow beantwortet. Das einzige Plus dieses Forums sehe ich in der deutschen Sprache. Nur wenn man sich den Zeit intensiven Hans Dampf Zirkus anschaut der hier praktiziert wird ..... :thumbdown:

Lucas de Vil · 21. August 2012, 13:11

zuko schrieb:

(StackOverflow) Ins Nirvana würdest du und Konsorten verschwinden

Ja. Klar.

zuko · 21. August 2012, 15:30

Lucas de Vil schrieb:

zuko schrieb:

(StackOverflow) Ins Nirvana würdest du und Konsorten verschwinden

Ja. Klar.

Sehr amüsant.

Geil ist... du hast da insgesamt 3 Antworten auf Stacksoverflow gegeben mit einer +Bewertung. Das ist aber weniger relevant.
Interessant ist das alle drei antworten nett, knapp und ohne Zirkus formuliert hast. Backt Hans Dampf in Englisch kleinere Brötchen?

Zieh doch mal da die Nummer durch die du hier veranstaltest und dann schauen wir mal wie wie weit du da kommst.

matz · 21. August 2012, 16:21

Och gott, nur weil du mit Lucas Antworten nicht klar kommst ... So langsam entwickelt sich das hier ins lächerliche.

Lucas de Vil · 21. August 2012, 16:35

zuko schrieb:

Geil ist... du hast da insgesamt 3 Antworten auf Stacksoverflow gegeben mit einer +Bewertung. Das ist aber weniger relevant.

Ich seh' schon, du bist hier der StackOverflow Experte.
Ja, ich habe eine + Bewertung für 'Antwort hat mein Problem gelöst' sowie eine + Bewertung für einen Upvote erhalten.
In Anbetracht des Alters der gestellten Fragen halte ich das für durchaus akzeptabel.

zuko schrieb:

Interessant ist das alle drei antworten nett, knapp und ohne Zirkus formuliert hast. Backt Hans Dampf in Englisch kleinere Brötchen?

Nein.
Schau dir den Unterschied in den Fragestellungen an.

Bei einem war es ein 'Ich möchte gern ein Framework einbinden, bekomme aber nur den Sourcecode. Was soll ich tun?'.
Ein kurzer Hinweis auf die Multi-Target-Architektur und wie das zu bauen ist ist da ziemlich schnell gegeben.

Bei einem war es ein Codebeispiel mit einem 'Ich möchte dieses simple Beispielprojekt kompilieren, bekomme aber einen Fehler des Linkers. Was soll ich tun?'
Ein kurzer Hinweis, dass die .m auch zum Target gehören muss, mag für die Beantwortung dieser Frage nicht hilfreich sein. Ich hatte das Problem und habe die Lösung geschrieben, um sie Anderen zugänglich zu machen.
Ob ich dafür Punkte bekomme ist mir genauso schnurz wie hier Beiträge zu bekommen.

Beim dritten wieder ein 'Ich möchte ein Framework einbinden', diesmal mit 'doch bekomme immer einen Fehler dyld: Bibliothek nicht geladen.'
Ein kurzer Hinweis auf das Hinzufügen des nicht-systemweiten Frameworks zu den Copy Build Phases ist da ebenfalls schnell gegeben.

Du siehst, die Fragen waren so formuliert, dass es eine schnelle und kurze Antwort darauf ohne langes Rätselraten geben konnte.

zuko schrieb:

Zieh doch mal da die Nummer durch die du hier veranstaltest und dann schauen wir mal wie wie weit du da kommst.

Nein. Wenn mir die Fragen bei StackOverflow nicht gefallen, bekommen sie einen Downvote und fertig. Da kümmere ich mich überhaupt nicht drum.
Übrigens: wenn ich über eine interessante und gut formulierte Frage stolpere, dann bekommt sie auch einen Upvote. Nicht nur bestrafen, auch belohnen, sonst wird das nie was.

Im Forum hingegen versuche ich noch zu verstehen, was mir der Autor mitteilen möchte.

Deine Fragestellung war meiner Meinung nach unverständlich. Das kannst du gern anders sehen, du darfst dich deswegen gern angegriffen fühlen, du kannst alles tun was du möchtest.
Jedoch wirst du nicht schaffen mir einzureden deine Fragestellung sei leicht verständlich gewesen.
Immerhin: drei Personen haben sie nicht verstanden.

Sinnvoller wäre vielleicht gewesen:

Hallo Mädels,

wir ihr hier sehen könnt, möchte ich in meiner App Shortcuts anbieten und die dazugehörigen Symbole in einem Textfeld darstellen.
Ungefähr so wie bei den Eingaben der Key Equivalents für ein NSMenuItem im Interface Builder.

Nun stehe ich vor dem Problem, dass beispielsweise die Taste für Ende (↘) nicht so dargestellt wird, wie es beispielsweise beim H der Fall ist.
Beispielcode:

C-Quellcode

const unichar u = [[theEvent charactersIgnoringModifiers] characterAtIndex:0];

NSString * test = [NSString stringWithCharacters:&u length:1];

NSLog(@"Test: %i == %@", u, test);

Habe ich als Taste zum Beispiel das 'H', dann meldet das Log mir:
Test: 72 == H

Habe ich als Taste aber 'Ende', dann meldet das Log mir:
Test: Test: 63275 == 

Ich erwartete aber ein:
Test: 63275 == ↘

Wo liegt der Fehler?

Dann hättest du kurz und knapp eine Art "Alle Unicodes ab 0xE000 bzw. 57344 bis 0xF8FF bzw. 63743 sind 'private' und denen ist nicht unbedingt ein Glyph zugeordnet. In dem Fall musst du selbst eine Prüfung auf die Konstanten von NS*FunctionKey vornehmen und das dir dazu passende Zeichen manuell bereit stellen." erhalten.
Vielleicht noch ein kleines, neckisches "Kopier doch mal das Zeichen aus dem Log in die Schriftsammlung unter der Ansicht 'Eigene' (CMD+3) und schau es dir in einer ausreichenden Größe an. So ab Schriftgröße 90 siehst du, dass dir das Zeichen auch genau das mitteilt. ;)".

Mit deiner Aussage, das Symbol Key Equivalent sei ↘, das Key Equivalent sei immer ein String, die Formatierung im Log stimmt nicht und deiner späteren Aussage die Unicode-Werte unterscheiden sich hast du verwirrt statt eine klare Frage zu formulieren.
Mich zumindest.
Die Frage nach der Taste mit einem Glyphen zu beantworten hat die Verwirrung noch erhöht.
Bei mir zumindest.

Deine Annahme, die Unicode Werte der NS*FunctionKey Konstanten bzw. keyEquivalents würden mit einer Systemschrift übereinstimmen hast du erst in deinem ersten Motzposting #13 überhaupt geäußert.
Jetzt, wo man diese Annahme kennt, ist der Fehler offensichtlich. Bis Posting #8 hatte ich keine Ahnung davon, dass dem so ist. In Posting #9 hatte ich nur die vage Vermutung, die ich dann in Posting #11 als Fakt dargestellt habe.

Zusammenfassung: wenn mein Rumgezicke hilft, dass du deine Fragen in Zukunft so formulierst, dass sie kurz, knapp und zügig beantwortet werden können, dann hat es sich gelohnt.
Wenn nicht, werde ich bei zukünftigen Fragen meinen StackOverflow Stil fahren: die Frage einfach ignorieren.

zuko · 21. August 2012, 18:41

matz schrieb:

Och gott, nur weil du mit Lucas Antworten nicht klar kommst ... So langsam entwickelt sich das hier ins lächerliche.

Also ich komm damit klar nur nicht Kommentarlos. Aber ich finde es süss wie du Lucas zu Hilfe eilst mit der Warnung an mich ihn nicht zu kritisieren weil dann würde ich es mir im Forum mit allen verscherzen.
Wirklich putzig.

@Lucas

Ist netter Versuch dich rauszureden. Der einzig nützliche aus deinem Beitrag ist die Information das du Anfangs nicht verstanden hast worum es geht.
Was dann auch die Ursache für dein rumgezicke war. Aber war die Frage wirklich so unverständlich formuliert?

----------
String Formatierung - lesen und Darstellen von Symbolen

Ein Menu Item hat als keyEquivalent das Symbol " ↘".

Der keyEquivalent ist laut NSMenuItem Doku ein NSString --> (Fakt, so steht es in der Doku)
Wenn ich den keyEquivalent im Log abfrage wird ein anderes Symbol dargestellt.

Quellcode

NSMenu * mainMenu = [[NSApplication sharedApplication] mainMenu];
int a =4;
int b =1;
NSString *keyEquivalent = [[[[[[mainMenu itemArray] objectAtIndex:a]submenu]itemArray] objectAtIndex:b] keyEquivalent];
NSLog(@"keyEquivalent: %@",keyEquivalent);

Wie muss muss man formatieren, damit im Log das Symbol richtig dargestellt wird?
-----------

Alle Infos sind in der Fragestellung enthalten.

Welches Symbol? Ganz unverwechselbar das das für den NSEndFunktionKey verwendet wird.
Wo ist das Symbol? Im keyEquivalenten eines Menu Items.
Wie versuche ich den den Wert abzufragen? Siehe Code.
Was will ich ? Die korrekte Wiedergabe des Symbols im Log.

Was genau soll denn daran missverständlich formuliert sein?

Das ich mich mit unichar Werten rumschlagen muss hat sich erst später herauskristallisiert als ich parallel zur Thread Eröffnung selbst die Lösung gesucht habe.
Das wusste ich vorher gar nicht. Und das steht auch nirgendwo. Kannst ja mal gerne Googeln...mal schauen ob du die Info irgendwo findest.

Auch hier in der Doku...

(....)
Function-Key Unicodes
These constants represent Unicode characters (0xF700–0xF8FF) that are reserved for function keys on the keyboard. Combined in NSStrings, they are the return values of the NSEvent methods characters and charactersIgnoringModifiers and may be used in some parameters in the NSEvent method keyEventWithType:location:modifierFlags:timestamp:windowNumber:context:characters:charactersIgnoringModifiers:isARepeat:keyCode:.

(....)

developer.apple.com/library/ma…/Reference/Reference.html

Das sind die Fakten. Also warum sollte ich mir hier deine Hans Dampf Show vollgespickt mit irgendwelchen haltlosen Vorwürfen kommentarlos reinziehen?
Davon darfst du höchstens träumen.

Ich bin Vater von 2 Kindern und würde denen die Ohren langziehen wenn die sich so verhalten würden.

mattik · 21. August 2012, 20:44

zuko schrieb:

Was genau soll denn daran missverständlich formuliert sein?

Deine Frage bestand in Wirklichkeit aus zwei Problemen. Die offensichtliche Frage war nach 3 Minuten, spätestens nach Lucas' erstem Beitrag beantwortet: Die Xcode-Konsole unterstützt keine höheren Unicode-Zeichen. Klare Frage, klare Antwort.

Das eigentliche, dahinter liegende Problem - und damit das Missverständliche - entstand dadurch, dass Deine Annahme

zuko schrieb:

Ein Menu Item hat als keyEquivalent das Symbol " ↘".

nicht stimmte. Das Menu Item hat als Key Equivalent den Code NSEndFunctionKey, in der API eingepackt als Unicode Codepoint in einen NSString. Es wird in einigen GUIs mit der Glyphe ↘ dargestellt, was in Unicode SOUTH EAST ARROW entspricht, hatten wir ja schon. Der ganze Salami-Findling-Dialog sollte nur erklären, dass das zwei verschiedene Dinge sind. Ja, ihr habt ein Stück weit aneinander vorbeigeredet. Sowas passiert. So, und jetzt ist gut - runterkommen. Mit etwas Glück bekommen wir alle heute Abend noch in einer netten Kneipe um die Ecke ein kühles Bier an einem warmen Sommerabend.

Michael · 21. August 2012, 21:15

mattik schrieb:

Die Xcode-Konsole unterstützt keine höheren Unicode-Zeichen.

Da scheint sich was getan zu haben. Jedenfalls gibt mir Xcode 4.4.1 bei

Quellcode

NSLog(@"\u26BD Hello, World! \u26BD");

Das hier aus:

⚽ Hello, World! ⚽

Michael

zuko · 21. August 2012, 22:59

mattik schrieb:

Deine Frage bestand in Wirklichkeit aus zwei Problemen. Die offensichtliche Frage war nach 3 Minuten, spätestens nach Lucas' erstem Beitrag beantwortet: Die Xcode-Konsole unterstützt keine höheren Unicode-Zeichen. Klare Frage, klare Antwort.

Bei dem Bier bin ich dabei.

Ich denke wenn es hier wieder auf die sachliche Ebene kommt gibt es keinen Grund warum man sich nicht weiter über das Thema unterhalten sollte.

mattik schrieb:

Deine Frage bestand in Wirklichkeit aus zwei Problemen. Die offensichtliche Frage war nach 3 Minuten, spätestens nach Lucas' erstem Beitrag beantwortet: Die Xcode-Konsole unterstützt keine höheren Unicode-Zeichen. Klare Frage, klare Antwort.

Ob die Konsole höhere Unicode Zeichen ausgeben kann oder nicht ist vollkommen unrelevant denn die NSEndFunctionKey ist kein höheres Unicode Zeichen das 8600 dem ↘ SOUTH EAST ARROW entspricht. Der NSEndFunctionKey entspricht dem Unicode Zeichen 63275 .

Wie soll die Konsole denn daraus den SOUTH EAST ARROW zaubern? Sachlich gesehen ist der Formatierungshinweis der Konsole zunächst einmal, ohne böse Absicht, irreführend denn ein NSTextfield oder ein NSButton könnten es auch nicht. Somit ist die Frage auch nicht erschöpfend oder klar beantwortet.

Das eigentliche, dahinter liegende Problem - und damit das Missverständliche - entstand dadurch, dass Deine Annahme

zuko schrieb:

Ein Menu Item hat als keyEquivalent das Symbol " ↘".

nicht stimmte. Das Menu Item hat als Key Equivalent den Code NSEndFunctionKey, in der API eingepackt als Unicode Codepoint in einen NSString.

Nun ich gebe zu das kann man missverstehen. Nur die visuelle Identifikation des NSEndFunktionKeys ist das Unicode Zeichen 8600 ↘ SOUTH EAST ARROW.
Wenn du in der XiB auf das Menu klickst, den keyEquivalten (Shortcut) eines MenuItems auswählst, kannst du den neu definieren. Und wenn du die NSEndFunctionKey taste betätigst wird das Unicode Zeichen 8600 ↘ SOUTH EAST ARROW dargestellt. Sprich im Menu wird visuell das Symbol " ↘" als keyEquivalent des MenuItems dargestellt.

Ich hätte nicht angenommen das der Abstraktionsgrad zwischen MenuItem --> KeyEquivalent-->Symbol-->Tastatur so hoch ist.
Ich mein es ist doch logisch das das Symbol eines keyEquivalenten die Taste auf dem Keyboard repräsentiert. Das sagt der Name keyEquivalent doch schon.
Und jeder der den NSEndFunctionKey beim Namen kennt weiß mit einem Blick auf seine Tastatur das dieser durch das Symbol " ↘" repräsentiert wird.

Aber gut... Sorry für das Missverständnis.

Na dann Prost.

zuko · 21. August 2012, 23:08

Michael schrieb:

NSLog(@"\u26BD Hello, World! \u26BD");

Xcode 4.3.2 kann das auch

Lucas de Vil · 22. August 2012, 08:53

Michael schrieb:

mattik schrieb:

Die Xcode-Konsole unterstützt keine höheren Unicode-Zeichen.

Da scheint sich was getan zu haben. Jedenfalls gibt mir Xcode 4.4.1 bei

Quellcode

NSLog(@"\u26BD Hello, World! \u26BD");

Das hier aus:

⚽ Hello, World! ⚽

Michael

Nicht Xcode 4.4.1, sondern Lion.
Müsste der Emoji-Zeichensatz sein.

Vergleiche fontblog.de/10-praxistipps-zu-lion-33 Punkt 10.

Michael · 22. August 2012, 10:02

Lucas de Vil schrieb:

Michael schrieb:

mattik schrieb:

Die Xcode-Konsole unterstützt keine höheren Unicode-Zeichen.

Da scheint sich was getan zu haben. Jedenfalls gibt mir Xcode 4.4.1 bei

Quellcode

NSLog(@"\u26BD Hello, World! \u26BD");

Das hier aus:

⚽ Hello, World! ⚽

Michael

Nicht Xcode 4.4.1, sondern Lion.
Müsste der Emoji-Zeichensatz sein.

Ob die Fußbälle per Emoji-Zeichensatz dargestellt werden oder nicht, spielt doch keine Rolle. 26BD ist der Unicode für einen Fußball. Wenn die Xcode Konsole kein Unicode könnte, dann würde statt der Fußbälle so etwas dabei raus kommen:

‚öΩ Hello, World! ‚öΩ

Hier noch ein Beispiel ohne Emojis:

NSLog(@"\u24BD\u24B6\u24C1\u24C1\u24C4");

ergibt: ⒽⒶⓁⓁⓄ

Michael

String Formatierung - lesen und Darstellen von Symbolen

zuko schrieb:

mattik schrieb:

zuko schrieb:

zuko schrieb:

kmr schrieb:

Lucas de Vil schrieb:

zuko schrieb:

zuko schrieb:

zuko schrieb:

zuko schrieb:

C-Quellcode

kmr schrieb:

matz schrieb:

Quellcode

zuko schrieb:

zuko schrieb:

mattik schrieb:

Quellcode

mattik schrieb:

mattik schrieb:

zuko schrieb:

Michael schrieb:

Michael schrieb:

mattik schrieb:

Quellcode

kmr schrieb:

Lucas de Vil schrieb:

Michael schrieb:

mattik schrieb:

Quellcode