Obj-C Eine Nachricht an mehrere Objekte

[starknights]

Hallo,

ich geb jetzt erstmal google auf und hoffe, einer von euch kennt die richtige Syntax.

Angenommen ich habe 10 Textfelder als IBOutlet erstellt,
feld1, feld2, feld3, usw.

kann ich in dann die Objekte in einer for Schleife mit der Variable ansprechen, nach dem Motto:

for (i=1;i<=10;i++){
[('feld'+i) setIntValue:i*10];
}

bzw. überhaupt "variable Varbiablennamen" verwenden, wie ich das in php machen würde:
$variablenname="variable".$i;
$$variablenname=$i*10;

In meiner Verzweiflung hab ich schon mit sprintf und so rumgespielt, aber ich denke jetzt ist einfach mal fragen angebracht, die compiler fehler gehen mir doch langsam auf die nerven beim ausprobieren

Grüße,
Micha

 

[anegmawad]

Für Objecive-C der völlig falsche Ansatz. Bitte lies etwas Einführendes.

 

[starknights]

Hi Anegmawad,

genau das mache ich gerade, und da werden halt die (in dem Fall 5) Textfelder alle einzeln hintereinander mit der gleichen Nachricht angesprochen, kam mir halt irgendwie als unpraktisch vor, wenn es mal mehr Felder werden.

Kannst du bitte kurz erläutern, warum es der völlig falsche Ansatz ist, würde das gerne verstehen

Viele Grüße,
Micha

 

[anegmawad]

Ein Konzept in drei Zeilen erläutern?

Also, die Kurzfassung: Was du machst, ist es Variablennamen zusammenzubauen. Objective-C wird compiliert. Daher verschwinden die Symbole. (Das ist nicht wirklich richtig, über die Laufzeitumgebung kommst du noch heran, davon bist du aber weit entfernt.)

Für deine Anwendung gibt es View-Hierarchien und Tags.

 

[SumpfMonsterJun]

Klinke mich mal ein und erläutere, was Amin mit Viewhierarchien gemeint hat:

Du würdest die Textfelder in eine NSForm packen (via IB), jeweils mit einem Tag versehen und dann über das Interface von NSForm ansprechen.

Eine weitere Möglichkeit wäre es, die Outlets in ein NSArray zu packen und dann dem Array die Nachricht makeObjectsPerformSelector: bzw. makeObjectsPerformSelector:withObject: zu schicken, allerdings ist das schmutziges, "von-hinten-durch-die-Brust-ins-Auge" Gehacke und wie Amin schon sagte, davon bist Du weit entfernt.

Also, zurück zu Post #2 dieses Threads...

Beste Grüße, SMJ

 

[starknights]

Hallo erneut, erstmal danke.

Zurück zu #2 ist ja gerade die Sache ^^

Hab vor einem Jahr mal ein einfaches Spiel in Obj-C gebastelt, lief wider Erwarten sogar, aber halt mehr php Stil als Obj-C...
Ja und jetzt hab ich mich mal wieder dran gesetzt und versuche das Ganze mal stilgerechter zu lernen und arbeite daher das Buch Cocoa Programming for Mac OS X durch, was überall so empfohlen wird, und die Seite http://cocoa-coding.de/ durch. (muss ich hier grundsätzlich mal empfehlen, endlich mal was für Einsteiger in Cocoa, was auf deutsch ist )

Und genau hier störte mich bei dem Lottozahlen Beispiel, dass die Felder alle einzeln gefüllt werden.
Mit dem NSForm scheine ich dann ja das Ganze umgehen zu können. Danke schonmal für den Tipp, muss ich mir gleich mal anschauen

Aber alte Angewohnheiten wird man schwer los, wäre es denn theoretisch möglich, das ganze ohne NSForm über NSInvocation zu lösen?
Ich meine der Punkt an dem ich hänge (offensichtlich und nochmal sorry dafür) ist dass ich immer wieder was lese von wegen Ziel und Typ würde erst zu Laufzeit bestimmt, daher hab ich halt gehofft, es gäbe etwas wie findeObjektDasDiesenNamenHat.

Soweit die Theorie.

Gleiches gilt dann, wenn ich einen Controller (c) habe, der x Objekte erzeugt hat und nun eines von diesen erzeugten Objekten (a) eine Nachricht an ein anderes Objekt (b) schicken möchte, dann muss das immer über den Controller gehen, der einen Pointer auf (b) an (a) zurückgibt, richtig?

Ich möchte euch damit wirklich nicht nerven, ich versuche nur diesmal alles genau zu verstehen, damit ich am Ende nicht wieder mit so einem "sieht nach prozeduralem php-code aus" Ergebnis rumwerkel.

---
Und ja. Ich bin verwirrt durch den Umstieg von prozeduralem Scripten zu Objektorientiertem Programmieren. Hoffe, das gibt sich bald

 

[anegmawad]

Du brauchst auch kein NSForm, wenn du nicht willst. Wie bereits gesagt gibt es Viewhierarchien.

