Suchergebnisse

Zitat: „Original von asrael Der Thread is schon'en Jahr alt, Tom. :)“ Hast Du ihn nicht aufgewärmt?

Ich erstelle deshalb immer einen gesonderten View für die Statusleiste. Die -[NSWindowController windowDidLoad]-Implementierung sieht dann so aus: Quellcode (3 Zeilen)

Da hier ja auch schon einige mit dem iPhone-SDK herumfrickeln, mal eine Frage. Vermutlich habe ich einfach nur eine Denkblockade oder bin blind. Auf jeden Fall bekomme ich einen UIScrollView nicht dazu zu zoomen, obwohl ich glaube, sämtliche Anforderungen erfüllt zu haben. Getestet wird auf dem Simulator (Wahltaste + Klick). Folgendes habe ich unternommen: - Meine von UIViewController abgeleitete Klasse ist im NIB als Delegate des UIScrollViews gesetzt. - Der Viewcontroller implementiert sicherh…

Das Problem mit den privaten Settern hatte ich auch. In benannten Kategorien lassen sich nämlich keine Eigenschaften automatisch via @synthesize implementieren. Funktionieren tut das aber mit unbenannten Kategorien (class continuations). Das sieht dann so aus: MyFoo.h: Quellcode (7 Zeilen) MyFoo.m: Quellcode (12 Zeilen)

Wenn Du via FSMatchAliasBulk() die möglichen Originaldateien für die Aliase herausfindest, kannst Du bestimmen, ob Volumes eingebunden werden sollen oder nicht; das bezieht sich dann aber wohl auf alle Arten von Volumes, nicht nur auf Netzwerkvolumes. Die entsprechende Maske ist kARMMountVol.

Für ein neues Projekt, für das sich Abwärtskompatibilität nicht lohnt, setze ich auch gerne auf Objective-C 2.0.

Zitat: „Original von Michael Was es nicht alles neues in 10.5 gibt.“ developer.apple.com/releasenotes/Cocoa/AppKit.html Das tolle an diesen zwei neuen Methoden ist allerdings, daß einem zwar ständig überall von -[NSWindow setContentBorderThickness:forEdge:] erzählt wird, aber (so gut wie) nie etwas von -[NSWindow setAutorecalculatesContentBorderThickness:forEdge:]. Außerdem wird einem auch nie gesagt, wann man sie am Besten verwendet …

longWs Tip mit dem Viel-Lesen würde ich mich anschließen. Nimm es nicht persönlich, aber gerade am Anfang sollte man so klein wie möglich anfangen. Dann kann man später noch ausbauen. Am Anfang ist wohl weniger das Aussehen Deiner Anwendung wichtig, als vielmehr daß Du Dir die wiederkehrenden Muster in Cocoa aneignest: MVC, Klasse vs. Protokoll, Delegates, Notifications, KVC/KVO, usw. Ansonsten wurde, wenn ich das richtig sehe, schon alle Fragen geklärt, oder? Nochmal ein paar Worte zu meiner Lö…

Ich habe Dir mal ein Miniprojekt angehängt, das das korrekte Vorgehen demonstriert. Momentan ist der NSWindowController (BBMyController) noch im NIB eingebettet, Du könntest ihn aber auch programmatisch erstellen, die Inhaltsrahmendicke setzt er trotzdem richtig.

Ich sehe auch gerade, daß Du den Code nach -[NSView initWithFrame:] gepackt hast. Das ist meiner Meinung nach Unsinn. Dein NSWindow hat einen NSWindowController/ein NSDocument (wenn es den nicht hat, machst Du vermutlich was falsch) als Delegate. In dessen Code packst Du an die von mir oben angegeben Stelle den Code. Ein View sollte am Fenster nichts verändern.

Die Methode funktioniert nicht, wenn die Fenstermaske NSTexturedWindowMask enthält, also wenn Du im IB den Haken bei Textured gemacht hast. Die Methode würde beim View keinen Sinn ergeben, da der Inhaltsrahmen Teil des Fensters (eigentlich nochmal ein separater View, aber wen juckt’s) ist. Außerdem, wieso sollte der View den Rand *oben* haben? Dein BottomBar ist vermutlich ohnehin überflüssig.

Wenn Du nur für Leopard entwickelst – ich schloß auf Grund des Stichwortes »Garbage Collection« darauf –, dann brauchst Du für den Hintergrund unten keine besondere NSView-Unterklasse. Verwende einfach in der passenden Methode (-[NSWindowController awakeFromNib], -[NSWindowController windowDidLoad] oder -[NSDocument windowControllerDidLoadNib:], je nachdem, wie Deine Anwendung aufgebaut ist) folgenden Code: Quellcode (2 Zeilen) Den Wert von 41.0f müßtest Du natürlich an Deine Bedürfnisse anpasse…

Zitat: „Original von Objcler Ja und? NSArray, NSDictionary, NSString, ... praktisch jeder Typ, der von NSPropertyListSerialization verstanden wird hat "eigene" Propertylist Methoden.“ *Nachschau* … Stimmt, bisher war mir diese nur bei NSDictionary aufgefallen. Naja, via NSPropertyListSerialization hat man mehr Kontrolle über das, was passiert. So lassen sich Fehler u. U. leichter abfangen, wenn Du zuerst ein NSData-Objekt mit +[NSData dataWithContentsOfFile:] erstellst und es anschließend deseri…

Zitat: „Original von Objcler Mal eine kleine Frage: Wieso sollte man statt NSDictionarie's oder NSArray's Propertylistmethoden NSPropertyListSerialization nutzen? Zwei Gründe fallen mir spontan ein: Um ältere plists einlesen zu können oder um das Format beeinflussen zu können. Aber sonst?“ Das Wurzelobjekt einer Plist kann nicht nur ein NSDictionary sein. Es kann jeder Datentyp sein, der von NSPropertyListSerialization serialisiert werden kann.

Die Angabe wird dann am zuverlässigsten aktualisiert, wenn das Wurzelverzeichnis des Laufwerkes geändert wird, z. B. so:Quellcode (1 Zeile) Man könnte also prinzipiell einen Daemon schreiben, der diese Aufgabe erledigt, jedoch würde dies, wenn ich richtig wähne, verhindern, daß der Rechner in den Ruhezustand geht.

U. U. könnte die Installation des vorherigen Comboupdates helfen. Der Erfolg dieser Methode ist davon abhängig, ob in 10.4.10 auch keine Komponenten geändert wurden, die in keiner der Versionen zuvor geändert worden sind. Außerdem weiß ich nicht, ob es möglich ist, ein Comboupdate über eine neuere Version zu installieren.

Zitat: „Original von Yves Hab ich doch gemacht… siehe Eröffnungsposting ;)“ Upps …

Ihr sollten dann sinnvollerweise auch noch den Schlüssel CFBundleDevelopmentRegion in der Info.plist entsprechend setzen: Zitat: „This key specifies the native region for the bundle. This key contains a string value that usually corresponds to the native language of the person who wrote the bundle. The language specified by this value is used as the default language if a resource cannot be located for the user’s preferred region or language.“

Du könntest auch zu Objective-C++ verwenden. Damit kannst Du die Oberfläche in schönem, praktischem Objective-C halten, und die GUI-unabhängige Programmlogik in häßlichem C++, unübersichtlichem schreiben.

Du muß einfach die Spiralen im Interface Builder für die automatische Größenanpassung richtig setzen: Die untere und die rechte müssen flexibel sein.