SFML community forums
Bindings - other languages => DotNet => Topic started by: BuGG on July 19, 2011, 12:47:43 am
-
I updated to the most recent revision of SFML 2 .NET today and have noticed a little different behavior from the Input class.
Previously window.Input.IsMouseButtonDown only returned true if window was active.
In the new version, Mouse.Input.IsButtonPressed returns true regardless of the state of the window.
What is the proper way to determine that a window is the active window?
(or am I missing something obvious here?)
-
Inputs are now truly global (independant of windows), they directly read the mouse/keyboard/joysticks state.
If you want to watch inputs that happen on your window when it's active, you should rather use events. Or you can watch the focus events and use (or not) Mouse.IsButtonPressed accordingly.
-
I was really hoping this wasn't the case, I really prefer IsButtonPressed over events in a lot of cases. However, I can also understand the reasoning behind global input state as well...
Is there any possibility of a window.IsFocused at any point in the future?
I realize I can accomplish this with focus events, but seems like it would be a nice addition to the window class itself.
-
I was really hoping this wasn't the case, I really prefer IsButtonPressed over events in a lot of cases
What the Input class did was very simple: setting a boolean on ButtonPressed event, and clearing it on ButtonREleased event. Then IsButtonPressed simply returns the value of the boolean.
Is there any possibility of a window.IsFocused at any point in the future?
It is a possibility, indeed.
-
It is a possibility, indeed.
That would be excellent.
Thanks for the quick response btw. :)
-
I was really hoping this wasn't the case, I really prefer IsButtonPressed over events in a lot of cases.
That was also my fear in this post (http://www.sfml-dev.org/forum/viewtopic.php?p=34496#34496). I currently use focus events to enable/disable global input states depending on whether the window is active.
I use a more high-level event-handling system anyway (the one in my library), so the user is relieved from doing this manually. I would recommend to abstract the "input enabled/disabled" logic away, too ;)
By the way, is it "focused" or "focussed"? Seems like both forms exist, which one is more widely used?
-
By the way, is it "focused" or "focussed"? Seems like both forms exist, which one is more widely used?
I've personally never seen 'focussed', and Firefox spell check apparently hasn't either.
According to Wiktionary 'focussed' is a UK alternate spelling.
-
Hello
I'm just trying SFML 2 in .net since yesterday.
First, this is a great engine, really easy to use.
Dealing with the inputs, i have just figured out that a mouse move event is triggered on a mouse clicked, even if the mouse didn't move.
Is it a intended (and quite surprising) behavior ?
-
This would be very surprising... Can you show your code?
-
Sure.
Imports SFML.Graphics
Imports SFML.Window
Public Class SFMLPanel
Inherits Panel
'the SFML window
Protected WithEvents RenderWindow As RenderWindow
''' <summary>
''' Constructor
''' </summary>
''' <remarks></remarks>
Public Sub New()
MyBase.New()
'init
Me.SetStyle(ControlStyles.UserPaint Or ControlStyles.AllPaintingInWmPaint Or ControlStyles.Opaque, True)
RenderWindow = New RenderWindow(Me.Handle)
End Sub
Protected Overrides Sub OnPaint(ByVal e As System.Windows.Forms.PaintEventArgs)
'clear
RenderWindow.Clear()
MyBase.OnPaint(e)
RenderWindow.DispatchEvents()
'render
RenderWindow.Display()
'next iteration
Application.DoEvents()
Me.Invalidate()
End Sub
Protected Overrides Sub OnResize(ByVal eventargs As System.EventArgs)
MyBase.OnResize(eventargs)
'update view
RenderWindow.SetView(New View(New FloatRect(0, 0, Me.Width, Me.Height)))
End Sub
Private Sub RenderWindow_MouseMoved(ByVal sender As Object, ByVal e As SFML.Window.MouseMoveEventArgs) _
Handles RenderWindow.MouseMoved
Debug.WriteLine("Mouse moved " + e.X.ToString + " ; " + e.Y.ToString)
End Sub
Private Sub RenderWindow_MouseButtonPressed(ByVal sender As Object, ByVal e As SFML.Window.MouseButtonEventArgs) _
Handles RenderWindow.MouseButtonPressed
Debug.WriteLine("Mouse clicked")
Me.Focus()
End Sub
End Class
And this panel is only docked in my main form :
Public Class Form1
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Dim renderPanel As New SFMLPanel
SplitContainer1.Panel1.Controls.Add(renderPanel)
renderPanel.Dock = DockStyle.Fill
End Sub
End Class
-
Hey Laurent
Did you manage to reproduce the behaviour ?
-
I haven't tested it yet, sorry.
-
Are there any plans for a way to determine if a window has focus? (Aside from hooking the events)
The events work, but not perfect...
On application start I either have to assume the window is focused, or assume it is not.
It is possible for an application to start without focus. For example, if your application starts while the Start Menu is open or if the user launched the game from a dock application installed (RocketDock, StarDock, etc).
When this happens LostFocus isn't raised so my game logic believes the window is focused, when in fact, it is not.
Minimal example of how I'm determining if the window is focused.
bool isFocused = true;
window.GainedFocus += (s, e) => isFocused = true;
window.LostFocus += (s, e) => isFocused = false;
if (isFocused)
{
// Handle Keyboard/Mouse Input
}
-
Yep, focus handling will probably be improved in the future. As you found, it's not perfect.