Getting the window handle

[Jallen]

I'm using SFML for my A level computing project, a physics simulation for my school.
I have a problem however, as I made my own GUI system and I am using SFML's input system. When you make the window size different, the mouse position is incorrect, so clicking a button will click somewhere entirely different.

How can I stop the window from being resized or made fullscreen?

Also, I'd like to be able to get the hWnd, how can I do that?

Problem 1 solved

Code: [Select]

sf::RenderWindow* rwindow = new sf::RenderWindow(sf::VideoMode(800, 600), "Roller Coaster Simulator", sf::Style::Close);

Now, how can I get the hWnd?

[Daazku]

I'm using SFML for my A level computing project, a physics simulation for my school.
I have a problem however, as I made my own GUI system and I am using SFML's input system. When you make the window size different, the mouse position is incorrect, so clicking a button will click somewhere entirely different.

How can I stop the window from being resized or made fullscreen?

Also, I'd like to be able to get the hWnd, how can I do that?

Problem 1 solved

Code: [Select]

sf::RenderWindow* rwindow = new sf::RenderWindow(sf::VideoMode(800, 600), "Roller Coaster Simulator", sf::Style::Close);

Now, how can I get the hWnd?

Maybe the problem is your GUI you know...

[Jallen]

No, it isn't.
The co-ordinates given in Event.MouseMove.X and Event.MouseMove.Y are pixel based, therefore a fullscreen window has more pixels, but everything is stretched, so the new pixel values of the buttons are wrong. I could have fixed it with finding the window size, but i decided to lock the windows size, besides, i fixed that by fixing the size.

I need to know how to get the window handle.

[Laurent]

The co-ordinates given in Event.MouseMove.X and Event.MouseMove.Y are pixel based, therefore a fullscreen window has more pixels, but everything is stretched, so the new pixel values of the buttons are wrong

That's why SFML provides the RenderWindow::ConvertCoords and Drawable::TransformToLocal functions.

i fixed that by fixing the size

Not really a "fix"

I need to know how to get the window handle.

For what? If SFML is lacking a feature I prefer implementing it (or teaching you how to implement it using existing features), rather than giving a raw access to the window's internal handle.

[Jallen]

First (not of great importance), the window needs repainting when it is moved off screen. If you drag the window under the task bar and move it out again you get an ugly smudge across your window.

Second and this is the important one, I need a way to reduce my CPU usage when the window is not in focus. I also need to be able to check if the window is minimised and reduce my CPU usage then.

[Laurent]

First (not of great importance), the window needs repainting when it is moved off screen. If you drag the window under the task bar and move it out again you get an ugly smudge across your window.

You should rather report it as a bug so that I can fix it for everyone

Second and this is the important one, I need a way to reduce my CPU usage when the window is not in focus. I also need to be able to check if the window is minimised and reduce my CPU usage then.

This is planned for SFML 2.0.

[Jallen]

Ok, cool. Right now though, I need a solution, I have a deadline.
So how can I get the hWnd?

[Nexus]

Second and this is the important one, I need a way to reduce my CPU usage when the window is not in focus. I also need to be able to check if the window is minimised and reduce my CPU usage then.

What about reacting to LostFocus and GainedFocus events? For example by manual sf::Sleep()? At least that could bring the CPU usage down to a few percents.

[Laurent]

Ok, cool. Right now though, I need a solution, I have a deadline.
So how can I get the hWnd?

You can modify SFML to add an accessor to the window's handle, and use your modified version until the next release.

What about reacting to LostFocus and GainedFocus events? For example by manual sf::Sleep()? At least that could bring the CPU usage down to a few percents.

LostFocus and GainedFocus are not the right events: your window can be minimized but still have focus, or loose focus but still be visible.
SFML 2.0 will handle two new events for this: Activated and Deactivated.

[Jallen]

Argh.

This is annoying. I don't think it's worth going into SFML and modifying it, but at the moment its rendering constantly with a Sleep(5) in it, which is fine for a game, but this will sit there, perhaps minimised, perhaps behind other windows, just doing nothing, waiting for a teacher to use it. This is a big problem because its CPU usage is so high.

I want to only render when something on screen has changed. Unfortunately that is not a possibility because any window passing over it would then screw up what is painted on my window because i don't have access to the paint event.

I guess I'll just have to render once every 200ms or something unless something changes, in which case I will render it instantly.

Thanks for your help.

[Laurent]

I don't think it's worth going into SFML and modifying it

Retrieving the window handle is really straight-forward; it doesn't even need to be Windows-specific (SFML defines a WindowHandle portable type). It could be done in five minutes

I'm curious regarding what you said, what kind of application are you developping? Do you really have issues with CPU consumption, or is it more an early optimization?

[Jallen]

I'm drawing 41 circles and 40 lines, as well as 4 rectangles and 4 bits of text.

CPU usage is 39%, which is 78% of one of my cores.
I have a Sleep(5) in there to help a bit, without it it's 50% CPU (100% on one core).

[Laurent]

You should rather use UseVerticalSync or SetFramerateLimit, and probably render less than 200 frames per second (unless you really need it for some reason).

[Nexus]

Sleep(5) is probably to few. Especially, the game doesn't run fluently if you wait every frame the same time (the code-execution duration varies).

You could try sf::RenderWindow::SetFramerateLimit().