morris

AppKiDo tror jag läser Apples docs, och den är open source så kanske går att klura ut hur den gör.

Kikat på SVK? Det är ett distribuerat system som sitter ovanpå ett vanligt Subversionrepository. Du får funktionalitet som push och sync, etc, medan folk kan jobba på som vanligt med Subversion.

http://svk.bestpractical.com/view/HomePage

Hmm. Testat med ibtool/nibtool? Det är ett commandlineverktyg som kan analysera nibbar. Kanske går att konvertera med det?

När man förändrar attributen på en NSView kör den vanligen -setNeedsDisplay:YES vilket gör att de kommer ritas om i nästa iteration av runloopen. Du skulle kunna testa att skicka -display till textfältet, vilket ska rita om det omedelbart.

Jag antar att du har någon sorts controllerobjekt för fönstret du har dina textfält i. Det objektet passar utmärkt att använda som delegat för fälten.

I Interface Builder, control-dra från varje textfält till ditt controllerobjekt och anslut dem till outleten "delegate". Det här gör att ditt objekt blir fältens delegat. I IB bör du också sätta upp din kedja av key views, så att den hoppar till rätt fält senare. Dra först en connection från fönstret till det första textfältet, anslut det till fönstrets outlet "initialFirstResponder". Det här är fältet som ska ha fokus när fönstret först öppnas. Dra sedan en connection från det fältet till nästa fält, anslut "nextKeyView". Gör samma sak med resten av textfälten. På det sista fältet, dra en connection till det första, anslut "nextKeyView".

I ditt controllerobjekt lägger du sedan till den här koden:

- (void)controlTextDidChange:(NSNotification *)notification {
	NSTextField		*textField;
	
	textField = [notification object];
	
	if([[textField stringValue] length] == 1)
		[[self window] makeFirstResponder:[textField nextKeyView]];
}

Det här implementerar metoden -controlTextDidChange:. När man skriver i textfälten kommer de kolla om de har en delegat och om delegaten svarar på den metoden, vilket du gör, alltså körs den. Vi får textfältet i NSNotifications -object och plockar ut det. Kollar sedan längden på strängen och om den är ett, ber fönstret flytta fokus till nästa textfält.

Eftersom du vill associera två värden med varandra låter det som du vill använda ett dictionary snarare än en array. Då kan du använda metoden -keysSortedByValueUsingSelector:, såhär:

NSEnumerator		*enumerator;
	NSMutableDictionary	*letters;
	NSArray				*keys;
	NSString			*letter;

	letters = [NSMutableDictionary dictionary];
	[letters setObject:[NSNumber numberWithInt:5] forKey:@a];
	[letters setObject:[NSNumber numberWithInt:15] forKey:@e];
	[letters setObject:[NSNumber numberWithInt:10] forKey:@i];
	
	keys = [letters keysSortedByValueUsingSelector:@selector(compare:)];
	enumerator = [keys reverseObjectEnumerator];
	
	while((letter = [enumerator nextObject]))
		NSLog(@"%@: %@", letter, [letters objectForKey:letter]);

NSTextField är en NSControl, så den skickar metoden -controlTextDidChange: till sin delegat varje gång användaren ändrar texten i fältet. Där kan du lägga in din kod för att hoppa vidare till nästa fält automatiskt. Du styr fokus med NSWindow-metoden -makeFirstResponder: och du kan fråga ditt NSTextField om vilket som är nästa fält med -nextKeyView:

[window makeFirstResponder:[textField nextKeyView]];

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSControl_Class/Reference/Reference.html#//apple_ref/occ/instm/NSObject/controlTextDidChange:

Du kanske ska installera Xcode 2.5 parallelt med 3.0? Då får du den äldre Interface Builder som kanske har större chans att öppna nibben.

Det finns ingen sådan metod i kitet, och om du ska göra en sån själv kommer det att involvera -containsObject: vilket som sagt inte är helt effektivt tidskomplexitetmässigt. En alternativ lösning skulle kunna vara att använda NSSet, som är lite snabbare på sånt. Till exempel (antag att array1 och array2 finns och du vill jämföra dem):

NSMutableSet		*set;
unsigned int		count;

set = [NSMutableSet setWithArray:array1];
[set intersectSet:[NSSet setWithArray:array2]];
count = [set count];

Kolla NSArrays -componentJoinedByString:

+soundNamed: returnerar objekt från en intern lista av ljud, precis som NSFonts +fontWithName:size: gör, vilket gör att det råkar funka eftersom NSSound själv retainar objekten. Dock är det här absolut inget man ska lita på, så protokollen för objektägarskap gäller: du är skyldig att retaina NSSound-instansen om du vill behålla den utanför det omedelbara scopet.

