IBAction / IBOutlet in Class-Files unter Xcode 3.0

[Micky2007]

Hallo Leute,

bin MacOS X - Programmier-Anfänger und kämpfe immer noch damit, dass die ganze Programmierbeispiele, die es gibt (von Hillegass, von developer.apple.com) scheinbar noch auf XCode 2.5 basieren.

Wenn ich im Interface-Builder von meinen Steuerelementen mit Ctrl-Klick Verbindungen für die Outlets und Actions zu meiner Klasse MyClass ziehe, dann funktioniert das erstmal ganz gut und unter Connections im Inspector wird auch alles prima angezeigt.

Wenn ich jetzt jedoch (mit Speichern) den IB verlasse und mir die Dateien MyClass.h und MyClass.m anschaue, dann ist da nichts von den Definitionen meiner Connections zu sehen. Kein IBOutlet, kein IBAction. Ich muss die Connections hier also nochmal definieren, z.B.:

IBOutlet NSTextField *textEingabe;
}
-(IBAction)go: (id)sender;

Das funktioniert auch prima, jedoch meine ich, dass der IB doch das alles schon hätte machen können und sollen. Oder liege ich da falsch? Ich habe schon vieles probiert, z.B. "Write Class Files" und "synchronize with Xcode" aufgerufen, doch die Class-Files bleiben immer ohne die Connections.

Leider habe ich keinen Vergleich zu XCode 2.5 und will mich ehrlich gesagt auch nicht mehr damit beschäftigen. Deshalb meine Frage...

Grüße
Micky

 

[below]

bin MacOS X - Programmier-Anfänger und kämpfe immer noch damit, dass die ganze Programmierbeispiele, die es gibt (von Hillegass, von developer.apple.com) scheinbar noch auf XCode 2.5 basieren.

Du kannst Xc2.5 auch neben Xc3 auf Leopard installieren. Für viele Anfänger ist das der leichteste Weg.

Ich habe schon vieles probiert, z.B. "Write Class Files" und "synchronize with Xcode" aufgerufen, doch die Class-Files bleiben immer ohne die Connections.

Das sollte aber eigentlich funktionieren.

Unter Xc2.5 musst Du die Class files neu schreiben lassen ("Write Class Files")

Alex

 

[iCode]

Die Connections sieht man nicht im Code.

 

[SumpfMonsterJun]

Mit Xcode 3 hat sich Apple von der bisherigen Philosophie im IB verabschiedet und eine klare Trennung vollzogen:

Xcode für selbstgeschriebenen Code, IB für die Oberfläche. Es ist zwar nach wie vor möglich, Outlets und Actions im IB anzulegen, allerdings rät Apple dazu, dies in Xcode zu tun. Die Integration beider Werkzeuge ist nun noch enger, dh Du musst nicht mehr "Synchronize with Xcode" aufrufen, wenn beide Programme laufen.

Schreibe einfach Outlets/Actions in Xcode und sofort erscheinen sie im IB.

Diese Trennung ist gerade im Hinblick auf Versionskontrollsysteme sinnvoll (klare Trennung von handgeschriebenen und generierten Code).

Auch die Instanzierung neuer Objekte (meistens selbstgeschriebene Controller) ist nun "live" möglich, ohne die Headerdatei in den IB zu ziehen, wie dies in vielen Büchern beschrieben ist (zB Hillegas). Einfach ein NSObject in den Nib ziehen, dann im Inspector die mit Xcode erstellte Klasse auswählen.

Ich hoffe das hat fürs erste geholfen,

beste Grüße, SMJ

 

[below]

Diese Trennung ist gerade im Hinblick auf Versionskontrollsysteme sinnvoll (klare Trennung von handgeschriebenen und generierten Code).

Das ist jetzt etwas off-topic, aber da sehe ich jetzt keine wirkliche Veränderung von IB2 zu IB3. Auch mit IB2 wurden Outlets nicht einfach im NIB o.Ä. generiert (wie bindings), sondern mussten auch in Dateien geschrieben werden. Damit waren sie dann auch für die Versionskontrolle zu verarbeiten.

Alex

 

[SumpfMonsterJun]

Ja das stimmt, allerdings schrieb der IB2 ja u.U. direkt in den Sourcecode (write classes...), das wird nicht immer gerne gesehen, obwohl es der versionsverwaltung natürlich egal ist.

Es ist einfach ein logische Trennung so wie Straße/Fußweg die von vornherein evtl. Probleme vermeidet.

Gruß, SMJ

Nachtrag: In manchen Fällen fassen automatische Generatoren dann Sourcecode an, ohne ihn wirklich zu verändern, das bewirkt dann aber trotzdem eine Veränderung für die VVW. Für den Programmierer erscheint die Datei dann als geändert, obwohl er sie garnicht angefasst hat - das kann verwirrend sein.

 

[below]

Ja das stimmt, allerdings schrieb der IB2 ja u.U. direkt in den Sourcecode (write classes...), das wird nicht immer gerne gesehen

Das macht der IB3 ja auch noch... wenn man es will.

Und den Hinweis, dass man besser alles im Sourcecode macht gab es auch schon bei Xc/IB2 -- insb. weil IB2 schlimme Probleme beim Mergen -- siehe oben -- verursachen konnte.

Ist ja auch egal. Die Tatsache, dass IB3 die Actions und Outlets ohne mein Zutun erkennt ist sehr hilfreich.

Alex

 

[Micky2007]

Also ich fass das jetzt nochmal zusammen:

1. Der neue IB3 erkennt Outlets und Actions jetzt als Connections wenn sie in XCode gecoded worden sind.

2. Auch im IB3 kann man mit ALT-Drag Outlets und Connections bilden.

Nur gerade mit 2. hab ich ja meine Probleme. Wenn ich das mache, tauchen diese in XCode nicht auf. 1. geht natürlich, aber das möchte ich ja gerade nicht. Spart Tipparbeit

Grüße
Micky

 

[below]

2. Auch im IB3 kann man mit ALT-Drag Outlets und Connections bilden.

Huh? Mit alt-drag erzeuge ich bei mir Duplikate.
Outlets und Actions erzeuge ich im Identity Inspector (⌘6)
Connections erzeuge ich mit Control-Drag.

Nur gerade mit 2. hab ich ja meine Probleme. Wenn ich das mache, tauchen diese in XCode nicht auf.

Dazu muss ich tatsächlich auch "Write Class Files…" machen, dann geht FileMerge auf und erlaubt mir Korrekturen.

Alex

 

[SumpfMonsterJun]

Das macht der IB3 ja auch noch... wenn man es will.

Und den Hinweis, dass man besser alles im Sourcecode macht gab es auch schon bei Xc/IB2 -- insb. weil IB2 schlimme Probleme beim Mergen -- siehe oben -- verursachen konnte.

Ist ja auch egal. Die Tatsache, dass IB3 die Actions und Outlets ohne mein Zutun erkennt ist sehr hilfreich.

Alex

Hauptsache immer das letzte Wort...

 

[Micky2007]

Huh? Mit alt-drag erzeuge ich bei mir Duplikate.
Outlets und Actions erzeuge ich im Identity Inspector (⌘6)
Connections erzeuge ich mit Control-Drag.

Klar, entschuldige bitte, ich war noch nicht ganz wach...

Dazu muss ich tatsächlich auch "Write Class Files…" machen, dann geht FileMerge auf und erlaubt mir Korrekturen.

Das probier ich nachher mal, dank Dir!