Ich glaube nicht, dafl man das ohne weiteres rausbekommt, da letztendlich alle Programme ¸ber eine API gestartet werden und das die Information, wie der Weg dorthin war, verloren ist (evtl. kann man aus dem Namen des Users der das Programm gestartet hat weitere Informationen ableiten, aber das ist ziemlich unsicher und eigentlich nur fortgeschrittenes Raten)

Allerdings f‰llt mir jetzt gerade keine Anwendung f¸r diese Information ein - wozu h‰ttest du denn diese Information benˆtigt?

Eine Unixlˆsung (Aufruf EINES Programmes mit verschiedenen Namen) liefle sich auch mit Umwegen f¸r ein Bundle implementieren (zB. compress/decompress linken auf dasselbe Executable sind, dessen Defaultparameter sich aber je nach benutzten Namen ‰ndern). Diese Technik macht aber bei GUI-Anwendungen irgendwie keinen richtigen Sinn mehr...

Also, direkt in Cocoa glaube ich geht das nicht. Aber, da Mac OS X ja auch ein Unix ist, sollte es in der BSD-API doch eine Mˆglichkeit geben. Da kann man doch bestimmt den "parent"-Prozess erfragen. Welche Funktion das liefert weifl ich jetzt aber nicht, muss ich auch erst mal suchen.

Michael

Original von WhitMan
Ich muss wissen ob mein Programm durch den CronTable oder durch den User gestartet wurde, weil das Programm im ersten Fall nur ein paar sachen machen, und sich ganz still wieder verpieseln soll.

Du kannst dem Programm Parameter ¸bergeben, mit diesen kannst du unterscheiden, ob das Programm ganz normal (=keine Parameter) oder per crontab (=mit Parameter gestartet wurde). Das ist nicht dasselbe, wie rauszubekommen, durch wen man gestartet wurde, aber es ist einfacher und sollte den selben Zweck erf¸llen.

ƒhem,

sorry - das war ein Ausschnitt aus einem Programm, der so nicht zu kompilieren ist.

Wichtig ist eigentlich nur der Zugriff auf NSProcessInfo und das Einbinden der entsprechenden Headerfiles(Foundation). Leider sitze ich gerade nicht am Mac und will jetzt nix falsches zusammenl¸gen (Quelltext aus dem Kopf zusammengetippt haben IMMER Fehler...)

Aber als "Hilfe":

die @"" bei den compare Statements m¸ssen auf deine Bed¸fnisse angepaflt werden (das sind die Schalternamen, zB. "crontab"). Das Zeuch mit [self *] wird bei dir nicht funktionieren, weil du die entsprechenden Methoden nicht hast, anstelle dieser Aufrufe mufl deine Logik rein (halt das, was den Unterschied zwischen crontab und GUI Aufruf "schaltet", zB. [self setCrontabMode:YES] - whatever...).

Wenn du das Foundationframework includest und die [self] Teile rausnimmst, m¸fltest du die Routine in den designated initializer deines Models einbauen kˆnnen (oder wo auch immer).

Ok, ich kann das auch in ein Programm extrahieren, welches man compilieren kann...

Original von WhitMan
OK ich habs hingekriegt.

WhitMan

In nicht mal einer Stunde... So gehts voran

Original von WhitMan
Nur zu deiner Info ich hab nicht die ganze Zeit gearbeitet, und nebenbei nicht deinen Vorschlag genommen sondern selbst was gebastelt...

Ach deswegen hat es so lange gedauert (*duck*)

Wieso, 50 Minuten sind nicht so schlecht, bis man sich durch den Sumpf der Apple Doku durchgearbeitet und die Teile extrahiert hat, die man braucht...

Meins is sowieso viel besser

Davon bin ich ¸berzeugt. Das sage ich ja auch immer...

NSEnumerator ist ganz simpel. Dazu soll uns mal ein Beispiel helfen:

ohne NSEnumerator, mit Array:

geg: NSArray *array;

id obj;
int i;

for (i=0; i<[array count]; i++)
{
&nbsp;&nbsp;obj = [array objectAtIndex: i];
&nbsp;&nbsp;//code
}


mit NSEnumerator, aus den Array:

geg: NSArray *array;

NSEnumerator *enu = [array objectEnumerator];
id obj;

while (obj = [enu nextObject])
{
&nbsp;&nbsp;//code
}


kloa? Machmal macht's Sinn und manchmal ist es umst‰ndlicher.
HTH

grufl
MAX

Er hat den Vorteil, dass du ihn nicht manipulieren kannst. Also kannst du z.B. in einer Callback-Funktion einen Enumerator zur¸ckgeben, damit man nicht das Array, aus dem es stammt, manipulieren kann.

Sonst f‰llt mir nichts ein.

Doch: er ist etwas unkomlizierter, der Code.

Ich nehme auch immer die manuelle Methode

gruten Rutsch
MAX

Auflerdem ist NSEnumerator egal wo die Enumeration herkommt. Ob Du den Enumerator von einem NSArray, NSDictionary oder NSSet (oder einer eigenen Klasse) kriegst ist egal der Code bleibt gleich:

id *collection;

NSEnumerator *e = [collection objectEnumerator];
id x;

while x = [e nextObject])
{
//code
}

sieht nach wenig aus, kann aber viel Arbeit sparen...

Original von WhitMan
Mich w¸rde allerdings mal interessieren ob wirklich was dran ist das NSEnumerator in der Ausf¸hrung langsamer ist als die manuelle Methode, und eventuell sogar wie viel langsamer.

Keine Ahnung.

Original von WhitMan
Hat jemand ne Idee?

Mess es doch einfach mal aus.

Michael