Hej! Snyggare lösning till CF är att använda TabControl. Ofta bättre än att använda flera fönster. Förstår inte riktigt vad du menar..."Man gör preogram som alla andra gör det."? Ted! Du missar hela poängen med att koda!!! Användarvänligt är ALLT!!! Om inte ditt program är användarvänligt, så kan du skriva det så snyggt du vill - men ingen använder det och det spelar alltså ganska liten roll hur snygg koden är... Eh, nu börjar jag faktiskt undra ifall folk inte kan läsa... Vilken trevlig stämning. Hej Andrec, Alternativet till TabControl är ju Panel. Men då får du sämre översikt i design-läge (i Visual Studio). En idé är att ärva från tabcontrol, sedan "plockar man bort" tabbarna på något sätt (har inte tittat på hur det är implementerat, men det borde gå på något sätt) Du kan glatt köra på med dina paneler , tabflikar är vanliga paneler som hanteras av en tabkontroll så du får precis samma prestanda om du hanterar panelerna själv. Jo, verkar inte hitta andra sätt. nej det är inte konstigt alls.. Annars borde det fungera med en textbox till det här + fånga lite messages för att få den trevligt inaktiv utan gråskuggad text? Hej och tack för svar! Jag måste fortsätta på denna tråden då frågan om effektivt programmering är ännu mer aktuell nu. För länge sen, satt jag i ett familjealmanacksprojekt i skolan som hade samma problem. Eftersom jag sparar allt har jag koden kvar och jag testade och jag uppfattade själva GUIändringen som rätt snabba. Nu kanske jag inte är den bästa av programmerare och rätt oerfaren och så men några rader kod att läsa igenom kan väl inte skada. Det jag tror skiljer har jag försökt markera med stjärnor. Grunden till denna koden hittade vi i de "dolda" raderna där .Net skapar GUIt. Jag skapar flera olika formulär som jag sedan instancierar och visar efter behov istället för att ha alla ui-kontroller liggandes som hidden. Dessa formulär samlar jag sedan under en basapplikation som agerar delat minne (kommunikator) för alla dessa formulär, enkelt och smidigt och framför allt minnes-snålt. Tack för svaren!C# GUI grafik: effektiv programmering?
Vet inte exakt i vilket forum denna tråden ska ligga men jag tar den jag tror =)
Vad jag undrar är ifall någon har bra resurser att läsa gällande hur man gör effektiv, snabb och generellt sett "bra" grafisk programmering i C#, C# CF?
Har utvecklat en applikation till en Pocket PC med CF 1.1 och den fungerar, men jag har en massa paneler som jag tar kör .Show() och .Hide() på. Jag har letat lite och funderar på hur snyggt det är med en massa paneler som skapas och sedan göms o tas fram när det du krävs.
Är det rätt sätt? Finns det snyggare och bättre sätt att skriva GUI? Vad är det man bör tänka på gällade GUI-programmering sett till prestanda?
Tack!Sv: C# GUI grafik: effektiv programmering?
Om man inte skulle vilja se tabbarna av någon anledning kan man göra kontrollen större än fönstret och sen koppla knappar och sånt till tabflikarna.
Annars är det väl sunt förnuft. Man gör program som alla andra gör det. Den typen av program är nog de flesta användare vana vid.
Du vet väl att dina användare spenderar det mesta av sin tid med att använda andra program än ditt :)
/andrecSv:C# GUI grafik: effektiv programmering?
"Du vet väl att dina användare spenderar det mesta av sin tid med att använda andra program än ditt "?
Jag pratar inte om användarvänlighet här, utan vad som är effektiv och snygg kod =)Sv: C# GUI grafik: effektiv programmering?
/mickeSv:C# GUI grafik: effektiv programmering?
Jag pratar INTE om användarvänlighet - det är en HELT annan diskussion och har inget med min fråga att göra. Varför Micke o andrec besvarar eller diskuterar en fråga som jag inte ens ställt förstår jag inte alls.
Alltså - användarvändlighet är ju klart att det ska vara bra. Men svara mig: vad har det med min ursprungliga fråga att göra? Det finns inte mycket som är mer irriterande än när man ställer en fråga och några wiseguys bestämmer sig för att "svara" på något helt annat som dessutom är väldigt irrelevant i sammanhanget.
Jag undrar hur man KODMÄSSIGT eller programmeringsmässigt skriver bra, effektiv och snygg kod för hantering av GUI. Det har inget med användarnvändlighet att göra, utan har med prestanda och bra skriven kod.
Så ifall någon har lite bra tips och ideér gällande detta (och alltså inte användarvänlighet eller kanske en filosofisk diskussion om trädet i skogen som faller som ingen hör - lät det något då?) tar jag tacksamt emot dessa!
MVHSv: C# GUI grafik: effektiv programmering?
Jag svarade ju på det. Du ska använda TabControl istället för fönster. Då slipper alla Show och Hide.
/andrecSv:C# GUI grafik: effektiv programmering?
jo det är sant. Den första delen av ditt svar gav ju def. ett tips, mina kommentarer riktade sig till den andra delen du skrev samt Mickes inlägg.
Jag är tacksam för tipset, men jag tycker nog inte det är en speciellt "ren" eller stilig lösning (rent programmeringstekniskt). Känns fel att behöva fulhacka genom att lägga den utanför det synliga området...
Men tack ändå! =)Sv: C# GUI grafik: effektiv programmering?
Ett annat alternativ är att göra någon egen control.
/andrecSv:C# GUI grafik: effektiv programmering?
Sv: C# GUI grafik: effektiv programmering?
dessutom kan du i motsats till vad dom andra säger få bättre översikt med paneler eftersom du kan bredda ditt fönster i designläge o lägga panelerna bredvid varandra så du ser alla samtidigt i designern.
(men du måste ju självklart positionera om dessa i runtime sedan)
//RogerSv:C# GUI grafik: effektiv programmering?
Men det är väldigt långsamt, verkar det som.
Jag har en Panel som innehåller en hel del rader vanlig text. Det är alltså en label med en hel del rader text (ca 360 rader) och med en scroll på sidan.
Detta är extremt långsamt att scrolla och att ta fram (show) Panel. Ju längre "ner" i listan (över textraderna i panelen) desto snabbare går det. Alltså, de rader som skrevs först går snabbare, medan de rader som är sist inskrivna (överst i panelen) går långsammare - mkt långsammare.
Varför beter det sig så? Det verkar ju oerhört konstigt tycker man. Sv: C# GUI grafik: effektiv programmering?
din label ritas internt med gdi+ med DrawString
drawstring slutar rita när den känner att den kommer utanför de bounderies som är synliga.
MEN
när du scrollar till slutet , så måste den börja rita från början fram till de sista rader du ser..
säg att du på skärmen ser rad 260-300 , så måste den iaf rita rad 1-300 för att rad 260-300 ska hamna på rätt ställe.
en bättre lösning vore (om du kan leva utan wordwrap) att splitta din text på enterlsag och lägga alla rader i en arraylist
och göra en egen customcontrol med en scrollbar och en rityta där du börjar rita från samma radnr som scrollbarens värde tills du ritat så många rader att du hamnar utanför skärmen..
//RogerSv:C# GUI grafik: effektiv programmering?
Sv:C# GUI grafik: effektiv programmering?
Intressant om GDI och DrawString. Har dålig koll på hur det fungerar internt men det förklarar ju en del. Men tycker fortfarande att det är konstigt att den är såpass långsam att den inte klarar ett par rader text! Usch, synd som fan.
Generellt sett är det väldigt omständigt och kladdigt att programmera GUI:s/grafiskt i C# också. JAVA är ännu värre antar jag (för att inte prata om C/C++) men hade hoppats på betydligt snabbare och enklare i och med .NET.
Ska testa lite med båda förslag jag fått, se hur det löser sig bäst.
Dock undrar jag hur man lär sig att skriva bra, effektiv och snabb kod. Verkar ju vara väääldigt svårt att göra det... =(Sv: C# GUI grafik: effektiv programmering?
Vi har fortsatt på vårt projekt och det finns en hel del som är väääldigt långsamt i applikationen (som är för Compact Framework 1.1). Det är så ofattbart att sådana små mängder information som vi rör oss med tar så lång tid att behandla, uppdatera grafiskt etc...
Jag har sökt som en galning på Google efter olika tips, ideér, artiklar etc som rör just hur man för snabb och effektiv kodning i C# men hittar ingenting.
Problemet är, t ex, att när man klickar på en viss panel körs en metod som uppdaterar "statusen" för den panelen. Egentligen uppdateras ett object (en Int sätts till ett annat värde) och sedan ritas det grafiska om. Det är, i dagsläget, en for-loop som hittar ett object (jag vet att det är ineffektivt och vi har planer på att byta men det rör sig om väldigt få iterationer, kanske 5-6 st), ändrar värdet och sedan säger åt en draw()-metod att "rita om".
Den draw-metoden går igenom en Array/ArrayList, skapar lite grafiska objekt (panels i huvudsak) och ritar om det man ser. Och detta hackar, laggar och segar lite som det vill känns det som.
Jag fattar verkligen ingenting. 400Mhz processor i en applikation som inte alls är belastad eller stor ska inte bete sig såhär tycker man.
Eller vad har man missat? Svårt att säga om man inte ser koden kanske, men varför läser jag inget om dessa problem annanstans? Hur dålig programmerar kan man vara egentligen? Det borde ju finnas en övre gräns på hur dålig koden kan vara... och så dum tror jag inte jag är (eller de andra jag jobbar med).
Någon som har några tankar?Sv:C# GUI grafik: effektiv programmering?
PS: Min lärare hatade när man skrev på svenska i koden och framför allt när man blandar så koden är ju inte så vacker men man kan ju inte få allt...
//Lisa
/********** skapa Labels och Buttons **********************/
public void skapaLabelsButtons(int v)
{
//Här ska första knappen placeras dvs. vilken veckodag den ska börja på * locationX
string veckodag = användare[a].aÅr.åretsDagar[användare[a].aÅr.åretsMånader[v].startDag].veckodag;
int dag = 1;
int vdag = (användare[a].aÅr.veckodagTillVdg(veckodag));
int vecka = 1;
//initiera innehåll på knapp och label
int plats = användare[a].aÅr.åretsMånader[v].startDag;
string labelText = dag.ToString()+ "/" + v.ToString() + användare[a].aÅr.åretsDagar[plats].veckodag;
string buttonText = användare[a].aÅr.åretsDagar[plats].anteckning;
//location och storlek på knappar och labels
int kB = 125;
int kH = 60;
int lH = 15;
int vB = 50;
int vH = 25;
int locX = (vdag-1)*127;
int locY = 4;
int locVx = 4;
int flagga = 0;
//månads while
while(flagga==0)
{
//vecko while
while(vdag<=7 && flagga == 0)
{
//för rätt text på knapp och label
plats = (användare[a].aÅr.åretsMånader[v].startDag)-1+dag;
labelText = dag.ToString()+ "/" + v.ToString()+" "+ användare[a].aÅr.åretsDagar[plats].veckodag;
buttonText = användare[a].aÅr.åretsDagar[plats].anteckning;
/************ det är här jag tror det skiljer ************************/
//knappar och labels
buttons[dag] = new System.Windows.Forms.Button();
labels[dag] = new System.Windows.Forms.Label();
buttons[dag].Location = new System.Drawing.Point(locX,locY+15);
labels[dag].Location = new System.Drawing.Point(locX,locY);
buttons[dag].Size = new System.Drawing.Size(kB,kH);
labels[dag].Size = new System.Drawing.Size(kB,lH);
buttons[dag].BackColor = System.Drawing.Color.MidnightBlue;
buttons[dag].ForeColor = System.Drawing.Color.OrangeRed;
labels[dag].BackColor = System.Drawing.Color.Crimson;
labels[dag].BorderStyle = System.Windows.Forms.BorderStyle.None;
buttons[dag].Text = buttonText;
labels[dag].Text = labelText;
buttons[dag].Name = plats.ToString();
buttons[dag].Click+=new EventHandler(button_Click);
grbxDatum.Controls.Add(buttons[dag]);
grbxDatum.Controls.Add(labels[dag]);
//så räknar vi upp allt vi behöver
locX += 127;
vdag++;
if(dag<=användare[a].aÅr.åretsMånader[v].månadslängd-1)
dag++;
else
flagga = 1;
}//veckowhile
vdag=1;
locX=4;
//veckolabel
veckoLabel[vecka] = new System.Windows.Forms.Label();
veckoLabel[vecka].Location = new System.Drawing.Point(locVx,locY);
veckoLabel[vecka].Size = new System.Drawing.Size(vB,vH);
veckoLabel[vecka].BackColor = System.Drawing.Color.Crimson;
veckoLabel[vecka].BorderStyle = System.Windows.Forms.BorderStyle.None;
veckoLabel[vecka].Text = "vecka\n" + användare[a].aÅr.åretsDagar[plats].veckoNummer.ToString();
grbxVecka.Controls.Add(veckoLabel[vecka]);
locY += 76;
vecka ++;
}//månadsWhile
}//skapaLabelsButtons
Oj så mycket onödig kod det blev och indenteringen är gräslig men jag har satt några stjärnor där det verkar som om vi har gjort olika.Sv: C# GUI grafik: effektiv programmering?
Sv:C# GUI grafik: effektiv programmering?
Lisa: jag har svårt att avgöra vilka skillnader det var. Upptäckte ni att "aha, det här segar ner som fan"?
Jag har försökt att göra lite tester i min kod, genom att mäta tider som olika metoder tar. Jag började först med hela metoder och sedan gick jag in i dessa och mätte vissa bitar ur dem för att försöka avgöra var det långsamma låg. Dessvärre kom jag inte fram till speciellt mycket i mina efterforskningar.
Jag har en draw()-metod som jag kallar när jag fått in ett nytt jobb. För varje sådant nytt jobb lägger jag in det objektet i en ArrayList och kör sedan min draw()-metod. Den ser ut som följer:
<code>
public void draw()
{
Invoke(new EventHandler(draw));
}
</code>
Mkt enkel med andra ord. Vad jag funderar just nu på är Invoke-metoden där. Det står på MSDN att den är blockerande och att den kallande tråden låser tills dessa att den "returns". Kan det möjligen sega ner?
Jag har en klass som heter "Panel_JobList" där draw()-metoden ligger. I den "riktiga" draw-metoden (den som Invokas) ligger en massa kod som skapar nya Panels (Panel_Job) baserat på de objekt som finns i min ArrayList.
MEN
i varje Panel_Job finns det sådana här metoder:
<code>
protected override void OnClick(EventArgs e)
{
stopAlert();
panel_jobList.zoomInOn(sicJobUnit.SICID);
base.OnClick (e);
}
</code>
Dessa "onClick" exekveras alltså när man klickar på panelen (på Panel_Job). Som man kan se kör denna Panel_Job en metod i min Panel_JobList.
Metoden zoomInOn(...) kör i sin tur draw() som beskrivet ovan.
Om nu MSDN säger att det är en blockerande metod och att tråden låses tills Invoke-metoden (min andra draw) returnerar - vad innebär det? Kan det bli någon slags rundgång och att den låser sig själv på något sätt?
Jag vet att det blir lite kladdigt nu kanske, men jag ska försöka förtydliga igen. Alltså:
- Panel_JobList har en metod draw() som kör en Invoke på en annan metod som uppdaterar GUI.
- Panel_JobList skapar Panel_Job i den Invokade metoden, alltså varje gång man kör draw() typ.
- Panel_JobList har en metod zoomInOn(...) som efter lite meck kör metoden draw() enligt ovan.
- Panel_Job har en OnClick-metod som kör Panel_JobList.zoomInOn(...)
Är det någon som kan detektera något fel? Tänker jag rätt? Invoke?
<code>
public void zoomInOn(uint SICID)
{
SICJobUnit clickedJob = findJob(SICID);
if(clickedJob.status == Panel_JobList.UNACKED)
{
clickedJob.status = Panel_JobList.ACKED;
((Panel_Top)ClassReferencer.getObject("Panel_Top")).checkJobMessage();
sendJobAckMessage(clickedJob.SAMID, clickedJob.SICID);
xmlParser.updateData(clickedJob);
}
else
{
if (zoomedInOn > 0)
zoomedInOn = 0;
else
zoomedInOn = SICID;
}
draw();
}
</code>