Suchergebnisse

Super, vielen Dank für den Test! Ich werde auf jeden Fall das Programm noch ins Deutsche übersetzen (allerdings erst, wenn aus der Version ein "offizielles" Release wird - die Übersetzung mache ich immer als Letztes). - Tjark

Prima! Falls ein MacIntel Besitzer Lust und Zeit hat, kann er gerne auch noch das Finder-Contextmenü-Plugin testen. Das Plugin lässt sich über den Preference-Dialog installieren und auch wieder deinstallieren. Danke! Tjark

@below Entschuldige, kenne mich mit den Bedingungen für die DTKs nicht so aus... Na ja, bekommst jetzt ja einen iMac dafür @ssb: Tritt bei dir die Denkpause beim Schließen des Donate-Fensters auch auf? (falls du "Don't show again" angeklickt hast, einfach "com.derlien.DiskInventoryX.plist" in deinem Preference-Ordner löschen) - Tjark

@Chris: Danke. Mal sehen, ob's bei ssb nun geht. @below: Nein, es ist ein normales NSWindow, das sofort beim Klicken auf "Close" geschlossen werden sollte. Die Checkbox "Don't show again" ist per Bindings mit den "Shared User Defaults" verbunden. Ich frage mich gerade, ob die Defaults beim Schließen des Fensters auf die Platte geschrieben werden und so eine Denkminute auftritt? Ist 10.4.4 auf deinem DTK installiert? - Tjark

Dass die Intel-Version grundsätzlich läuft, freut mich natürlich. Danke, ssb! Der Absturz auf dem G5 wundert mich aber. Habe gerade die Applikation mit einer kleinen Änderung neu gebaut. Könntest du sie bitte nochmals unter dem obrigen Link herunterladen? Weil sonst noch jemand einen G5 hat, würde ich mich freuen, wenn er ebenfalls diese Version auf seinem Rechner kurz testet. Danke!

Ein Screenshot wäre super! Wegen des Absturzes auf deinem G5 muss ich noch mal schauen (ist merkwürdig, da es auf meinem PB G4 läuft). Danke

Zitat: „Original von ssb Auf jeden Fall crasht DIX auf meinem G5. Den Crashreport habe ich dir als Mail geschickt. Ich werde DIX gleich auf meinem DTK Mac testen.“ Das klingt nicht gut. Läuft denn die "offizielle Version" 1.0 auf deinem G5?

