[SOLVED] Change Window-Style on the Fly

[Glocke]

Hi, I wrote a loading screen which shouldn't allow resizing the window while loading. Is there any possibility to change the window style on the fly? The only approach I found, is closing the window and recreating it with the right style. It is working but I don't like that close-open-close-open, when entering the loading screen and leaving it (so resizing should be reallowed).

The approach works great if you want to have a splash screen before the actual startup, but looks weird if the it appears during a loading in the middle of the application. Additionally, I'd need to track the window title on my own, because there is nothing like getTitle() either. I'm not quite sure how to deal this situation..

Kind regards
Glocke

[zsbzsb]

There is no way to change the window style without reopening the window. However, I don't see why you need to disable window resizing only on a loading screen so maybe you should expound more on that topic.

[Glocke]

so maybe you should expound more on that topic.

While loading, multiple subsystems are initialized. They have access to the RenderWindow via const reference in order to query the window size for their tasks. I'm not sure whether it is a good idea to allow resizing the window during this process - doesn't seem that this will always lead to a valid state.

Well, no bugs occured yet. But I don't think that this is always true. To be honest, I'm scared whether side effects could happen... Querying the window size first and then passing the resolution to all systems doesn't seem to be a good solution either. I'd need to track the latest resize event and apply it to all systems after the loading is done - in order to guarantee that all systems work with the correct window size.

/EDIT: One of the systems is creating some RenderTexture's based on the window size. If the window resizes, possibly one render texture would be larger or smaller than the others - which is a problem. Btw the loading state is using a thread for loading, so all input events are handled.

[zsbzsb]

Maybe instead of passing the entire window pointer in... just pass what you need to know. So grab the size once, and then pass that same size to the rest of your loading logic. And one more thing, SFML isn't known as having a thread safe API so depending on what you access from your loading thread well... I would be more concerned about that than having a render texture created at a different size.

[Glocke]

Maybe instead of passing the entire window pointer in... just pass what you need to know. So grab the size once, and then pass that same size to the rest of your loading logic.

Thanks, I think that would be best!

And one more thing, SFML isn't known as having a thread safe API so depending on what you access from your loading thread well... I would be more concerned about that than having a render texture created at a different size.

Well, the entire loading is done by one thread, the main thread is just looping until the other thread finished. I do so to allow the main thread to draw some sf::Text while loading - displaying "Loading: Sprite animations", "Loading: Level generation" etc. So the problem might not be that heavy.
But anyway, thanks for your thoughts

[Glocke]

Meanwhile, I applied the advice: So I query the window size and pass it to the thread when starting it. While waiting for the thread to finish, all resize events are stored to a single variable (which is overwritten if two resize events occure). So finally, I can apply this delayed event to the game state after loading is done. Works just great