This project is read-only.

Window Message Hooking for Event-Driven UI

Mar 26, 2013 at 6:10 AM
Edited Mar 26, 2013 at 6:14 AM
Why?

I'm honestly curious as to why GUI/Util/Input.cs hooks into the window messaging protocol that's available only on Windows/Win32 when XNA/Monogame provides full input handling capability for every supported platform by just polling its input state?

Ruminate could still be event-driven on the user-side, just your internal code would iterate through the input state instead of catching Win32 WM messages.

The reason I ask, is now I have to rewrite all of the input-catching code to use Microsoft.Xna.Framework.Input in a polled manner, myself, for a project that's 3 weeks behind, in part due the ui toolkit not properly handling mouse-up for some unknown reason.

So, why?
Mar 26, 2013 at 7:53 AM
Edited Mar 26, 2013 at 7:56 AM
Polling based input simply does not work with keyboards especially for text entry. People are able to type at a rate of more than 60 characters a second (groupings like "ing" are pressed extremely rapid succession) and any key press that is shorter than the XNA update function gets called will not be registered. Also using the form handle takes care of a multitude of issues such as repeating characters and double clicks which are impacted by the users settings. Good luck doing doing such things with polling and taking into account the system settings.

Fortunately I can tell you exactly why "the ui toolkit not properly handling mouse-up for some unknown reason".

http://monogame.codeplex.com/workitem/7263

Note the WindowHandle property always returns a IntPtr.Zero because monogame uses an opentk window and not windows forms.

I have an alternative way to implement a very similar event driven input system that is not dependent on monogame. So check out the below. It has instructions to make the input only be picked up if the current process is active too.

http://www.codeproject.com/Articles/7294/Processing-Global-Mouse-and-Keyboard-Hooks-in-C

Anyways I never claimed to support monogame though that is what I am currently working on.
Mar 26, 2013 at 9:23 AM
Apologies for my attitude, and thanks for the quick reply. I've gone ahead and modified ruminate to operate via polling using a separate thread, while still maintaining the event-driven interface everywhere else, and I've managed a fair bit of success.

Most of my annoyance was directed at the incompatibility created by monogame, along with some distaste for my project members not pulling their weight. I really do appreciate the work done here as it allows us to actually complete the project.

Does Ruminate currently work on anything non-pc? One reason we chose to port to monogame was due to the excellent x-platform support. Keyboard input won't be particularly important for us
Mar 26, 2013 at 8:57 PM
Edited Mar 26, 2013 at 8:58 PM
No it only works with the pc currently.

In the interest on supporting monogame more broadly I am considering creating a fork that will not include widgets that rely on the text input such as the textboxes. As mentioned I think the way XNA handles keyboard input is inadequate and supporting all of the various ways phones and tablets handle their virtual/physical keyboards is not really possible as I don't even own a smart phone nor do I have that sort of time.

I personally only develop for PC and am mainly interested in expanding the library to support Linux and Mac. Neither of which should be difficult at all. However, if there is a lot of interest non pc related stuff I can focus on creating the fork that strips out the windows specific code.
Mar 26, 2013 at 9:30 PM
I've come this example, which provides an event-driven input system to monogame based projects by hooking into monogame's event polling features (on mac). When I have more time, I would like to extend ruminate to use this in a cross-platform way.

As it stands, I can create a patch within the next few days that gives moderate support to polling for input events if you'd like.
Mar 29, 2013 at 2:01 AM
Edited Mar 29, 2013 at 3:19 AM
rooly wrote:
I've come this example, which provides an event-driven input system to monogame based projects by hooking into monogame's event polling features (on mac). When I have more time, I would like to extend ruminate to use this in a cross-platform way.

As it stands, I can create a patch within the next few days that gives moderate support to polling for input events if you'd like.
Apparently a few other people have already ported the input over to mac. I am seeing if they will let me merge their code into this library.
Mar 29, 2013 at 8:00 PM
After using the latest version with support for monogame, all my current problems have now gone away.

Now I have a new problem: Text is not visible in the SingleLineTextBox, even though the value is filled properly:
uiskin = new Skin (Content.Load<Texture2D> ("uiskin"), System.IO.File.ReadAllText ("Content/uiskinmap.txt"));
uitext = Content.Load<SpriteFont> ("uifont");
...
ui = new Gui (this, uiskin, new Text (uitext, Color.White));
...
SingleLineTextBox userbox, passbox;
Widget loginpanel = new Panel (100, 100, 300, 140);
loginpanel.AddWidget (userbox = new SingleLineTextBox (50, 20, 200, 50));
loginpanel.AddWidget (passbox = new SingleLineTextBox (50, 40, 200, 50));
no input
typed "asdf"

If this happens to be an error on my part, or if you need more code to determine as much, some assistance would be appreciated
Mar 29, 2013 at 8:46 PM
I'm about to hop on the bus home but I'll look into it this evening.
Mar 31, 2013 at 6:48 AM
Actually, I managed to get around this issue by putting labels over my text boxes. This is almost beneficial actually because I get to emulate a "password" field easily.
Apr 1, 2013 at 2:18 PM
Hmm I still would like to know why it was not drawing. I was unable to duplicate the issue and the only thing I can think of is its a nesting issue messing up the clipping rectangle. If you can send me a code snippet that reproduces the issue that would be awesome though I understand that you are busy.
Apr 1, 2013 at 3:02 PM
I'll try to get you one this evening. My project setup may be the issue, I have my project building against ruminate, and ruminate building against latest monogame source.