next »

[nikki]

Hi i am in the process of making a GUI for my program, and have decided to go out all the way and write my own GUI editor.

Mostly the Gui consists of screens/windows with gadgets/buttons on them .
The logic of wich gadget disappears and what gadget appears when you press button 'x' is in place. and working.

The question i have is about the buttons that have a real effect for example there is this button somewhere that tells the MAIN.EDITOR to change drawing routine to "wall-drawing with Bresenham Lines" for example. And like this there are many more buttons that have effects on classes all over the place ..

What would be good practice for such a 'spaghetti' sensitive area ??

[BlueSweatshirt]

I'm not totally sure what you mean-- But, check out the MVC design pattern.

[Falmil]

Um, I have no idea what you're saying. If you're asking how not to turn you editor code into spagetti based on all the different buttons doing different things, you could use a state machine so different keys change the state and mouse clicks do different things depending on the context. (You said 'x' button, but I'm not sure if you meant like a keyboard key or an actual graphical button). You should probably elaborate and define terms like "gadgets".

[nikki]

mm , i'll try again:

some gadget i can use in my gui-editor have an effect on another gui-gadget  for example :(window [a] has button b and when you press that button window b appears) this works well because every window and gadget have their unique id, the way i save that gui is easy too because of those id's (in the file thats just a integer value).

the problenm i'm seeing is with the buttons that have a 'real' effect in the program : for example a button that closes the program , or a button that decides the zoom factor.
these results arent the same as an id of a gadget, but it would be sweet if i could come up with a way to save those effect too.

I think a simple enumeration of all the different possible effects is probably what i'm after..


thoughts, ideas ?

[Falmil]

So, the GUI buttons affect the game by possibly executing some kind of "Quit" command or "Zoom" command? And you don't know how/what to save in your GUI so that it can interact with the actual game? If you're able press a "button" to open a window, I'm not sure what the problem is in pressing a button to have a different effect. You could use some kind of event based system. Maybe I'm still not understanding the issue.

[Chris Whitman]

What language are you writing in?

Most have support for function pointers, functors or the like, so you could have the button creator pass a callback function to the button which is invoked when the button is clicked. That way the button doesn't have to know anything specific about what it's doing, and the caller doesn't have to know anything about anything going on inside the button.

I think that's the usual method... if I understand your question.

[nikki]

i'm writing in blitzmax,

where you could make the equivalent of function pointers, havent used them much though, but i think you understand my problem.

the plan i have now is

• to enumerate all possible in-program action any button could have.
• each button knows :
  
  • a)wich enumerated other window it'l open when clicked or
  • b)wich in-program action number it starts.
  • c)how to save this in an external file/string
• somewhere higher in the program where all actual gamedata lives, i'll just receive the numbers the buttons shout and lookup wich function i'll need to run (with what parameters) (would this be the place of them funky functors ?)

 

 

[BlueSweatshirt]

What language are you writing in?

Most have support for function pointers, functors or the like, so you could have the button creator pass a callback function to the button which is invoked when the button is clicked. That way the button doesn't have to know anything specific about what it's doing, and the caller doesn't have to know anything about anything going on inside the button.

I think that's the usual method... if I understand your question.

Could you pass me a quick example of this? I don't mean to totally thread hijack, but I think it's relevant. I'm using C++, but he's not, and sadly I don't think you can pseudocode something that's pretty language specific.

Also, if I'm reading your post right, trying to guess any possible action the app developer may want to take(especially yourself-- Since you'll probably push your engine to it's limits for the fact that you know them) is a very bad choice. Why? Obviously because you can't cover all possible outcome.
I recommend going the MVC approach with function pointers. Much more flexibility, and I think it'd be easier once you got to writing the actual app.

Another approach you can do is an event system, which is somewhat like what you're describing. You can poll the object for things that have taken place, such as being clicked or a slider value being changed. From there you can use your own high end logic to deal with it.

Personally, I prefer function pointers. For reference, Windows uses an event-style approach(afaik), and Mac uses a function pointer approach.

[Sam]

I'm just scrubbing around in Actionscript, but the way I make buttons-and-things from scratch is something like:

Code:

myStartButton = new FancyButton(startNewGame);

function startNewGame():void
{
   //do stuff
}

An instance of the FancyButton class will store a reference to the function passed to it when it's created, and make a call to that function when it detects that it's been clicked.  As Chris says, this way FancyButton doesn't need to know anything about the rest of the program, all it knows is how to detect that is has been clicked and that it should call that particular function when it is clicked.

Nice thing is you can use many FancyButtons for whatever you like, without having to go and fiddle with the FancyButton class itself.

Code:

zoomButton = new FancyButton(zoomIn);
createZombieButton = new FancyButton(makeZombie);
closeWindowButton = new FancyButton(closeWindow);

function zoomIn():void
{
   zoomFactor++;
}

function makeZombie():void
{
   new Zombie();
}

function closeWindow():void
{
   myWindow.close();
}

Flash has a pre-made event handling system all built in that I absolutely should be using for simple stuff like this, but reinventing the wheel is so much more fun.

[Mikademus]

Just cook up something basic. Something like my pseudo-code below (lotsa boiler plate left out), which should work in any language:

Code:

widgets : map of id<-string, control<-Widget


class Widget
   id : stirng
   action : function pointer
end class


class Button extends Widget
   enable
   end

   disable
   end
end class


def DisableOther
   map["quit program"].disable
end


def QuitProgram
   exit
end


main
   var button1 : Button("process data", DisableOther )
   var button2 : Button("quit program", QuitProgram )
end

As you understand, the meat of what you want to do lies in the functions that you associate with a widget on creation.