Mach um deine Textfelder einfach eine Superview, meinetwegen eine unsichtbare Box und dann ein Outlet auf die Box

for( NSView* view in [superbox subviews] ) 
{
   [view …];
}

Oder gleich wie oben dargestellt:

NSArray* views = [[superbox subviews] makeObjectsPerformSelector:…];

Wenn von den erzeugten Objekten eines eine Nachricht an ein anderes schicken möchte, dann sollte es einen Verweis geben. Wenn an alle Objekte eine Nachricht geschickt werden soll, sollte das eine übergeordnete INstanz tun.

 

[norbi]

Ich würde einen Binding-Controller verwenden und (daher) gar nix programmieren (müssen).

Btw, es gibt auch ein Buch auf Deutsch. Da ist ua. Deine Aufgabenstellung genau beschrieben.

Weiß nicht, ob jemand hier ist, der das Buch auch kennt

No.

 

[anegmawad]

Ich würde einen Binding-Controller verwenden und (daher) gar nix programmieren (müssen).

Btw, es gibt auch ein Buch auf Deutsch. Da ist ua. Deine Aufgabenstellung genau beschrieben.

Weiß nicht, ob jemand hier ist, der das Buch auch kennt

No.

Ich weiß gar nicht. Es gibt ein Beispiel von Klaus, das ähnlich funktioniert. Mich hat das etwas geärgert. Aber auf jeden Fall ist genügend Material zu Viewhierarchien drin, dass man sieht, wie es eleganter gelöst wird.

 

[starknights]

Wenn von den erzeugten Objekten eines eine Nachricht an ein anderes schicken möchte, dann sollte es einen Verweis geben.

Das bedeutet jetzt den Controller eine Anfrage schicken, einen Pointer auf das andere Objekt zurückzugeben und den verwenden, oder wäre das auch wieder unsauber?

 

[norbi]

Na gut, weil ich nicht so bin:
"Objective-C und Cocoa - 2. Auflage"

Hab' mich auch lange gequält. Buch gekauft. Gut war's.

No.

 

[anegmawad]

Das bedeutet jetzt den Controller eine Anfrage schicken, einen Pointer auf das andere Objekt zurückzugeben und den verwenden, oder wäre das auch wieder unsauber?

Also, es ist etwas schwierig zu beantworten, wenn das so allgemein bleibt. Daher muss ich auch allgemein bleiben.

Ein Controller verwaltet üblicherweise eine Ansammlung von Instanzen im Model. Das Model ist in der Regel methodenarm. Dass überhaupt eine Model-Instanz Nachrichten verschickt ist selten. Aber es kann natürlich vorkommen.

Wenn es vorkommt, dann sollte das Model autark sein. Stell dir das Model als Keller eines mehrstöckigen Hauses vor. Der Keller muss sich schon selbst tragen und nicht von dem Erdgeschoss (Controller) gehalten werden.

Wenn da also eine Kommunikation abläuft, sollte das Model die Beziehungen zu anderen Objekten bereits selbst kennen und niemanden außerhalb danach befragen.

Wenn das aus irgendwelchen Gründen nicht geht, so ist es in der tat die Aufgabe des Controllers, zusammenzuführen, was zusammen gehört.

 

[starknights]

Na gut, weil ich nicht so bin:
"Objective-C und Cocoa - 2. Auflage"

Hab' mich auch lange gequält. Buch gekauft. Gut war's.

No.

Hab die erste Auflage hier liegen und beim letzten Versuch mit Obj-C anzufangen verwendet. Da natürlich nach dem ersten drittel prompt Obj-C2 rauskam war ich total gefrustet und hab erstmal wieder aufgehört und diesmal auf "Cocoa Programming for Mac Os X" gesetzt. Aber mir scheint, ich sollte das andere ruhig nochmal zu Rate ziehen. An den Basics scheint sich doch nicht so viel getan zu haben. Und irgendwie wird bei allen Beispielen die Speicherverwaltung doch immernoch per Hand gemacht. Das war's worauf ich mich eigentlich am meisten gefreut habe bei Obj-C, dass das entfällt.

Aber ok. Ich danke euch erstmal allen!
Habe jetzt wieder 'ne Meng zum nachlesen und grübeln
Melde mich bestimmt demnächst wieder

 

[anegmawad]

Nein, die Konzepte haben sich nicht geändert. Es geht bei Objective-C 2 vor allem um Bequemlichkeitssachen,was bei GC schon sehr viel ist. Aber dann mache es so, wie in den Handwerksregeln angezeigt. Die synthetisierten Accessoren machen es auch nicht anders. (Zufall, wo ich die doch noch gar nicht kannte?)

Am besten du liest vielleicht mal das Kapitel 9. Das dürfte deine aktuellen Fragestellungen beantworten. Weniger wegen des konkreten Kots als mehr wegen des prinzipiellen Aufbaus. Und der hat sich seit Smalltalk-80 nur am Rande verändert.

 

[HJOrtmann]

Weniger wegen des konkreten Kots

Ich oute mich als alten "C"-Sack - deshalb hat mir diese Stelle besonders gut gefallen