Negativa handikapp

Golfhandikappet som de flesta spelare har är ett negativt nummer, men det skrivs alltid utan minustecken, istället skrivs ett plustecken ut för de få spelare som faktiskt har ett plushandikapp. Handikappet en spelare har är ju något som ska dras av från resultatet. Om jag som har 18 i handikapp slår 90 slag på en golfrunda är mitt nettoresultat alltså 90 - 18 = 72 slag. Mitt handikapp är alltså -18, och inte 18 som är vedertaget. På samma sätt fungerar det för en plushandikappare, om en spelare med hcp +2 slår 72 slag på en runda blir dennes spelare resultat 72 + 2 = 74 slag netto. Det är väl normalt att hela golf sverige tar bor minustecknet framför sitt handikapp eftersom majoriteten har ett negativt handikapp, och de som har ett positivt handikapp uttryckligen skriver ett plustecken framför sitt handikapp. Matematiskt däremot är detta förkastligt. Gemene man säger att man sänker sitt handikapp när man spelare bättre än sitt handikapp. Säg att jag som har -18 i handikapp får 37 poäng på en runda, då blir mitt nya handikapp -17.7. Detta är ju en höjning! Och om jag får mindre än 33 poäng så blir mitt handikapp -18.1, vilket är en sänkning! Helt tvärtemot vad som är vedertaget i golfsverige! Detta struntar såklart C# koden i, och det är detta jag har sysslat med den senaste tiden, att lagra alla handikapp som negativa nummer i databasen, jag har även fått ändra alla sorteringsordningar och jämförelser. Inför detta projekt har jag skrivit dokument som beskriver olika typer av tänkta användare för golfprogrammet, och jag hade helt missat elitspelare, som ofta har plushandikapp. En sak som skulle ha varit halvjobbig att fixa innan extensions kom till är att skriva ut -18.0 som 18 (utan minustecken) och 2 som +2 (med plustecken), men detta fixade jag lätt med en extension på Decimal typen. public static string ToHcpString(this decimal? value) { string returnValue = ""; if (value.HasValue) { //Check if this is a plus handicapper if (value > 0) returnValue = "+" + value.ToString(); else returnValue = value.ToString(); //Remove any minus signs returnValue = returnValue.Replace("-", ""); } return returnValue; }

WPF Elementhost

Nu börjar programmet bli klart för att betatestas av många fler personer. Todo-listan börjar krympa. Applikationen är alltså en Winforms applikation med vissa WPF-kontroller som integreras i WinForms med kontrollen elementhost. Microsoft hävdar att denna kontroll är perfekt att använda för att stegvis migrera en winform applikation till WPF eftersom man kan migrera kontroll för kontroll, eller ett formulär i taget, genom att skapa wpf-kontroller som man "hostar" i elementhost. Perfekt tänkte jag, den ska jag använda eftersom jag redan var klar med en stor del av gränssnittet och ville inte bygga om det jag redan gjort med Winforms, utan hellre fortsätta med WPF för det som inte är klart i programmet. Tyvärr har det visat sig att elementhost inte är helt ok, den läcker minne och uppträder segt vid resize händelser. Jag hade en usercontroll som visade grundläggande statistik för en spelare. Detta var alltså en vanlig winform userkontroll från början som jag sedan migrerade till en WPF-kontroll. Denna kontroll skapade jag en gång per användare i en panel så att det då visade fem sådana kontroller om det fanns fem användare i systemet. För att migrera detta skapade jag en WPF kontroll som ritade samma sak, och "hostade" den i en elementhost, som jag skapade en gång per användare i systemet. Till en början var jag nöjd med denna lösning, det gick fort att skriva om koden till detta, det enda jag behövde göra i grundapplikationen var att lägga till en elementhost med en WPF-userkontroll till befintlig applikationslogik. (Förutom själva koden för WPF-kontrollen så klart.) När jag sedan testade resize, olika antal kontroller (spelare), med mera, märkte jag hur applikationen blev segare och segare. Jag öppnade taskmanagern och ser att för varje resize ökade minnesanvändningen med ca 10MB, men den gick aldrig ner. Dessutom upplevde jag mycket flimmer när jag scrollade. Så, det var bara att ta tjuren vid hornen och göra som jag borde ha gjort från början, att skapa en userkontroll som dynamiskt hanterar antalet spelare, desutom blev det mycket snyggare också eftersom det finns fler möjligheter i WPF med expanders etc. Nedan är en bild på en WPF-userkontroll som visas i en elementHost, där WPF-userkontrollen laddar antalet spelare och skapar layouten dynamiskt i code-behind. Så en varning till alla som använder elementHost, var försiktig med att använda elementHost och tänk efter en gång extra innan du migrerar dina befintliga kontroller rakt av och om det är WPF eller Winforms som ska stå för det "dynamiska".