NSTableView und Bindings: Merkwürdige Formatierung

  • NSTableView und Bindings: Merkwürdige Formatierung

    Hier kommt auch schon das nächste Problem, dass ich bei meinen ersten Binding-Schritten habe:

    Bitte das angefügte Bild anschauen, während ihr diesen Beitrag lest; bitte nicht über die merkwürdigen Spalten wundern - ist noch in Testphase.
    Es zeigt einen NSTableView, dass über einen NSArrayController gefüllt wird.

    Kurze Info zu den Spalten:
    "icon": 32x32 NSImage per NSImageCell
    "volume": NSAttributedString
    "usage": NSString (small system font)
    "path" bis "free": NSString (kein Font eingestellt!), "capacity" u. "free" sind über einen NSFormatter formattiert

    Das NSTableView ist mit dem Style "use alternating row background" versehen.

    Wenn man sich nun das Bild genauer anschaut, sieht man, dass die Spalten "path", "driveName", "fileSystemName", "diskIDString" und "volumeFormat" einen kleineren Font verwenden und schwarz gezeichnet werden, wenn die Zeile selektiert ist, obwohl "nur" ein NSString dargestellt wird und keinerlei Font für die Spalte eingestellt ist (auch nicht über Bindings). Die Spalten "mountDevice", "capacity" und "free" werden hingegen korrekt angezeigt - neben den Spalten "volume" und "usage", die ja einen bestimmten Font verwenden.
    Zusätzlich wird der bläulichen Zeilenhintergrund in der Spalte "capacity" weggelassen (bzw. überzeichnet?).

    Zwar würde es mich wundern, wenn diese "Formattierungs-Anomalien" vom Binding herrühren; ich hatte aber keinerlei solcher Probleme, wenn ich sonst NSTabelViews (ohne Bindings) eingesetzt habe.

    Weiss jemand einen Rat?

    Vielen Dank,
    Tjark

  • RE: NSTableView und Bindings: Merkwürdige Formatierung

    Hmmmm, hmmm, und nochmal hmmmm.

    Also, mal so Brainstorming: Es kann sein, dass obwohl due Strings übergibst, ein Formatter dazwischenhängt. Du kkannst ja etwa auch floats zurückgeben, die von den Bindings dann automatisch in ein anderes Format umkonvertiert werden. Damit bleibt diese Arbeit den Views erspart. Vielleicht hast du also im Endefekt einen Text, keinen String. Das weiß ich aber nicht. Kannst du vielleicht iM debugger etwas feststellen? Möglicherweise, wenn du den View einfach mal "leer" ableitest und dich nur an eine Methdoe (draw:) hängst um einen Breakpoint setzen zu können?

    Wie sieht es denn aus, wenn du einzelne Spalten breiter machst?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • ebenfalls hmmm ;)

    Vielleicht hast du also im Endefekt einen Text, keinen String.

    Du meinst einen formatierten String (NSAttributedString)? Die Methoden, die aufgerufen werden, um die Zelleninhalte bereit zustellen, geben NSStrings zurück und auch deren Implementierungen arbeiten nur mit NSStrings. Für die Spalten "capacity" und "free" verwende ich einen eigenen Formatter, der ebenfalls NSString zurückgibt (deren zugrunde liegende Model-Methoden geben unsigned long long zurück, welche - wie du auch erwähnt hast - in NSNumber geboxed werden).

    Beim Verändern der Spalten-Breite verhalten sich die Spalten ganz normal.
    Wenn ich den Font z.B. der "path"-Spalte auf den Standard-Font mit

    Quellcode

    1. [[[_volumesTableView tableColumnWithIdentifier: @"path"] dataCell] setFont:
    2. [NSFont systemFontOfSize: 0 /*default size*/]];

    setzte, wird die Spalte korrekt gezeichnet.
    Aber normal ist datt nich...

  • Nee, neee, ich meine, dass die Bindings automatisch das umformatieren. Das machen die schonmal, wenn du etwa einen float zurückgibst. Ich lgaube es aber hier auch nicht wirklich.

    Ansonsten: Es hängt also schon mit der Spaltenrbeite zusammen? Habe ich das richti vestanden?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Mit der Spaltenbreite hängt es nicht zusammen.
    Mit "Beim Verändern der Spalten-Breite verhalten sich die Spalten ganz normal" meinte ich, dass die nicht korrekt formatierten Spalten sich genauso verhalten beim verändern der Breite, wie die Spalten, die richtig formatiert werden (also z.B. der Text wird abgeschnitten, wenn die Spalte schmaler gemacht wird, als der Text lang ist).

  • Hmmm, schade, schade.

    Also, als ich es mir jetzt nochmal angeschaut habe, hatte ich fast den Eindruck, dass es möglicherweise mit der Spaltenhöhe zusammenhängt. Ich werde das Gefühlö nicht los, dass das ein gewolltest Verhalten ist. Dazu sieht es "zu gut" ist.

    Lade das Projekt dochmal hoch oder schicke es mir zu. Das interessiert mich dann doch.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Hast du meine E-Mail schon bekommen?

    Ich habe übrigens gerade gesehen, dass im Interface Builder bereits der kleinere Font verwendet wird. Wie kommt das? Wie kann ich den Standard-Font im Interface Builder setzten?

    Zusätzlich habe ich gerade bemerkt, dass, egal ob ich "horizontal lines" oder "vertical lines" im Interface Builder für das NSTabelView einstelle, es werden immer nur vertikale Linien gezeichnet !?
    Hä? Langsam werde ich wahnsinnig...

  • Du kannst ja im Interface Builder andere Cells den Spalten zuweisen. Wenn Du das gemacht hast, dann erscheint bei Auswahl einer Spalte oben rechts ein Dreieck. Dieses kannst Du ebenfalls auswählen und bekommst dann die Einstellungen für die verwendete Cell, wo Du dann z.B. die Größe des Font einstellen kannst.
    Ich vermute ja, dass auch das andere Problem auf unterschiedliche Cell-Einstellungen zurück zu führen sind.

    Michael

  • Das ist nicht das Problem, denn ich verwende für die nicht korrekt gemalten Spalten keine speziellen NSCell-Typen.
    Ich habe zur Sicherheit ein NSImageCell auf die Spalten gezogen und danach "Use Default Data Cell" in den Attributen der Spalte angeklickt (danach verschwindet das Dreieck im Spaltenkopf wieder).