@klausel: Danke auch. Allerdings ist nicht alles auf meinem Mist gewachsen: Der Code für das Layout und den Kisseneffekt in der TreeMap stammt aus KDirStat. (ist ja alles GPL'ed @Tom9811: Stimmt, ich hatte dir mal den Quellcode gemailt. Ich glaube, ich hatte damals Probleme mit Bindings. Leider ist das Kompilieren und Linken des Tools wegen der ganzen Frameworks nicht so einfach

Habe mich in den letzten Tagen daran gesetzt, um ein Universal Binary meines kleines Tools "Disk Inventory X" zu erstellen (zeigt die Festplattenbelegung grafisch an; näherers unter www.derlien.com). Jetzt suche ich einen "Intel-Macianer", der so freundlich ist und einen kurzen Test damit macht! Download hier (dmg; 2,8MB). Es wäre super, wenn derjenige folgendes testet: 1. Applikation starten (was sonst ;-), 2. einen Ordner öffnen (möglichst nicht gleich die ganze Platte - das dauert zu lange) 3…

Bin gerade dabei, mein Projekt auf xCode 2.2.1 (von 2.0) umzustellen und bei der Gelegenheit ein Universal Binary zu erstellen. Merkwürdigerweise findet xCode/gcc die Nicht-Apple-Framworks nicht mehr, wenn sie über einen relativen Pfad (z.B. "$(SRCROOT)/../MeinSuperFramework/build") referenziert werden. Erst wenn ich den Pfad manuell in einen absoluten umwandle, findet gcc die Header des/der Frameworks (entfernen und neu hinzufügen der Frameworks bringst nicht). Any ideas? Danke, Tjark

Prima, danke! Den Thread hätte ich ja auch finden können.. Schade, das Apple diese Feature nicht vorgesehen hat und man sich mit einem Skript behelfen muss. Kennst du den Unterschied zwischen den beiden Variablen "BUILD_STYLE" und "CONFIGURATION"?Scheinen Beide die aktuelle Build-Konfiguration anzugeben. Danke, Tjark

In meiner Applikation verwende ich diverse Frameworks (u.a. Omni, CocoaTech), die als embedded private Frameworks ins Applikations-Bundle kopiert werden (mittels einer "Copy Files" Build Phase). Nun möchte ich gerne, dass je nach Build-Konfiguration (Debug oder Release) meines Projektes jeweils auch die Debug- oder Release-Versionen der Frameworks gelinked und ins Bundle kopiert werden. Dies wäre sicherlich durch unterschiedliche Targets möglich, die sich nur in den verwendeten Frameworks unters…

Wenn Du "nur" einen String als eindeutigen Identifizierer im Netzwerk genötigst, biete sich auch folgendes an: Quellcode (1 Zeile) Aus der Apple Doku: Zitat: „Returns a globally unique string to identify the receiver. This method uses the host name, process ID, and a time stamp to ensure that the string returned will be unique for the network. This method generates a new string each time it is invoked, so it also uses a counter to guarantee that strings created from the same process are unique.“…

Ja, wenn's mit x86 soweit ist, wird wohl gcc 4 obligatorisch sein (oder aber ein Binary für PPC ab 10.3 und ein weiteres für x86 ab 10.4, was dann wiederum verwirrend sein kann). Aber zunächst werde ich zumindest öffentliche Versionen als gcc 3.3.-Kompilate verteilen...

Ja, stimmt, da war ja was Danke, ihr Beiden! Zitat: „ Man kann sich natürlich auch auf den Standpunkt stellen, das es von 10.3.x auf 10.3.9 ein kostenloses (und sinnvolles) Update gibt. “ Das stimmt. Aber solange die Verwendung von gcc 4 nicht aus technischen Gründen notwendig oder sehr angeraten ist, kann man es den Usern ja auch leicht machen (zumal nicht jeder User über die eingespielten Updates entscheiden kann).

Seit auf ich auf 10.4 aktualisiert habe, kompiliere ich mein Programm mit dem Target-SDK 10.3.9. Leider startet das Kompilat nicht mehr unter Betriebssystemversionen vor 10.3.9. Gibt es eine Möglichkeit, unter 10.4 Programme zu erstellen, die auch unter 10.3.0 - 10.3.8 laufen oder muss man hierzu das Programm unter 10.3(.9) erstellen? (auf das 10.2.8-SDK kann ich leider nicht zurückgreifen wegen der Verwendung von Bindings) Danke, Tjark

Hab's doch noch wiedergefunden! Allerdings nur CList, CString und CPtrList - nicht CArray. Zu den einzelnen Klassen gibt's jeweils ein Konsolenprogramm als MSDev 4.2-Projekt. Die Klassen liefen dann aber auch ohne Modifikationen unterm gcc (unter Solaris). Download hier (93kB). Ist schon lustig, MFC-Quellen mit Developer Studio-Projekten in einem Mac-Forum zu posten...

Zitat: „ Soll ich einfach die header dateien mit auf den Mac kopieren und dann da so lange fehler ausbessern etc bis es irgendwann kompiliert??? *guckt unsicher*“ Im Prinzip, ja Ich würde damit anfangen, die reine Klassen-Definition von z.B. CArray in eine neue Header-Datei zu kopieren (z.B. CArray_T.h) und dann alles hinzu zu kopieren, was noch so benötigt wird (also die ganzen Template-Funktionen wie "ConstructElements", usw.), bis es kompiliert. Du musst dabei "straight forward" denken Wie ge…

Wenn das Template CArray in dem Code sehr viel benutzt wird, könnte sich auch eine Portierung von den Template-Klassen (evtl. auch CString) nach "Standard"-C++ lohnen. Das habe ich auch mal gemacht und es war gar nicht so aufwendig (die Klassen CList<> und CArray<> sind ja recht übersichtlich). Du kannst das ganze auch unter MSDev vorbereiten, in dem du ein Projekt für eine C++-Konsolenprogramm "ohne alles" (ohne MFC-Support) anlegst, die Header-Dateien für die Templates in das Projekt hineinkop…

Die Lösung ist, dass alle Objekte, die über Bindings Änderungen an den Defaults mitbekommen wollen, sich bei dem "shared defaults controller" ([NSUserDefaultsController sharedUserDefaultsController]) anmelden müssen, und nicht bei den "user defaults" ([NSUserDefaults standardUserDefaults]). Als zweites ist wichtig, sich nicht bei dem Objekt anzumelden, dass mittelsQuellcode (1 Zeile) zurückgegeben wird, sondern den key path selber zusammenzubauen und sich dann bei dem "shared defaults controller…