jeg har en program (som egentlig er et lille spil). Jeg vil gerne have at der først åbnes en slags menu (Start form) og så ved et klik af en knap skal der åbnes spillet (Spil form).
Jeg ved hvordan jeg kan gøre det sådan at der åbnes flere forms, men jeg vil kun have en enkelt form åben. Da begge forms har samme størrelse tænkte at man måske kunne have en slags "mainform" hvor jeg "loader" andre forms ind i så der til enhver tid kun er en enkelt form åben. Er det muligt?, hvis ja så hvordan?
Du kan lave en MainForm som du nævner og så starte med at loade menuen ind via Controls.Add( new MinSejeMenu() ). Når man så klikker på noget i menuen kan du fjerne DinSejeMenu fra din MainForm's control collections, og tilføje en ny.
Du skal lave en main form, proppe din menu i et Panel og add'e det Panel til Form.Controls. Når du vil skifte indhold kan du fjerne dit Panel fra Controls og add'e et nyt...
Det kommer sådan lidt an på hvordan du helt vil have det til af fungere i baggrunden...
Men en måde er at lave en "Controler" klasse, hvori du styrer det fra... Den nemme måde er så her fra at have en reference til begge forme, og ved tryk på din knap i MenuForm kalde en metode "SwitchToGame()" eller lign... og omvendt kan du jo gøre det samme fra GameForm med "SwitchToMenu()"... det er lidt dirty som det er beskrevet her... men bygger på et godt princip...
I dine metode kan du så enten bare gøre dine forms skiftevis Synlige/Usynlige...
Eller hvis du skal have lavet en ny, jamen så gør du jo så det... (Kunne godt være du har lagt noget af dit GameInitialize i din GameForms Constructor, jamen så er det så at lave en ny hver gang...
Din klasse bør nok desuden være en SingleTon til det her...
ok det her er lige skrevet i Notepad, så bær lige over med fejl og den slags :P... Men burde give dig en ide om hvad jeg mener:
public class FormControler { private static FormControler _instance = new FormControler(); private FormControler() { }
public static FormControler Instance { get { return _instance; } }
private MenuForm _menu; private GameForm _game;
public void SwitchToGame() { if(_game.Visible) return; //Game is already visible
_menu.Hide();
//Hvis det ikke er nødvendigt at lave en ny GameForm for hvert nyt spil (der er en Reset Game funktion?), kan næste linie undlades, NB kommentaren i næste metode skal så også følges! _game = new GameForm(); _game.Show(); }
public void SwithcToMenu() { if(_menu.Visible) return; //Game is already visible
//Hvis det ikke er nødvendigt at lave en ny GameForm for hvert spil, kan Dispose erstattest af Hide istedet, og game=null fjernes ( + evt. kald til reset funktion ), Dette SKAL erstattes hvis der ikke bliver lavet en ny form i forige metode!! _game.Dispose(); //_game.Hide(); _game = null;
_menu.Show(); }
public MenuForm Menu { get { return _menu; } set { _menu = value; } } public MenuForm Game { get { return _game; } set { _game = value; } } }
public class Program { [STAThread] static void Main() { FormControler.Instance.Menu = new Menuform(); FormControler.Instance.Game = new GameForm();
md_craig -> I forhold til arkitekturen i Microsoft's egne GUI API'er er det du er i gang med der ikke helt pænt. De bruger meget det klassiske Composite design pattern, hvor en masse objekter bliver nested under hinanden i en form for træstruktur.
Du laver en noget mere horisontal løsning, som også har nogle problemer. Det åbenlyse: Hvis en bruger har menuen åben, og resizer vinduet, og derefter klikker på et punkt i menuen får du et Game-vindue med den forkerte størrelse...
Det er rigtigt at det er fedt at have en central klasse der tager sig af at skifte indhold i din form, men jeg synes kun du bør have en form, til hver vindue...
Det kommer jo helt an på hvordan du ønsker tingene skal fungere... Men fundamentalt er jeg i dette tilfælde muligvis enig... Men nu blev der sagt at han havde en Form til hver, så var det måske en nemmere løsning for ham...
Men derfor bygger den stadig på gode principer, specielt et princip om at Gui ikke skal holde styr på hvad der skal vises, og hvornår... om det så er forskellige Controller i gui, eller om det er visningen af 2 helt forskellige Guis...
En helt anden ting er, hvis vi her nsakker DirectX, er der slet ingen tvivl om at et vindue er det pæneste at gøre, men samtid er der heller ikke stor tvivl om at det ikke just er den nemmeste vej uden om...
Det kan godt være dit forslag er den nemmeste løsning på problemet, men der er ofte flere ting at tage hensyn til:
- Er det nemt at vedligeholde? - Hvis en anden udvikler kommer ind, er det så nemt at finde rundt? Hvilket det er, når man bruger kendte patterns - Hvordan performer det? At åbne nye vinduer hele tiden er vist ikke ligeså rart som at proppe nyt indhold i eksisterende..
Mmmm.... jeg ved ikke hvad du laver, men den der med at "der er ofte flere ting at tage hensyn til" krydret med de ting du nævner, well... det er bare ikke hvad der sker ude i verdenen...
Og vil nu mene det er lige nemt at vedligeholde, faktisk nemmere hvis princippet om en "Dum" gui skal holdes. Den måde at gøre det på var hurtig og dirty, men principet har jeg set mange mange steder... om det så er et kendt GOF pattern eller ej... så er det nok kendt af mange... og performance tror jeg for det første ikke der er stor forskel på i dette tilfælde... og når du snakker performance og hvad der performer bedst, så skal du også huske på frekvensen af operationen. her sker det måske hvert 5 min - 30 min afhængigt af hvor hurtigt spillet er eller hvor dårlig man er... så gør det ikke noget at de tager måske 1/10 sekund, det ser man ikke...
En stører pointe jeg vil trække på er at Hvis det er DirectX, så er det ikke længere EventBaseret, men derimod StateBaseret, og så kan ejg sige som jeg sagde før, at det er pænere, det er hurtigere, og det er 100% det rigtige at gøre...
Er det et Windows Forms baseret spil... well... så er det så som så... så kan begge nu fint gå, også til trods for alle dine Pointer, som da er gode Pointer... Design messigt ville det da være pænere at lave det som kontroller når de ikke skal kunne ses samtidig... det er vi da enige om, go det ville evt. kunne gøres endnu pænere end at pille controller ind og ud af en liste... derimod lave en control der var egnet til at switche mellem kontroller, lidt som en TabControl, bare uden det visuelle... det er bare stadig den mest tidskrævende løsning at lave det om han har nu...
Og nu har han fået 2 løsninger, så må han jo vælge ud fra det... det er jo i sidste ende ikke os der skal bestemme...
Hehe, nej det er ikke os der skal bestemme, for en gangs skyld ;-)
Til daglig laver jeg mest web-udvikling (ASP.NET og den slags) samt en masse behind-the-scenes-kode, hvor pænt design er det der driver din styrer din daglige arbejdsglæde.
Jeg har i den sidste uges tid siddet og rodet med et Java projekt der er meget fokuseret på GUI, og har fået mig en del erfaringer omkring måder at styre en applikations præsentation på, og har fundet ud af at jeg "bedst kan lide det" når også GUI er struktureret pænt.
Alt hvad jeg har sagt er dog udtryk for mine egne meninger, og min eneste interesse i at fremme godt design er at jeg, forhåbentlig, kan få folk til at tænke over hvad de laver og ikke bare trække en ny form ind i Visual Studio, når de skal lave noget nyt... Jo flere drag-and-drop værktøjer der kommer frem, jo sværere er det for os der godt kan lide at håndkode alt at argumentere for hvorfor det tager os længere tid at lave det samme som folk der godt kan lige drag-and-drop.
Men skal vi ikke sige at vi har luftet vores individuelle meninger, og skilles som venner?
Ja ok, så giver det nok lidt mening, kan godt huske mine gamle dage fra Web'en... Det er en helt anden værden, og nogle helt andre principper IMO...
Selv sider jeg dagligt og udvikler applikationer i .NET 1.1/2.0... Og jeg må faktisk stille mig lodret uenig i at Drag-and-drop er en dårlig ide... det er tværtimod en skide god ide når det er så stærkt som i Visual Studio 2005... (Java verdenen er noget skod til sammenligning, J-Builder er IMO den der kommer tættest på at lave noget pænt, og det er mildest talt noget rod den laver IMO)...
Men netop hele Microsofts Gui Builder, er tydeligt at der er tale om noget som er gennemtænkt og gennemarbejdet... 90% af det den laver ville ikke kunne kodes pænere selv i hånden, og de sidste 10% er et spørgsmål om smag... at nogle så får deres app's til at flyde med labal1, label2 og label3 variabler er ikke builderens fejl, men manden bag rettet... hvor tit ses det ikke også at folk bruger den fantastiske tmp variabel?...
En anden markandt fejl er folk der bygger foretnings logik in i deres Gui'er, desvære en alt for kendt fejl, som ofte har at gøre med hvor erfarende folk er...
Det som en god GUI builder gør, er at øge din produktivitet markant, men ligsom man skal lærer at programere ordenligt, så skal man også lærer at "bygge" gui'er ordenligt...
Jeg kan kun give en af mine kammerater ret i den her sammenhæng, og det er når han siger at så længe man lærer skal man gerne have det svært, men når vi så har lært... så skal det være let...
Og her er det ikke bare Drag-&-Drop builders der er i billedet, men også de daglige værktøjer vi bruger hvor der er indbygget Refactoring, Intellisense, Class builders, Reverse ingeniering, Debugging og mange flere yderst nytige værktøjer... problemmet med dem alle, er at det kan skabe dårlige programmører...
Men når man først har sidet og fedtet med at skrive JavaGui i hånden i 3½ år, og alligevel kan kigge tilbage på sin kode og sammenligne den med hvad VS2005 spytter ud, og se minimale forskelle, så er der for mig ingen grund til ikke at øge produktiviteten...
(Men man bygger ikke Web sider på den måde, der er Drag-&-Drop banlyst IMO)...
Og til slut, bare fordi vi har forskellige meninger, og deler vores synspunkter, så behøver vi ikke blive uvenner, jeg holder at at debatere, for det er også noget man lærer af...
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
