Jeg har lige siddet med noget kode, hvor jeg fandt ud af at IF...THEN statements ikke altid er den ”rigtigste” løsning, selv om det vil virke hvis man bruger det.

Forstil dig eksempelvis at du har en toolbar (værktøjs-linje) hvor der skal ske noget forskelligt, alt efter hvilken knap i toolbar’en User klikker på.

Her havde jeg først lavet følgende kode, hvor jeg lige har erstattet alt det der sker når User klikker med en simpel MsgBox (for overblikkets skyld), men ellers er koden den samme:



Først kigger vi altså efter, om User klikker på knappen buttonNewNote, og gør han ikke det ser vi om han så klikker på den næste, og gør han ikke det om han så klikker på den næste ... og sådan kunne vi egentlig fortsætte.

Dette er valid kode, og den virker fint nok. Men forstil dig at der sker en masse kompliceret inde i de enkelte IF og ELSEIF statements. Så skal vi hele rækken (og dermed al koden) igennem, før vi får et ”hit” og kan udføre den korrekte kode. Det kan sløve ens app helt enormt, hvis der sker meget mellem de enkelte IF og ELSEIF statements.

Her kommer CASE til vores redning. Den kigger nemlig på, om en betingelse af mange er opfyldt, og ”gør kun noget” hvis det gør sig gældende.

Derfor er denne kode meget mere ”korrekt” i og med den sparer programmet for hele tiden at checke de enkelte kriterier for, om de er opfyldt:



Som en tommelfinger-regel kan man sige, at i de tilfælde hvor du ikke kan lave en ren ELSE til sidst, men slutter af med en ELSEIF, så bør du nok se op om CASE kan bruges i stedet!

Læs selv mere om CASE ved at søge på ”select case” uden anførselstegn i Language Reference. LR finder du ved at klikke på dette ikon i REALbasic’s toolbar:

Når man bliver så god, at man kan begynde at skrive sin egen kode, vil man opleve at man ind i mellem gerne vil tilbage til et tidligere punkt i sin kode. Eller måske vil man gerne prøve noget kode af, men have mulighed for at komme tilbage til hvor man er nu.

Eller der kan være tusind andre grunde til, at det kan være en rigtig god idé at have flere versioner af sit projekt liggende. Har man det, har man nemlig samtidig flere backups til rådighed, hvis noget skulle gå galt.

Der findes mange måder at sikre, at man har disse ”kopier tilbage i tiden”, på. Men som med alt andet har jeg fundet ud af, at den simpleste metode også er den bedste. Derfor kommer her et lille tip til, hvordan du kan sikre dig at du har gode backups tilbage i tiden, samt kan se hvor og hvornår du har lavet store og små ændringer i din kode og dit projekt.

LAV NOTER!
Start med at lære dig selv, at bruge REALbasics indbyggede note-funktion. I et hvert kode-vindue finder du en knap der hedder Add Note, og klikker du på den laves en ny note-kategori samt en tom note. Det at der laves en kategori til noter betyder, at man kan lave flere noter i samme projekt og i hvert kode-vindue.

Jeg vil anbefale at man holder alle sine noter inde i App objektet (Klik på tabben Projekt og dobbeltklik på App og derefter klik på Add Note) da man så altid ved hvor man har sine oplysninger, og nemt kan finde dem igen.

Her ses et eksempel på de noter jeg har, i et af mine igangværende projekter:

Bugs bruger jeg til at notere de fejl og mangler jeg finder, mens jeg laver programmet samt i test-fasen, og som skal laves inden programmet kan kaldes færdigt.

Credits bruger jeg til at notere de personer eller websites, fra hvem jeg har brugt kode, tips eller idéer til min app. Det er som oftest ting jeg skal huske at have med i min ”About Box” som kommer frem, når brugeren vælger ”Om Program-navn...” fra menuerne i den færdige app.

I Egne spørgsmål på forummerne noterer jeg links og svar, til de spørgsmål jeg måtte have stillet på REALbasic Forummerne i forbindelse med min app. På den måde kan jeg nemt finde dem igen, også når jeg senere skal bruge samme funktion/svar i et andet projekt, men ikke kan huske præcist hvad svaret var.

Features & Ønsker bruger jeg til at notere de ting jeg falder over under udviklingen, som jeg gerne vil have med i næste version af min app. Eller ting der skal med i denne version hvis jeg får tid eller kan finde ud af det (det sidste som regel :) Det er ofte såkaldte ”Nice to have’s” altså ting der kunne være fedt at lave, men som ikke er essentielle for brugen af min app. Eller ting jeg gerne vil lave, når jeg bliver dygtig nok!

Interne versioner: Her kommer det, som denne blog-post egentlig handler om, nemlig info om de forskellige udgaver af min app, jeg har gemt gennem hele kode-forløbet. Mere om det herunder.

