I've used glutdisplayFun(void(*func)) in several of my program to sets the callback display to the current window.And by the use of it, i've rendered different things on the screen. By looking at the documentation of glut, passing null to it is illegal and we can't deregister it also.
The problem is that as we can't deregister it and i write a set of code to display the mainmenu(i.e as shown in the game). And i like to change to next window on the keypress(i.e play the game by clicking on the option play present in the mainmenu).
How to make the glutdisplayfunc call to the mainmenu inactive and and to set the glutdisplayfunc() for calling the next window.
std::%something%<std::function<void(void)>> displayFns;
void myDisplayFunc() {
for (auto& displayFn : displayFns)
displayFn();
}
Now register myDisplayFunc to GLUT and change the displayFns collection.
As for something, map<int, function<...>> would be a good start. Unordered map if you can guarantee your code doesn't need to be called in order. It starts to resemble good old BASIC times with line numbers, but I said upfront it will be a simple answer.
That's not how I would do it, but should do the trick for a quick'n'easy solution.
Funny thing with this is that you can create sets of those to have one element appear in more than one choice rather easily. So maybe it's not that bad after all.
Related
I have a school project involving creating a simple GUI and coloring graphs using a minimal number of colors. I am working with a classmate, and so far, we have laid out different ideas regarding how we will store the graphs in memory, and how to implement different coloration algorithms.
To create the GUI, we are using Qt, as I used it for another project before, it is free, and I generally find the documentation generally well detailed. Besides, I knew it had a drawing module, although I never used it.
After reading and the documentation and some examples, I was able to draw some basic shapes where I wished inside of a set area of a widget, and get them to correctly respond to resizing the widget.
To draw what I wish, I can write the paintEvent method this way, and just never use *event
void DrawArea::paintEvent(QPaintEvent *event)
{
//method body
}
Or I can write it this way, and it works too
void DrawArea::paintEvent(QPaintEvent *)
{
//method body
}
So, i have two questions :
How does the widget knows when to call the paintEvent method ?
If I'm not mistaken, every widget has a paint event, and I am
overwriting it ? If it's wrong please correct me, maybe that is the
reason why I don't really understand the way this pointer work.
What is the QPaintEvent pointer ? (I mean, what does it represent ?)
Thanks for any insight you may give me
So much text and so little questions...
You should learn about events handling in window systems (keywords are event loop, event queue and so on; in terms of Windows OS events are named "messages"). It is simple and useful thing to know.
In short, your program asks OS for new tasks time after time. If they exist, some information about it is provided, and you should handle them. Otherwise OS stops the program until such tasks will appear.
It means that OS notifies you to handle paint events when you are ready to do it.
QPaintEvent provides additional information about the event. At present it can give you a region to redraw. It may be used for painting optimization in some cases. But in simple cases it is not used.
EDIT:
This question isn't about briging a window to the front of EVERYTHING, just for my specifc application. I'd like the frame they were interacting with to be behind the new frame. Much like a dialog, except that it is not a dialog. I don't think this is bad practice, something was summoned (in this case via a menu) I expect it to be infront of the window I used to summon it.
I just read How can I ensure that a wxFrame is brought to the foreground? and that didn't work either.
SetFocus(); makes the window want my attention (it flashes in my task bar in the case of my platform, GTK and MATE task bar if that matters)
Raise(); does.... nothing
Show(); shows it, obviously, but despite it's newly created status nothing happens.
Weirdly clicking the window doesn't bring it to the front until after I have done something in the parent despite showing as the thing I am interacting with in the task bar. I am using all the 3 of the above (Show, SetFocus then Raise).
I've read Raise's documentation ( http://docs.wxwidgets.org/trunk/classwx_window.html#a54808c933f22a891c5db646f6209fa4d ) Raise and Lower are "z-order functions" - this suggests that it's supposed to do this. I have never really had much success with it though. I'd be really really nice if the starting frame came to the foreground whenever I run for example, but given the amount of times I press run and the project is built compared to the amount of time spent writing code and the fact creating a new folder even is more frequent, I've put up with it.
It'd be nice to get it fixed!
Addendum
Using Lower on the parent hasn't worked. There will be 64 less a few obvious ways to try this, I really want to avoid stumbling about.
I believe ravenspoint, and this is not a good user interface trick, but, if you don't mind a little bit of flashing... and stealing of focus, regardless of where you may be typing, etc, etc, just kinda bad...
ParentWindow->Iconize(false); // restore the window if minimized
ParentWindow->SetFocus(); // focus on my window
ParentWindow->Raise(); // bring window to front
ParentWindow->Show(true); // show the window
And before you do, think about another critical application running with
"Enter the counter measure launch code, impact in 12 seconds: "
and half way through typing, your window decides to pop to the top.
I have a Window object which contains only a grid. I want to use Gtk::Builder to get a pointer to the grid, and then use some Gtk::Box's Gtk::Box->pack_end() to add the grid to it many times (with manipulated contents each time).
Though each time that pack_end() is called I get:
gtk_box_pack: assertion 'gtk_widget_get_parent (child) == NULL' failed in my terminal and nothing gets added to the box.
What should I do?
Thanks
* EDIT:
Goal:
I want entries of a DB table to be put into a fancy widget for each record, though all the records being shown vertically one after the other. I thought I can create the fancy widget as a window in Glade and use Gtk::Builder to get a pointer to it. So in the fancy's Glade file I have a window containing a grid that has my custom appearance. I get the above error when I try to add the pointer to the fancy *grid*, to the visible window's Box. I hope I'm clear.
Here's the solution to gtk_box_pack: assertion 'gtk_widget_get_parent (child) == NULL' failed:
All that needs to be done at the first place is that you should draw the widgets WITHOUT a window, so when loaded with builder, it won't have a parent and thus the assersion succeeds.
Though here's another point: When I add the first instance of the grid to the Box, the second one results in the same error again. After a couple of trials and errors I realized that in each interation you should use Gtk::Builder::create_from_file() to create a new parent-less instance of the grid to be able to use, and this way it works.
There has to be a great difference in performance, in case number of records is gonna be big, but Gtk::Widget's copy constructor is private and direct copying is not possible, and since it wasn't my main obsession I didn't insist on resolving this "performance" issue.
Sorry for the ambiguous title. What I am wondering is what is an efficient way to alternate rendering between lets say a main menu, options menu, and "in the game."
The only two ways I've come up with so far are to have 1 render function, with code for each part (menu, ...) and a variable to control what gets drawn, or to have multiple render functions, and use a function pointer to point to the appropriate one, and then just call the function pointer.
I always wonder how more professional games do it.
Try to use state-machine / strategy OOP pattern. Game application is in different states and renders different things and reacts on keyboard/mouse input differently when you are playing and when you are interacting with menu.
Well this is a bit more complicated if you want to do it right.
First I create a CScreen class that's the base class for all the screens. It's an abstract class( use pure virtual functions) that has 2 functions: Render and Update. Then I derive it in more screens that I need such as CMainMenuScreen, COptionsScreen, CCreditsScreen, CGameScreen etc. Let each of these classes take care of their own stuff. In each of them you have the interface and then when press for instance the options button in the main menu screen then you change the screen to COptionsScreen. For that you have to just keep one variable CScreen screen somewhere and on every frame call screen->Update() and screen->Draw() remeber to adjust if you do not use pointers(tough I'd recommend this)
If your controls are represented as classes then a polymorhic API render would solve the problem. Depending on the object ( menu types) the corresponding rendering happens.
class UIObject
{
public:
virtual bool render() = 0;
~UIObject(){}
};
class MainMenu : pu{
public:
virtual bool render()
{ //rendering for main menu
}
};
class OptuionMenu
{
public:
virtual bool render() { //render for option menu}
};
Games that I've shipped, that have sold lots of copies, have had a state machine and used switch statements to choose the appropriate functionality. While ostensibly less flexible than an "OOP" state machine, it was far easier to work with than the OOP designs I've subsequently been subjected to.
It actually may be appropriate to have only one render function, but that function shouldn't know specifics about what it's doing. It'll have 3D and 2D passes (at least, for a 3D game, since even those often have 2D UI elements), but it doesn't need to know what "mode" the game is in.
The magic happens in the UpdateMainMenu or UpdateGame or UpdateInGameMenu functions, as well as the Start and Stop functions associated with switching states. Choose which with a switch statement on an enum and use it two places, switching states (one switch to stop the old state, one more to start the new one) and updating.
As I write that my alarm bells go off that this is a perfect opportunity to use OOP, but from experience I would advise against that. You don't want to end up in the situation where you have a million little states that are coming and going; you want to constrain it to the major "run modes," and each of those modes should be able to operate on data that tells it what to display. E.g. one state for the entire in-game menu, which "loads" data (usually, "updates its pointer to the data") to indicate what the behavior of the current screen is. There is nothing worse than having a hundred micro classes and not knowing which one triggers when, not to mention the duplicated logic that often arises from such a design (game developers are very bad at reducing duplication through refactoring).
In win32, how do I setup a callback mechanism for RichEdit I have not created myself?
PART 1
I'm reading from a textedit field in another application's GUI. This works just fine now, except after the first read I'd like to fetch only new or modified lines. In GTK+ or Qt I'd just install a callback on some signal the field edits when its changed, but how does it work on Win32?
My MSDN searches result with nothing useful, probably because I don't know the exact term to search for. The class of the textedit is RichText20W, and it has some messages that are probably used somehow, though that article just discusses using them for the parent of the class.
PART 2
Also, if there is no such "text changed, here is the newly inserted text" callback which returns the new content immediately, I need some way to easily detect what is new. From top-of-my-head:
Have a marker at the end of the text block we've read, and only read between that and the end.
Store what we've read previously, and after a second read, remove the duplicate part from the latter to have the newly inserted stuff.
Option 2 might not be viable, since the textedit can contain any amount of text. The marker part sounds doable, but yet again, my feeble Win32 skills and horrible Win32 function names prevent me from finding the right way to do it.
Note that all these must be doable for a textedit I do not own and have not created, they belong to a third party process.
Code samples in C++ highly appreciated.
Disclaimer
Obviously, if there is some better way of doing it, let me know. I only assumed callback would be the way to go based on my previous experience with GTK+/Qt. Feel free to show me the path :)
Win32 controls don't work on message-specific callbacks that you can subscribe to. They just send messages to their parent window when something happens, in this case EN_UPDATE, EN_CHANGE and all that. Even these events don't tell you what text changed. They only tell you that it did change.
You could subclass the parent, but the documentation for SetWindowLongPtr explicitly says you "should not subclass a window class created by another process." Something like this is probably possible with hooks, but I haven't used them enough to say for certain how you'd actually do it.
I realize it's an old post, but this article seems to be doing something similar.
Based on Joel's answer, I quit looking for callbacks and just made a small class that hooks itself (not by a real API hook though) to the richedit and polls it once a second for content length, and if it has changed since the last poll, it asks for the content, compares that to previous known content and emits a signal with the changed content.
This seems to work OK for this purpose, but if someone knows a better way still (some real and tested way of doing it via API hooks or something), please post.