1. Du skriver en actionmetod som vanligt och upprätthåller helt enkelt nåt sorts state. Här är ett exempel på en action jag skrivit som togglar repeat mode för en mediaspelare mellan tre olika state och byter bild på knappen beroende på vilket läge som är aktivt:

- (IBAction)repeat:(id)sender {
    SPPlaylistRepeatMode    repeatMode;

    repeatMode = [self repeatMode];
    
    if(repeatMode == SPPlaylistRepeatOne)
        repeatMode = SPPlaylistRepeatOff;
    else
        repeatMode++;
    
    [self setRepeatMode:repeatMode];
}

- (void)setRepeatMode:(SPPlaylistRepeatMode)repeatMode {
    NSString        *image;

    _repeatMode = repeatMode;

    switch(_repeatMode) {
        case SPPlaylistRepeatOff:   image = @RepeatOff;   break;
        case SPPlaylistRepeatAll:   image = @RepeatAll;   break;
        case SPPlaylistRepeatOne:   image = @RepeatOne;   break;
    }

    [_repeatButton setImage:[NSImage imageNamed:image]];
}

- (SPPlaylistRepeatMode)repeatMode {
    return _repeatMode;
}

Finns ett stort värde att få en headstart med sin Leopardutveckling, så att ens befintliga applikationer garanterat kommer fungera på releasedagen, eller att din Leopard-only-app kommer kunna släppas snabbare eftersom du redan utvecklat i ett år.

Du slipper allokera fem olika instanser, så viss prestandaskillnad kan säkert uppmätas. I just det här fallet tycker jag det enbart är en fråga om vad som ser tydligast ut i koden, då prestandaskillnaden kommer vara extremt låg. Gör du samma sak i en tight loop och räknar med att behandla tusentals rader i din fil blir det en annan fråga. Men som alltid, skriv det som blir enklast först, optimera om du märker att det går för långsamt, och använd alltid, alltid Shark för att försäkra dig om att du optimerar rätt saker.

Om du kikar i Xcode run log när du startar ditt program kan man se följande:

2007-04-05 10:12:17.194 windowsColourTest[27449] An uncaught exception was raised
2007-04-05 10:12:17.209 windowsColourTest[27449] *** -redComponent not defined for the NSColor NSCalibratedWhiteColorSpace 1 1; need to first convert colorspace.
2007-04-05 10:12:17.209 windowsColourTest[27449] *** Uncaught exception: <NSInvalidArgumentException> *** -redComponent not defined for the NSColor NSCalibratedWhiteColorSpace 1 1; need to first convert colorspace.

Du kan läsa mer om color spaces här, men lite kort kan man säga att du har fått en färg i en color space där du inte kan be om röda komponenten, och du måste konvertera den till något annat, lämpligen NSCalibratedRGBColorSpace:

- (void)changeColor
{
	NSColor		*color;
	
	color = [[myColorPanel color] colorUsingColorSpaceName:NSCalibratedRGBColorSpace];
	
	[myWindow setBackgroundColor: color];
	[myWindow display];	
	
	[redComponentTextField setFloatValue: [color redComponent]];
	[greenComponentTextField setFloatValue: [color greenComponent]];
	[blueComponentTextField setFloatValue: [color blueComponent]];
}

Det finns lite andra problem i din kod dock. Nån annan har redan tagit upp problemet med att ha en instansvariabel till NSColorPanel +sharedColorPanel. Nu råkar den vara en singleton så det fungerar, men det är mycket möjligt att den skulle kunna byta ut sig själv mot en annan instans av NSColorPanel senare, och då har du en sparad pekare till något som är deallokerat. Bättre att fråga efter +sharedColorPanel i varje metod du behöver använda den istället.

Din metod actionChangeColor tar ingen parameter, men actions ska alltid ta en parameter, sender. Definierar om den till - (void)actionChangeColor: (id)sender. Notera att actionChangeColor och actionChangeColor: är helt olika metoder. Du använder även NSSelectorFromString() i -setAction:, när du kan (och bör) använda @selector() istället:

[myColorPanel setAction: @selector(actionChangeColor:)];

Kan ju försöka med s_client i debugläge och se om det ger mer information:

$ openssl s_client -debug -connect www.apple.com:443

Ett vanligt problem med SSL är olika versioner mellan klient och server, t ex SSL 2.0, SSL 3.0 och TLS 1.0. Du kan peta in -ssl2/-ssl3/-tls1 för att tvinga fram en viss version med s_client.

Går att köra lock-modify-unlock-modellen även med Subversion om man nu vill det:

http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html#svn.basic.vsn-models.lock-unlock
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html