Tips & Links er til ting, der ikke lige passer andre steder, samt smarte ting jeg falder over på websites eller forummerne, som jeg gerne vil kigge nærmere på.

Og endelig To-Do’s hvor jeg noterer ting der skal laves i denne version, men som ikke er egentlige fejl eller bugs. Eksempelvis features der hele tiden har været planen at lave, men som jeg ikke har nået endnu.

LAV INTERNE VERSIONER!
Så kommer vi til det, at gemme interne versioner af sit projekt mens man koder. Det er ikke andet, end at man med jævne mellemrum vælger File > Save As... i menuerne, og dermed gemmer som et nyt fil-navn i stedet for bare at gemme oven i hele tiden. Dermed får man hele tiden flere ældre udgaver, som man kan vende tilbage til om nødvendigt.

Her er det vigtigt at finde en måde at navngive disse versioner på, som gør man kan finde rundt i det senere hen. Jeg gør det på følgende måde:

FILNAVN + VERSION + DATO hvilket kan se ud således: Research_001-20081002.rbp

På denne måde har man alle de informationer i fil-navnet, som man skal bruge i sin Interne versioner note i selve projekt-filen. Jeg flytter så gerne de lidt ældre udgaver af mit projekt, ned i en separat mappe så de er af vejen ind til jeg skal bruge dem, som vist her:



Det er vigtigt at forstå, at man ikke behøver ”gemme som” hele tiden, blot man gør det med jævne mellemrum, eksempelvis hver halve time, samt hver gang man går i gang med noget nyt eller et større re-design af sit projekt.

I mine noter skriver jeg så lidt om hver version. Ikke ret meget, for det må ikke tage ret lang tid at gøre dette, ellers får man det ikke gjort. Men nok til at jeg kan finde tilbage til en version, eksempelvis før jeg prøvede noget nyt jeg ikke kendte så meget til, eller før jeg re-designede et vindue eller lign.

Her er hvordan en Interne versioner note ser ud, i et projekt jeg er i gang med lige for tiden (klik for at se stor udgave):

Som det ses, har jeg alle informationer samlet, og kan nemt linke disse til fil-navnet så jeg altid kan finde tilbage til en ældre version, hvor noget måske virkede som ikke længere virker, eller på andre måder kan gøre brug af de ældre versioner af projektet.

Det er vigtigt at man gemmer sine projekter ofte, Æble/Ctrl-S skal sidde i fingrene og bruges hele tiden. Samtidig er det vigtigt, at man ind i mellem gemmer som, og dermed får en kopi af sit projekt så man kan finde tilbage og genbruge kode en anden god gang.

Med denne vejledning, er det nemt og hurtigt at klare denne opgave, og det er ikke mere kompliceret end nødvendigt. Så kan man bruge sin tid på at lære samt kode, ikke på at holde styr på ting som systemet lige så godt kan hjælpe en med :)

Klik her, for at hente kildekoden til Duck The Dock eller klik her for at hente det færdige program, som du kan bruge til at ændre din Leopard Dock fra normal til mere simpelt udseende.

Det programmet gør, er at lave en wrapper omkring nogle Terminal-kommandoer man kan bruge, til at indstille Mac OS X’s indbyggede Defaults-system.

Normalt kører man kommandoer som nedenstående i Terminal.app under OS X, og kan derved ændre måden systemet opfører sig på. Det er blandt andet i Defaults-systemet at tingene gemmes, når vi laver ændringer i Systemindstillinger eller i Apples egne programmer.

I dette Defaults-system findes også nogle skjulte indstillinger, som vi kan ændre, blandt andet udseendet på vores Dock. Den kommando knappen Lav simpel Dock kører, er følgende:

defaults write com.apple.dock no-glass -bool YES

Og koden til knappen i REALbasic, er følgende:


// Først laver vi en ny Shell til at køre vores Defaults kommando.
Dim s As New Shell


//Så checker vi om User kører Mac OS X og viser en besked hvis ikke.
// Gør han det, kører vi Defaults kommandoen.

If chkRestartDock.Enabled = True then
s.execute "defaults write com.apple.dock no-glass -bool YES"
s.Execute "killall Dock"
End If


// Sker der en fejl, håndterer vi den med en MsgBox og ellers viser vi en
// status-besked. Dette kan vi senere ændre til at gøre programmet mere avanceret.

If s.ErrorCode = 0 then
cvsStatus1.Graphics.DrawPicture (actionsbutton_ok, 0, 0)
cvsStatus2.Graphics.ClearRect (0, 0, cvsStatus2.Width, cvsStatus2.Height)
else
MsgBox "Der er sket en fejl: Kunne ikke gennemføre ændringen - fejlkode: "+ Str(s.errorCode)
end if

Vil du bare ændre din Dock, uden at rode med REALbasic, bruger du bare linket øverst til at hente det færdige program - have fun :)

PS: Jeg arbejder på at få koden vist med korrekt syntax high-lighting!