SFML community forums
Bindings - other languages => DotNet => Topic started by: nihohit on April 08, 2012, 03:18:52 pm
-
Using SFML's RenderWindow on VS2010 freezes the window. Original explanation was a bit muddled, I'll try to make a clear explanation:
Let's say I'm debugging my application, which currently only runs an animation in a newly opened RenderWindow. (Why debugging? because running it doesn't work at the moment.) Let's call this new window App. If I'll select any other window, including the commandline window that pops up when debugging, I won't be able to select App again, let alone display it once it was covered (even partially-covered) by another window. If only partially covered, I can see that the animation continues, but the only way to see the whole window again is to minimize everything else.
The same is happening when run in Mono, but then Windows actually marks App as non-responsive.
When browsing for a solution I found this (http://www.sfml-dev.org/old-forum/viewtopic.php?p=44355&sid=0b5768fde39ee08d5f032cff8b2ae324). Is upgrading to SFML 2.0 the only way to solve the problem?
-
small correction - I can "Start without debugging" in VS2010, and when that is done I can re-select the window, but it's still unresponsive.
So - VS debugger - can't reselect window. without debugger and Mono run & debugger - can reselect, is unresponsive.
-
A small code example would help a lot.
Also switching to SFML 2.0 wouldn't be such a bad idea specially since it seems you're not yet deeply into SFML 1.6. SFML 2.0 has quite a new API specially in the graphic section so you'd have to read again first about the changes.
-
Sorry. This is enough to recreate the problem:
class main
{ static int Main
(string[] args
) { SFML
.Graphics.RenderWindow mainWindow
= new SFML
.Graphics.RenderWindow(new SFML
.Window.VideoMode(960,
640,
32),
"main display"); mainWindow
.Display(); Console
.In.ReadLine(); return 1; } }
-
As for SFML 2.0, I'm not that expirienced and I think that for now I'll avoid the whole CMake process, and try to work with the given libraries of SFML 1.6 - I presume they work, and that the problems I'm facing are avoidable.
-
Hey there, updating to SFML 2.0 .Net is simple and you do not have to worry about using CMake. SFML 2.0 comes with precompiled CSFML 2.0 binaries. All you need to do is download the latest version from https://github.com/SFML/SFML.Net (https://github.com/SFML/SFML.Net) and compile it like any other .Net application.
As to the freeze, it sounds as if your not handling events. Try to handle events in SFML 2.0 and then see if the problem disappears.
-
Thanks, but I'm still flummoxed.
a. I couldn't managed to run the program with SFML 2.0. I downloaded the files, but there were no equivalent to the library files. I don't mean to go off topic here, but I'd really thank a link to a clear tutorial on installation.
b. By "handling events", what exactly do you mean? I use Window.DispatchEvents() during the screen's loop, and there are event handlers for losing & gaining focus, but they aren't activated when I switch windows.
-
Upgraded to SFML 2.0. While I'm now having updating problems, this problem seems to be solved. Thanks for the help!
-
Correction - this works only on a single threaded program. When used with a mult-threaded program and the display isn't in the main thread, the problem persists - even after creating the event handlers in the new thread, and setActive(false);
Any idea why?
-
Please show a complete and minimal code that reproduces your problem :)
-
using System.Threading;using SFML.Graphics;using SFML.Window;using System;namespace Game
{ class main
{ static int Main
(string[] args
) { Temp display
= new Temp
(); Thread graphicThread
= new Thread
(new ThreadStart
(display
.run)); graphicThread
.Start(); graphicThread
.Join(); return 1; } public class Temp
{ RenderWindow _mainWindow
; public Temp
() { _mainWindow
= new RenderWindow
(new VideoMode
(600,
600,
32),
"main display"); this._mainWindow
.SetActive(false); this._mainWindow
.GainedFocus += new EventHandler
(OnGainingFocus
); this._mainWindow
.LostFocus += new EventHandler
(OnLosingFocus
); } public void run
() { while (true) _mainWindow
.Display(); } } static void OnLosingFocus
(object sender, EventArgs e
) { Console
.Out.WriteLine("lost focus"); } static void OnGainingFocus
(object sender, EventArgs e
) { Console
.Out.WriteLine("gain focus"); } }}
-
There's still no call to DispatchEvents in this code.
-
Sorry, here's with - still doesn't work.
using System.Threading; using SFML.Graphics; using SFML.Window; using System; namespace Game
{ class main
{ static int Main
(string[] args
) { Temp display
= new Temp
(); Thread graphicThread
= new Thread
(new ThreadStart
(display
.run)); graphicThread
.Start(); graphicThread
.Join(); return 1; } public class Temp
{ RenderWindow _mainWindow
; public Temp
() { _mainWindow
= new RenderWindow
(new VideoMode
(600,
600,
32),
"main display"); this._mainWindow
.SetActive(false); this._mainWindow
.GainedFocus += new EventHandler
(OnGainingFocus
); this._mainWindow
.LostFocus += new EventHandler
(OnLosingFocus
); } public void run
() { while (true) { _mainWindow
.Display(); _mainWindow
.DispatchEvents(); } } } static void OnLosingFocus
(object sender, EventArgs e
) { Console
.Out.WriteLine("lost focus"); } static void OnGainingFocus
(object sender, EventArgs e
) { Console
.Out.WriteLine("gain focus"); } } }
-
Thanks, I'll test this as soon as I can.
And next time can you please use the code tag in your posts, so that I don't have to edit all your messages?
-
Ah, in fact your problem is a typical one: events must be handled in the thread where the window was created. This is a limitation of the OS.
-
Thanks!
Is this common with other classes too? Does this mean that the thread that opened the screen needs to handle display & input?
-
Is this common with other classes too? Does this mean that the thread that opened the screen needs to handle display & input?
No, there's really no other constraint than what I said: events must be polled (DispatchEvents) in the thread that created the window. As far as I know, all common OSes behave like this (it's even worse on OS X where all windows must be managed in the main thread).