 |
Prototypen blev så pass lyckat att uppdragsgivaren har beslutat att utveckla den vidare till ett program för distribution. Programmets målgrupp blir konstruktörer och försäljare av hus och takstolar företrädesvis i Sverige och Danmark. Förhoppningsvis kommer programmet att användas i fler länder.
Vi vill tacka vår handledare på Consultec Mats Johansson för stöd och hjälp under tiden för examensarbetet. Vi önskar också tacka vår handledare och examinator vid Högskolan i Luleå, Jan-Erik Moström för hjälp och stöd under examensarbetets gång. Vidare vill vi tacka Urban Lindberg, Rolf Wikman och övriga på Consultec Byggprogram AB för att de ställt upp med att hjälpa och stötta oss i vårt arbete. Vi vill samtidigt passa på att tacka Arkitekter och Konstruktörer AB, Byggteknik AB och NTH (Norges Tekniska Högskola, numera NTNU Norges Tekniska Naturvetenskapliga Universitet) för konsultationer och rådfrågning. Vi vill även tacka Nils-Ivar Bovim och Roald Nielsen för tips och användande av programkod. Slutligen önskar vi tacka Byggtekniks kunder som tog sig tid att besvara den utskickade enkäten om programmet.
Vid examensarbetets start fanns det egentligen ingenting annat än målsättningen över vilka saker som prototypen borde klara. Målsättningen var att åstadkomma ett objektorienterat grafiskt gränssnitt och arbetsgång för ett program som kan rita och konstruera takplan. I ett objektorienterat gränssnitt väljer man först de objekt man vill manipulera, sedan funktionen man vill använda. Detta gör att man slipper separata funktioner för varje typ av objekt. (Se vidare under rubriken 4.3.1 Objektorienterat användargränssnitt)
Gränssnittet och arbetsgången skall passa både säljare och konstruktörer. Det vill säga det skall vara enkelt för "sällananvändare" (säljare) samtidigt som det skall vara snabbt och rationellt för professionella användare (konstruktörer).
All specificering av gränssnittet och arbetsgången skulle göras som en del i examensarbetet. För att inte göra två parallella system för dimensioneringen och konstruktionen av takstolar så skulle prototypen kunna styra TrussCon. De modifieringar som skulle behövas i TrussCon skulle inte ingå som en del i examensarbetet. Tidsåtgången var bedömd så att prototypen skulle vara klart den första mars, men detta ändrades efter en tid. Examensarbetet skulle vara klart den första mars och prototypen skulle vara så klar som det var möjligt vid den tidpunkten.
Prototypen skulle implementeras i Microsoft Visual C++. Om prototypen skulle bli så lyckad att Consultec ville gå vidare med den behövdes det riktlinjer över hur man skall skriva koden. Uppgiften att ta fram riktlinjer för program i Visual C++ ingick också i examensarbetet.
Rapporten är upplagd så att först kommer en bakgrund till arbetet där teorier och verktyg som utnyttjats för arbetet redovisas. Sedan kommer en redovisning av det egna arbetet, där vi redovisar delar av gränssnittet och arbetsgången med förklaringar och motiveringar till vissa ställningstaganden. Även ett avsnitt med vissa intressanta implementationstekniska lösningar ingår. I slutet av rapporten har vi lagt slutsatser och referenser.
Det programmeringsverkyg som vi använt är Microsoft Visual C++ 1.52. Operativsystemen som vi kört på är Microsoft Windows 3.11 och Microsoft Windows ‘95. Vi har haft tillgång till att titta på några olika CAD-program (Computer Aided Design) nämligen AutoCad och AutoSketch från Autodesk, TrussCon från Consultec, Lambda från NTH, HusPartner från DDS (Data Design System A/S). Vidare har vi haft tillgång till Microsoft Excel och Microsoft Word för att skriva rapporten och för att titta på gränssnittet.
De datorer vi har använt har varit två datorer från Hewlett Packard, en med en 80486 DX 100 MHz processor och en med en Pentium 90 MHz processor. Vi har även testat programmet på en bärbar dator från IBM för att kunna kontrollera att programmet fungerar på en dylik.
Figur 3:1 RoofCon i miniversion
Figur 3:2 Fullständig version av RoofCon
Arkivmenyn har en lista över de fyra senast använda projekten, vilket gör det möjligt att direkt komma åt de vanligaste projekten man arbetar med.
Programmet har ett antal knappar som ger "direktåtkomst" till menyalternativ. Dessa har delats upp i två verktygsrader, en för mer allmänna funktioner och en för konstruktionsinriktade funktioner.
Statusraden innehåller förutom ett fält med korta hjälptexter även koordinaterna för senaste punkt(se vidare under4.3.4 Senaste punkt) och för musmarkören. För kommandoflödet och inmatning finns det dessutom ytterligare en verktygsrad, som vi kallar inmatningsraden.
Eftersom utrymmet i huvudfönstret är begränsat har användaren full frihet att välja vilka rader som ska synas på skärmen med undantag för inmatningsraden. Den är så viktig för kommandona att den alltid skall finnas med. Bristen på skärmutrymme är också orsaken till att programmet startas upp så att det täcker hela skärmytan.
Vi har lagt ner stor möda på att få knapparna och menyerna att visa programmets status i varje läge. Aktuellt kommando syns i inmatningsfältet och genom att knappen/menyalternativet markeras. För icke valbara kommandon tonas kommandoknapparna och menyalternativen ner så att man ser vilka kommandon som för närvarande är tillgängliga. Sättet på vilket koordinaterna tolkas visas hela tiden. Vi hoppas att det leder till färre misstag från användarens sida.
Implementationen i Visual C++ har varit enkel eftersom den gör att vi kan garantera fullständig överensstämmelse mellan menyalternativen och motsvarande knappar. Är en knapp nedtryckt är menyalternativet markerat med en liten bock (
). När man inte ska kunna köra en viss funktion i ett visst läge saknar det betydelse om man försöker via knappen eller via menyn.
Koordinatknapparna representerar tre olika sätt att tolka koordinater: som absoluta, relativa eller polära. (Se figur 3:4) I ett koordiantsystem med absoluta koordinater anger man positioner i förhållande till origo. Relativa och polära koordinater anges däremot i förhållande till den senast angivna punktens position. Koordinatknapparna ger användaren en möjlighet att när som helst byta koordinatsystem. Detta för att på enklast möjliga sätt mata in en punkt på en ritning. För mer avancerade användare är det möjligt att inför varje punkt ange koordinatsystem för de inmatade koordinaterna. Om man till exempel har angivit att man arbetar med relativa koordinater och vill ange att nästa koordinat kommer att vara på polär form skriver man "p(sträcka, vinkel)". RoofCon stöder även AutoCads konvention för koordinatinmatning.
Kommandoknapparna består av fyra knappar (från vänster i figur 3:5): Avbryt, Utför, Inställningar och Backa. Dessa knappar finns tillgängliga för alla kommandon även om de används i olika hög grad i kommandona.
Avbryt avslutar kommandot om det befinner sig i sitt första steg, annars startar den om kommandot och återgår till det första steget. Trycker man på ESCAPE-tangenten händer samma sak som vid klick på Avbryt. I AutoSketch åker man däremot direkt ut ur kommandot när man trycker ESCAPE. Om man gör någonting fel och trycker ESCAPE i AutoSketch så måste man åter välja kommandot och köra det. I RoofCon däremot är det då bara att börja om med kommandot.
Utför accepterar den inmatning som har skett, dess beteende kan jämföras med ENTER-tangentens. Om man vill köra samma kommando igen behöver man inte välja om det. Kommandot ligger kvar till dess man byter kommando eller avbryter det pågående med Avbryt eller ESCAPE. Detta är också en skillnad mot AutoSketch, där måste man välja kommandot varje gång man vill köra det. Ofta är det så att man vill använda samma kommando flera gånger i följd och då är det onödigt att behöva välja det varje gång.
Inställningar ger användaren en möjlighet att ändra det aktuella objektets egenskaper. Objektets egenskaper kan till exempel vara position, riktning, storlek och karaktäristiska mått med mera. För att komma åt inställningarna kan man alternativt använda ALT-ENTER. (Se vidare under rubriken 4.2.6 Tangentbordet)
Backa gör det möjligt att ångra en inmatning och gå tillbaka ett steg i kommandot. Detta kan vara praktiskt om man till exempel klickade med musen på fel punkt under ritande av en vägg. Backa kommer man också åt via ALT-BACKSPACE.
Användaren ser på kommandoknappen om den kan användas av ett kommando. Om den för tillfället inte kan användas tonas den ner och går inte att klicka på.
Inmatningsfältet är avsett för kommunikationen mellan kommandona och användaren. Det består av tre texter: en som talar om vilket/vilka kommandon som körs, samt en som talar om vad användaren ska göra samt en med eventuell inmatning från användaren. Vi har hämtat texten om kommandot från rullgardinsmenyn. Detta för att användaren endast skall behöva lära sig ett namn på funktionen. Den första texten och de efterföljande två skiljs åt genom olika färger. Även om man inte kan se skillnad på färger är det enkelt att veta vad som är vad. Det som står på raden är antingen kommandon, uppmaningar eller inmatning från användaren. Står det två kommandon på raden skiljs de åt av ett semikolon (;). Skillnaden mellan kommandot och uppmaningen utgörs av ett mellanrum. Inmatningen från användaren är kommer alltid sist i fältet.
Vi har försökt begränsa möjlighterna för användaren att ge felaktiga eller omöjliga indata till programmet eller kommandot. Om exempelvis användaren ska ange ett avstånd tillåter inte programmet andra tecken än siffror, komma och minustecken. De gånger programmet har standardvärden för en inmatning visas de i inmatningsfältet. Om standardvärdet gäller en punkt följer det växlingar av koordinatangivelser.
Andra raden från vänster:
Väggtyper, Takplansguide, Väggmakro, Rita vägg, Fortsätt vägg, Infoga vägg, Visa takytor, Takmakro, Rita tak, Visa takstolar, Takstolsmakrot, Rita takstol, Kopiera littra, Visa måttlinjer, Måttlinje.
Knapparnas utseende har i möjligaste mån hämtats från andra program för att användaren ska känna igen så många som möjligt. Vi har tagit bilderna för Nytt, Öppna, Spara, Ångra, Gör om från Microsofts rekommendationer. Excel har bidragit med utseendet för Ok- och Avbryt-knapparna i inmatningsraden. (Se figur 3:5) AutoSketch har inspirerat knapparna för koordinatangivelserna och plockrutans beteende.
Knapparna är grupperade på verktygsraderna efter objekten som påverkas, det vill säga stödlinjekommandon är en grupp, väggkommandon en annan och så vidare.Gruppernas ordning på konstruktionsraden stämmer överens med ordningen på rullgardinsmenyerna. Ordningen på knapparna inom grupperna stämmer också överrens med ordningen i själva rullgardinsmenyerna. (Se figur 3:7, 3:8, 3:9) Ordningen i menyn och på Konstruktionsverktygsraden stämmer överrens med ordningen inom takplansguiden, det vill säga först väggar, sedan takytor och sist takstolar.
Figur 3:9 Ett exempel på ordningen i en rullgardinsmeny.
Programmet har en Visa-knapp som ger en dialog. I den kan användaren ställa in vilka objekt som ska synas på ritningen. Dessutom finns det knappar för vissa objekt som byter visningsläget direkt. För de grupper som har en Visa-knapp har vi konsekvent placerat den längst till vänster i gruppen. För att få fram knappens utseende har vi korsat symbolen för Visa-knappen, med symbolen för det aktuella objektet. Då visar vi släktskap både mellan Visa och objektet för att det skall vara enkelt att veta knappens betydelse. På samma sätt har vi gjort Rita vägg, Rita takstol och Rita tak. De har pennan gemensam, eftersom man ritar objekt med dessa funktioner. Vidare ser alla makron ut som ett ritblock med en bild av objektet, som makrot skapar. Guiden fungerar ungefär som några makron efter varandra som skapar ett hus. Följaktligen ser guiden ut som ett ritblock med många sidor i och ett färdigt hus.
För att minska antalet dialoger har vi använt flikade dialoger (property dialogs, se figur 3:10) och grupperat den information som hör ihop till samma dialog. Ett klagomål på TrussCon har varit just mängden dialoger och svårigheterna att hitta information.
En ny standard i Windows '95 är text utan fetstil i dialoger, något som vi har anammat fullt ut. Det ger mer utrymme för längre texter, dessutom ser det i vårt tycke bättre ut. För Öppna, Spara och Skriv ut har vi använt de standardiserade dialoger som följer med Microsoft Windows och som användaren känner igen från andra program. I övrigt har vi följt de rekommendationer som Microsoft har givit när det gäller exempelvis storleken på knappar och avstånd mellan olika dialogkontroller. [1]
När det gäller tangentkombinationer är vi inte särskilt konsekventa. För menyn har vi valt standardiserade kombinationer för filhanteringen (Nytt, Öppna, Spara, Skriv ut) och Ångra. Under pågående kommando finns det möjlighet att komma åt kommandoknapparna från tangentbordet. Avbryt hör naturligt ihop med ESCAPE och Ok lika naturligt ihop med ENTER. Egenskaper finns redan i Windows som ALT-ENTER. Vi har valt att fortsätta utnyttja ALT-tangenten för andra funktioner relaterade till kommandona. Backa blir då naturligt ALT-BACKSPACE, som var den förra tangentkombinationen för Ångra i Windows. Även senaste punkt passar in här. ALT-musklick ändrar senaste punkt när som helst under körning av programmet.
Menyerna i prototypen är grunda, det vill säga att det finns inga undermenyer till rullgardinsmenyerna. Hittills har vi kunnat lägga in det vi velat i menyerna utan att de blivit för långa för att visas på skärmen. Vi har fortfarande plats att lägga till fler rullgardinsmenyer vid sidan om de befintliga. Motiveringen till varför vi vill hålla menyerna grunda är att det då går snabbare att hitta bland alternativen i dem.[2]
Användaren har full frihet att välja vad som ska visas i fönstret. Med många stödlinjer, takstolar och dylikt blir det lätt svåröverskådligt. De viktigaste objekten har en egen snabbknapp för att slå av och på visningen av dem. Detta gör det enkelt att välja bort det som bara är i vägen.
Vid inmatning av en punkt visas var den hamnade genom att senaste punkt och dess kryss uppdateras. Detta är speciellt viktigt då användandet av plockrutan gör att användaren inte kan vara helt säker på var punkten hamnar.
När kommandona kan ta emot en hel serie punkter krävs att användaren ser vilka han har matat in. Det sker på två sätt; antingen ritas linjer mellan punkterna (till exempel Rita vägg, se figur 3:14) eller så markeras punkterna var för sig (till exempel Måttlinjer).
Där det har varit befogat har vi använt oss av animering i kommandona, det vill säga att i realtid rita en figur som följer markörens rörelse, för att visa användaren vad resultatet kommer att bli. I till exempel måttlinje-kommandot är det nödvändigt för att användaren ska kunna placera måttlinjen där han vill ha den. (Se figur 3:15)
För att lättare kunna markera och arbeta med vissa objekt så har de fått en symbol som underlättar hanteringen. Det kan till exempel vara takstolarna som har en liten triangel som visar vad som är framsidan på takstolen. (Se figur 3:16) Man kan välja takstolen genom att klicka på triangeln, men man kan inte sätta en måttlinje mot triangeln. Triangeln är bara en symbol och inte ett objekt.
Vi bad Arkitekter och Konstruktörer AB att de skulle visa oss hur de skulle göra en ritning, som vi hade utarbetat förutsättningarna för. (Se figur 4:1) De utsåg Magnus Hellgren att stå för visningen. Magnus använde sig av AutoCad version 12 vid visningstillfället. Under visningen såg vi sådant som var bra och sådant som var mindre bra. En sak vi direkt tog fasta på var användandet av stödlinjer, som vi ville ha både snabbt och enkelt. Vi gillade däremot inte att Magnus var tvungen att hela tiden ange om det var absoluta, relativa eller polära koordinater på siffrorna som han matade in. Han angav skillnaden med tecken så som "@" och "<". Vi bad också Magnus att titta på vårt förslag till arbetsgång. Vi fick då in vissa synpunkter, men mest av allt fick vi lära oss hur man ritar hus.
Vi har vid ett antal tillfällen haft god hjälp av Byggteknik AB för att få svar på frågor samt synpunkter på programmet. I projektets slutskede skulle Byggteknik göra ett utskick till ett urval av deras kunder. Då passade vi på att skicka med en demonstration av RoofCon och en enkät med frågor. Vi hann emellertid inte få in så många svar innan projektet skulle vara avslutat. De enkätsvar vi fick in gav oss några värdefulla synpunkter på programmet. En del av enkäten bestod i att de svarande fick prioritera programmets uppförande och utdatan från programmet. Vi fick in en hel del önskemål om ytterligare former på huskroppar i makrona, vissa kanske mindre realistiska än andra. Vi fick också önskemål om att kunna koppla ihop RoofCon med många andra program på marknaden, men vi får se hur det blir med den saken. Tillsammans med vissa enkätsvar fick vi in ritningar på hus som de svarande hoppades att programmet skulle klara av. Delar av resultaten från enkäten finns redovisade i diagramform i bilaga 2.
För att få in ytterligare idéer och tips på hur vi skulle göra funktioner och stöd till användaren så har spionaget på andra program varit tämligen omfattande. Vi har haft möjlighet att titta på AutoCad, AutoSketch, HusPartner, Excel, TrussCon, Visual C++ och Word med flera. De program som vi tittat mest på har varit AutoSketch och TrussCon. I och med att Consultec gjort TrussCon och att det kommer att bli TrussCon som skall användas för dimensioneringen av takstolarna så har vi varit tvungna att ta hänsyn till TrussCons gränssnitt.
I figur 4:3, nedan, visas dialogen för att definiera en väggtyp. Bilden i mitten föreställer en vägg där man skall ange måtten för väggen. Bilden kan te sig lite svår att förstå för den oinvigde, men ingen av konstruktörerna som vi visat bilden för har tvekat om vad den föreställer. Att beskriva den figuren i ord kräver en hel del utrymme för förklaringar. Här vann vi en hel del på att använda bilden. Vi har använt bilder på väggen vid flera tillfällen bland annat för att användaren skall tala om vad som han/hon använder som referenslinje. Dessa bilder liknar bilden i figur 4:3. Vi använder oss av bilder som liknar varandra för att användaren lättare skall känna igen sig och förstå vad vi menar. Jämför bilden i figur 4:3 med bilden i figur 4:4.
Figur 4:4 Bild för referenslinje och utbredningsriktning
Vi har däremot tre funktioner som verkar direkt på objekt. De är: Fortsätt vägg, Infoga vägg och Kopiera littra. När vi skapade dessa var det enkelheten att komma åt deras funktionaliteter och det faktum att vi snabbt ville visa tanken bakom dem som gjorde att de blev särskilda funktioner. Den objektorienterade lösningen vore att alla objekt fick Infoga och Kopiera funktionalitet. Fortsätt funktionaliteten är egentligen bara ett specialfall av Infoga, varför man skulle klara sig bra utan den. Infoga vägg och Kopiera littra som egna funktioner kommer snart att försvinna. Infoga och Kopiera funktionerna kommer att implementeras för alla objekt, då kommer gränssnittet i RoofCon åter att vara helt objektorienterat.
Stödlinjekommandona har vi gjort lättillgängliga för att det skall vara enkelt och snabbt att ta fram stödlinjer. I dessa kommandon har vi lagt en del extra finesser. Dessa hade vi kunnat ha som skilda funktioner, men det hade dragit ned snabbheten vid användandet av kommandona. Användarna hade tvingats att byta kommandon ofta, det hade blivit många funktioner med liten skillnad att hålla reda på. Priset som vi får betala är att de som använder programmet sällan inte kommer att ha nytta av den extra funktionaliteten, eftersom de kommer att glömma finesserna mellan användningarna av programmet. Dessa användare kommer nästan uteslutande att köra funktionerna såsom kommandoraden uppmanar dem. För en beskrivning av kommandona se vidare under rubriken 4.3.7 Stödlinjer.
Ett enkelklick på musens högra knapp medför att en snabbmeny visar sig. Användaren är inte tvungen att hålla musen helt stilla under klicket. Vi har lite säkerhetsmarginal för att det skall vara möjligt att få fram snabbmenyn och inte alltid zooma in. Är man i närheten av ett objekt och klickar med högra musknappen får man upp en snabbmeny med funktioner som man kan använda på just det objektet. Klickar man med musen utan att vara nära något objekt så visas en snabbmeny med programinställningar.
Det vanligaste i Windows-världen är att användarna har en mus med två knappar. För de användare som har en mus med tre knappar tolkar RoofCon den mittersta på samma sätt som om användaren tryckte på ENTER.
I en objektorienterad variant av funktionen Flytta väljer man först vilka objekt man vill flytta. Sedan väljer man funktionen Flytta och då kan man flytta de valda objekten. I den icke objektorienterade varianten väljer man funktionen Flytta måttlinje och då kan man bara flytta måttlinjer. Följden blir att man har en massa funktioner som egentligen utför samma sak men på olika objekt. I TrussCon finns bland annat Flytta knutpunkt, Flytta mellanbjälke, Flytta måttlinje och så vidare, det vill säga en funktion per objekt.
Fördelen med ett objektorienterat gränssnitt blir att användaren får ett överskådligt antal funktioner att använda och hålla isär. Lär sig användaren att flytta en typ av objekt så kan användaren flytta alla objekt.
I RoofCon väljer man de objekt som man vill förändra och därefter anger man hur man vill förändra dem. Är något eller några av de markerade objekten av avvikande typ och funktionen inte fungerar på samma sätt för alla de ingående objekten får användaren välja på vilken typ av objekt han/hon vill köra funktionen. Då funktionen avslutats försvinner markeringen på de valda objekten. Det verkar som man oftast bara vill manipulera en typ av objekt åt gången och då känns det som ett extra moment att vara tvungen att avmarkera en del objekt innan man kan markera nya för nästa funktion. De funktioner som fungerar på det här viset är samtliga redigeringsfunktioner, bland andra Flytta och Ta bort.
Det kan till exempel vara så att man först under ritandet av väggen kan sätta ut vissa stödlinjer, så att man kommer sig runt hela huset med ritandet. Under tiden som man kör ett baskommando och håller på med ett tilläggskommando kan man inte välja att köra ett nytt baskommando. Man kan däremot byta tilläggskommando genom att välja ett nytt tilläggskommando. Vill man åter köra det pågående baskommandot trycker man på ESCAPE eller klickar på Avbryt-knappen i inmatningsraden.
Ett kommando är antingen ett baskommando eller ett tilläggskommando. Stödlinjekommandona är mycket bra exempel på tilläggskommandon därför att de gör enkla uppgifter som kan vara till hjälp för många kommandon. Då man väljer mellan de olika stödlinjekommandona byts de bara ut, medan baskommandona alltjämt ligger kvar.
I funktionen stödlinje i punkt, har vi gjort så att man kan mata in koordinater och vinkeln på linjen. Man kan också klicka in punkten och sedan trycka ENTER eller dubbelklicka med musen för att bekräfta senast angivna vinkel. Ytterligare ett alternativ är att klicka på två punkter för att få en linje mellan dem.
Funktionen Stödlinje parallell kan också användas på flera olika sätt. Första klicket är för att välja vilken linje som den skall vara parallell mot, en pil indikerar riktningen och sedan skall man ange avståndet. Trycker man två gånger på ENTER bekräftar man valet av sida, annars anmodas man att välja den sida om linjen som den nya linjen skall komma. Valet av sida gör man genom att klicka på öskad sida om linjen. Om man sedan önskar ha flera linjer med samma avstånd dubbelklickar man på rätt sida om linjen som man vill att stödlinjen skall vara parallell mot.
I väggmakrot får användaren först välja vilken form huskroppen skall ha, och sedan ange några olika mått som är karaktäristiska för just den huskroppen. Användaren får därefter ange rotationsvinkeln för huskroppen samt dess position. Vi har definierat fyra olika former på huskroppar, men av enkätsvaren att döma finns det önskemål om betydligt fler. Användaren kan använda dessa makron som en bra start även om makrots form inte är helt perfekt för användarens behov. Det är relativt enkelt att sedan modifiera huskroppen som makrot genererade så att det passar användarens behov.
I makrot för takytor, liksom i ovanstående makro, får användaren först välja formen på huskroppen och takytornas form. Därefter ange vissa karaktäristiska mått. Sedan utför makrot ritandet av själva takytorna och användaren anger en referenspunkt för höjden (det vill säga en punkt i vilken man känner höjden) och höjden i referenspunkten.
Takstolsmakrot skapar takstolar till en given takyta. I det här makrot får användaren först ange vilken takyta som det skall placeras takstolar på. Sedan får användaren välja vilken takstolslösning som han/hon vill ha samt ange några karaktäristiska mått för den lösningen.
I AutoSketch är måttsättningen associerad med en punkt på ritningen. Det innebär att flyttar man alla objekt inom ett visst område och måttlinjen inte är inom området så stannar den kvar och måttet ändras inte.
TrussCon har liksom RoofCon associativ måttsättning. I TrussCon har man löst det på ett annat sätt. Man får där bara välja mellan ett antal olika punkter som man kan mäta mellan och dessa punkter har programmerarna definierat. Programmerarna i TrussCon har ständigt problem med att användare vill mäta mellan fler och fler punkter som de då måste lägga in i koden.
I framtiden kommer fler val i de befintliga makrona. En funktion för att rita linjer som inte är objekt i vanlig mening står på önskelistan över saker att implementera. Vi vill också se en möjlighet att sätta ut helt fria texter på ritningen. Med de två sistnämnda funktionerna slipper användarna några av de begränsningar som trots allt kommer att finnas i RoofCon. Vidare måste RoofCon att kopplas ihop med till TrussCon för att dimensioneringen av takstolarna skall ske på ett korrekt sätt. RoofCon kommer att kunna presentera en samkörd kaplista och en samkörd kalkyl för hela takplanet. I framtiden kommer RoofCon också att kunna plocka in hela eller delar av ritningar från andra program genom en DXF-koppling.(Drawing Interchange Format). RoofCon kan redan nu exportera ritningar på DXF-format så att man kan ta in RoofCon-ritningar i exempelvis AutoCad för vidare behandling.
2 Löwgren J,1993 Human-computer interaction, Studentlitteratur, ISBN 91-44-39651-1
3 Wickens C D.,1992 Engineering psychology and human performance, HarperCollins Publishers, ISBN 0-673-46161-0, 40-58
4 Shinobu Ishihara,1980,Ishiharas tests for Colour-blindness, Kanehara & co. ltd. Tokyo
Andreas Nilsson
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.