So me and my friends are developing Connect4 in C++. At first we elaborated the logic behind the game in a Visual Studio Console Application. We came up with 3 classes, "Logic", "GameUi" (That name is probably not suitable) and "Gui". (I should mention that all members off these classes are static members - so no instances)
Once the logic worked it was my job to tranfer it to Qt. And here's the problem:
So basically once the player has done an input (aka. The Player has chosen a column in which he wants to throw the slice (?) in) the Logic class processes this input and updates the vector in which we store the field. After this Logic calls the GamUi class, which should then call a function in the Gui class (Note that the Gui class is now the Qt class). The Problem with that is that I can't call a non-static function in the Qt class to change the Ui from a static function from a different class.
At first I thought about making the Ui public, which is according to the internet not a good programming exercise.
Thank you very much in advance
Ps: Please don't judge me for my non-native-speaker-english and my not very good c++ skills.
Assuming GUI is a singleton, you might code a static GUI::instance() method that returns a pointer to itself. Call it from anywhere and you have your pointer. Better yet, [inherit from QObject and] use signals and slots.
Related
Some time ago I programmed a GUI with QT Designer / QT Creator.
For this question I will first state a schematic of how the general process of creating a GUI with the mentioned IDE works:
Creating the design with the QT Designer -> Get .ui files
The .ui files are translated into header files and you especially get something like "UIbasisclass.h" (with class UIbasisclass) .
You create something like an "UIsubclass.h" (with class UIsubclass) yourself making one private member UIbasisclass ui.
Code within class UIsubclass:
...
private:
Ui::UIbasisclass ui;
...
Finally you will create an object of UIsubclass in the main method -> Code:
...
UIsubclass *MyGUI = new UIsubclass();
...
where the constructor of UIsubclass consists among other code of:
...
ui.setupUi(this);
...
In short: We have a UIsubclass that is mostly responsible for applicational methods, but also has a private member of UIbasisclass named ui that consists mostly of design code.
When we create an object of UIsubclass its private member UIbasisclass ui is initialized within the constructor of UIsubclass with the object of UIsubclass itself (?). [see: this pointer]
My questions are now:
Why isn't there used inheritance in the way that UIsubclass inherits from UIbasisclass? Instead one object of UIbasisclass becomes member of UIsubclass.
Is this some specific advantageous concept (if yes which advantages has it or how is it named?) or is it "just" a necessity of the QT code structure?
Let me know if I have to specify my questions or if there are any questions.
You can do with private inheritance, it is even documented in Qt documentation.
The use of a private member for ui is the default because of the templates used by Qt Creator, Qt itself does not care.
Why isn't there used inheritance in the way that UIsubclass inherits from UIbasisclass?
You're asking us about why you didn't do it in your own code? Just do it. It's up to you. It truly is your code. You are responsible for its design. If you're using a template, it's there to help you get started, but not to design your software for you. The responsibility is yours, and yours only.
it "just" a necessity of the QT code structure?
There is no such necessity. The Ui class is a POD class with a bunch of pointers and one method. Nothing much to it. If you want to privately inherit from it: go right ahead.
Because with a private member you can forward declare the generated class:
namespace Ui {
class MyForm;
}
class Foo {
private:
Ui::MyForm *ui;
};
and on the .cpp file you insert the include.
this way all of the possible includes of this file will not have to preprocess that file again.
I'm trying to invent a GUI testing library for Qt. The library is meant to work remotely, so that I can run tests on mobile devices over WiFi. It should simply provide API for visible element's functions.
It should be extensible. In Qt, any visible GUI element is subclass of QWidget. I can hard-code handling for QPushButton (eg. clicking) or QLineEdit (writing text) but note that user can define his or her own QWidget subclasses, some of which may represent completely new kind of GUI.
In Java, I could solve this because class type is essentially a variable of Class type. So I could have:
public static void registerTestingHandler(Class<? extends java.awt.Component> GUIObject, Class<? extends TestingApi> apiHandler) {
...
}
The TestingApi would then be some basic interface which would accept messages as strings, eg: handler.doAction("click");
C++ doesn't have this kind of reflection. I also learned that it's impossible to get class' constructor address which could be used for this purpose. I think the whole design should probably look different in C++.
Therefore the question is: How do I allow user to register abstract handlers for specific class instances?
I'm developing a game using OpenGL. I have a Game class that contains all the environment variables (by environment, I mean things like gravity or tile sets). There's only one Game object. I also have another class called Entity, which contains properties to display objects on the screen.
I'm finding myself needing access to more and more Game variables in my Entity class. At the moment i'm just using parameters to pass data into each function, but I'm considering just passing a pointer to the Game class? Is there anything wrong with that? Is there a better way?
I think this is good practice. It is good idea to replace a group of parameters with a parameter object.
Just make sure that Game remains cohesive. The variables contained within Game should be related.
Make Entity a Friend of the Game class.
Please see
http://msdn.microsoft.com/en-us/library/465sdshe.aspx
Note: If this is ever done in C#, there isn't a friend keyword or exact equivalent.
I currently have a problem with mutual inclusion in a project of mine (C++).
Normally, if I had a mutual inclusion problem, I'd easily solve it by either forward declaration or redesigning the classes a bit. But this time, I'm stuck:
I have a class called Game, which creates and launches core game systems, where one of these is called GraphicsSystem.
In the Game constructor, a GraphicsSystem object is dynamically created and stored in a GraphicsSystem* pointer. Looks like this:
Game::Game ()
{
gfxSys = new GraphicsSystem(80, new Camera());
}
Now my GraphicsSystem class needs to access a Game class's method at one point to get the player object, which is stored within the Game object. The respective part looks like this (Game is btw a singleton!):
void GraphicsSystem::handleFrame ()
{
ElementList elements = Game::instance()->getPlayer()->getEnvironment()->getElements();
}
Now I tried forward declaration in both directions already, but that wouldn't satisfy the compiler. I could of course also just put the player pointer into the graphics system, but I really don't want to do that, since he doesn't belong there.
Is there any way to resolve this without me having to change the design too much? I'm really stumped right now, so I hope you guys can help me.
I'm using Visual Studio 2010 (Visual C++).
Thank you in advance!
Chris
Forward declare GraphicsSystem in Game.h. Include Game.h in GraphicsSystem.h if it needs it. Include Game.h and GraphicsSystem.h in Game.cpp. Include Game.h and GraphicsSystem.h in GraphicsSystem.cpp.
That should work based off the code you posted.
There are two main ways to break circular dependencies in C++.
1) Create a 'interface' class which lists the methods implemented by your real class and which your real class inherits from. Then you can include that instead of the declaration of the real class.
2) Pimpl - a class holds an opaque pointer to its real data, solving the problem of having to include declarations for the types of member variables.
I know this is going to sound dodgy, but have you considered holding a global reference to the initialized Game class?
I know globals are evil and so on and so forth, and I'm sure lots of people are going to rage, but in my personal experience I have succumb to Singletonitis with the Game class (among others) and found that sometimes it just simply isn't necessary.
The biggest question you need to ask yourself is "Who are you trying to protect your Game object from? and is there any reason why you need to request an instance each time you need the game class? I'm pretty sure that if your Game object wasn't initialized, you wouldn't be doing much else in your engine anyway.
Hope this might help you think about things in a different way, even though it's not answering your question directly.
So, I'm making a simple game using DirectX 9 and C++. I looked at the SDK's GUI, but I think I can implement something simpler.
All I want are windows, labels, buttons, textboxes, and checkboxes.
I've created a base class GUIObject, that all inherit from. It includes basics like size and focus and whatnot. Then the derived classes, GUILabel for example, all define render(), update() and whatnot.
My question is how to handle events, like clicks? I had it working with GUILabel::Click() defining every possibility based on the current instance's text member value. It felt wrong and I realized that every single label that needed to be clicked would have to be defined in the GUILabel class. I'd like to move that to each game state's code.
So, I briefly tried making the GUILabel::Click() take a function pointer as an argument. But then I realized I needed to have the state's class member method as static (not really possible, unless everything in it is static as well, right?) or also pass it a GUIObject class as well. Is that the way to go?
Could I define a derivation of GUILabel (or button, or whatnot) within a game state and just override whichever actions I needed? And then do that for whatever controls I need in that state?
What is the proper way to implement event handling?
You might want to look into using a signaling library such as boost::signals to allow you the flexibility of defining the interface between your GUI objects and the underlying events that each callback will trigger. It can also come in handy for the reverse relationship where you need GUI elements such as status indicators, etc. to respond to underlying events.
For callbacks/click events i would go with boost::function/boost::bind.
In my GUI framework I used to have two different abstract classes InputHandler and Renderable for handling touches and rendering. This leads to a design where components which don't need to be clickable (like UILabel) wont need to implement useless methods.
HTH,
Alex