memark

Jag ser inte varför man ska krångla till det.

SELECT forumStructure.forumTitle, COUNT(*)
FROM forumPosts
JOIN forumThreads ON forumPosts.threadID = forumThreads.threadID
JOIN forumStructure.forumID = forumThreads.forumID
GROUP BY forumStructure.forumTitle

borde räcka. Ev med LEFT JOINS om du vill ha med lite nollvärden. Man kan ev modifiera queryn med en korrelerad eller okorrelerad subquery, men det är svårt att säga om det går fortare utan att känna till din data. Som vanligt får man prova sig fram. (Jag utgår från att du har index på dina foreign keys.)

Att lägga till en extra kolumn tycker jag känns enormt kladdigt. Normalisering av data ftw liksom! (Visst det finns fall när det är berättigat, men då snackar betydligt tyngre grejer än att räkna poster ur två tabeller.)

Man kan se ett dictionary som just en... ordbok. Det innehåller kombinationer av nycklar av värden. Man kan fråga "vilket värde finns för nyckeln x?" eller "vilken nyckel finns för värdet y?". Det låter mer komplicerat än det är, så analogin med en vanlig ordbok är inte så dum.

Det som händer här är att NSSpeechSynthesizer-objektets metod returnerar ett dictionary med en massa information. Det är alltså inte nåt som kodexemplet egentligen skapar.

(@"The string has %d characters", stringLength);

Så där kan man inte skriva. Det du menar är nog

[NSString stringWithFormat:@"The string has %d characters", stringLength]

Med några få undantag (tänker främst på BOM i Unicode) så går det inte att "kontrollera". Det man kan göra är snarare att anta olika teckenkodningar och se om det ser rimligt ut. Pss kan man göra mer eller mindre kvalificerade gissningar, men att VETA går egentligen inte.

Prova BBEdit, tror att även Lite-versionen har stöd för att spara i valfri teckenkodning.

Utöver detta är det min starka åsikt att du i största möjliga utsträckning bör välja UTF-8, om du inte har starka skäl emot.

Ylan, jag läser ditt inlägg med intresse. Rent tekniskt har du rätt i det mesta, men jag håller inte med om dina slutsatser. Just möjligheten att "gå ner ett lager" och "optimera metoder genom att skriva om dem i ett lågnivåspråk" åberopas ofta som viktiga instrument men det köper jag helt enkelt inte. Jag har inga siffror, men jag misstänker att det endast är i undantagsfall man nånsin behöver göra detta, och då enbart för t ex extremt beräkningsintensiva program. (Nu är min professionella systemutvecklarkarriär iofs bara inne på sitt tredje år, men jag tror mig ha ganska god koll på branchen.)

Med det sagt ser jag ändå inte hur detta skulle vara en fördel med Obj-Cs (alla äldre C-språks) antika minneshantering. I de allra flesta språk, så även t ex Java och VB/C#.NET kan man, vid behov, ändå använda pekare och allokera minne manuellt om behovet skulle uppstå. Vilket det mycket sällan gör. Det är alltså inte främst GC jag är för, utan möjligheten att helt abstrahera bort det faktum att datorn har ett fysiskt internminne (precis som man redan gjort med nätverksströmmar, filpekare, filallokeringstabeller mm).

Nu är vi på väg mot ett programmeringsspråkskrig, men jag kan inte låta bli... Pratar du om gamla VB 6 och tidigare här eller? Isf håller jag med om att det är lite spaghetti över det. VB.NET (som kom 2002 och är det enda som används numera) är helt objektorienterat och jämlikt med t ex C# (om inte bättre).

Att pekare och manuell minneshantering skulle vara "smidigare och vettigare när man väl lärt sig" har jag svårt att se. Möjligen att det är lite "coolt" att jobba närmare hårdvaran. Men det finns ju en anledning till att programmeringsspråk hela tiden blir mer och mer högnivå, och det man ser till att bli av med är just att behöva sköta sådant manuellt (det tar massor av tid, ger snudd på inga fördelar, och ger hemska buggar när man missar något). Jag är uppriktigt nyfiken på vilka fördelar du ser med att manuellt behöva ägna sig åt detta.

När du säger att VB är "rakare" menar du då enbart att det är mer högnivå och inte så mycket trassel med pekare och minneshantering?

Det finns många åsikter om XCode. En av dem är just den du uttrycker, att det är svårt och krångligt att förstå sig på.

goranlin, jag säger inte att detta gäller dig, men många har en ogrundad rädsla för just terminalen. Den är egentligen inte konstigare än något annat program, och risken att förstöra nåt är inte heller större. Om man så bara skaffar sig minimala kunskaper om den tycker jag att förståelsen för OS X växer nåt enormt. Med det sagt föredrar även jag grafiska GUIn.

Mig veterligen finns ingen selector i CSS som kan läsa av en kontrolls värden på något sätt. Jag skulle ändra class på radioknappen som blivit vald och stajla denna, antingen i onClick-eventet med JavaScript eller serverside vid postback (vilket verkar onödigt att göra förstås).

input[type="radio"] fungerar för övrigt inte i Internet Explorer 6, så den varianten kan du nog glömma ändå.

Prova denna content type på link-elementet, funkar i de flesta läsare trots sitt proprietära utseende.

<link rel="shortcut icon" type="image/vnd.microsoft.icon" href="favicon.ico" />

Du borde lägga till möjligheten att dela med sig på lite kändare ställen också, typ Facebook och Dig.

Vill du åstadkomma fetstilen mha css, javascript eller server side?

Det var bl a det jag skrev om ovan. Kolla på Response-elementet i web.config som sagt.

Fast grejen är ju att meta-elementet bara används i undantagsfall, när servern inte skickar ut någon http-header. Jag tror det finns ett @Page-direktiv för det också. Sen kan du kolla vilka värden du har på Encoding för Request- och Response-elementen i Web.config. Poängen är att ha samma överallt typ. Personligen föredrar jag UTF-8 överallt, men du kanske har andra skäl att välja gamla Windows-1252?