Another touch issue

Hi all, I have just downloaded Grapefruit on my mobile development machine, an ASUS B121 Slate on which I run Windows 7. First thing, I ran the Projucer, and I have issues with the touchscreen.

The program is able to correctly recognize finger clicks and drags, but fails to respond to pen input: menus highlight but don't open; the tabs in the project manager on the right (Files / Config / Build) highlight their text when clicked but don't get selected; other widgets don't respond at all.

I bet that any program compiled with the new version will behave like the Projucer, I'll keep you posted as soon as I build one of my projects againts Grapefruit.

I had a very similar problem some year ago with the Comfort On-Screen Keyboard from Comfort Software (http://www.comfort-software.com/on-screen-keyboard.html); I sent them 2 different logs created with Spy++, where I clicked with the finger and with the pen, we realized there is a difference in the WM_messages received by applications in the two scenarios, and they were able to fix it. I can log the messages sent to Projucer too.

I don't think we have a machine with pen input for testing, so any clues you can throw our way would be helpful! As a test case, the introjucer's GUI is the same code as the projucer.

This is the thread i started on the Comfort Keyboard forum:

http://www.comfort-software.com/forum-t1132.html.post

The 9th message has the Spy++ logs attached, I am also attaching them here. They are the logs I created for the Comfort Keyboard issue, not the logs for the Projucer. Also, the Spy version I used at the time didn't resolve names for touch messages, they appear as Unknown...

Thanks Jules, as soon as I have Spy logs from a Projucer run I will send them!

Ok, here are 3 log files created using Spy++ version 11.00.50727 (64bits).

Each time, I clicked on a Menu Item in Projucer after activating logging in Spy: this means that Projucer is also activated by the click, since the focus was on Spy immediately before clicking on it. The logs could well be examined starting from the WM_ACTIVATEAPP message.

I used a finger, the stylus, and also a plain mouse connected to a USB port.

Hope this helps!

Hmm, don't really think that helps much.

If you can't debug it and give us some more suggested changes that help, then it'll have to wait until we have a suitable device to test with..

I didn't have time yet to rebuild my projects, or even the demo program, using the new version. I will have to deal with some Juce internals I never cared to look at, so it could take me some time, but I will surely do it! cool

Thanks!

I have built the JuceDemo and debugged it, and here is what happens:

- when touching with the finger, HWNDComponentPeer::peerWindowProc() receives 2 WM_TOUCH messages, and they are handled in HWNDComponentPeer::doTouchEvent(); they are followed by 1 WM_LBUTTONDOWN and 1 WM_LBUTTONUP; HWNDComponentPeer::doMouseDown() discards the BUTTON messages because the test isTouchEvent() gives true;

- when touching with the stylus, HWNDComponentPeer::peerWindowProc() receives only WM_LBUTTONDOWN / WM_LBUTTONUP messages, and no WM_TOUCH - but in doMouseDown() the test isTouchEvent() gives true this time too, so they are discarded.

The value returned by GetMessageExtraInfo() is the same for both TOUCH and BUTTON messages (0xff51570f)

Cheers!

Fabrizio

 

This seems to go against what stated in the MSDN page linked in the isTouchEvent() implementation sad

Maybe this might help?

http://www.petertissen.de/?p=4

Thanks.. So if we just add 0x80 in juce_win32_Windowing.cpp like this:

#ifndef MI_WP_SIGNATURE
 #define MI_WP_SIGNATURE 0xFF515780
#endif

#ifndef SIGNATURE_MASK
 #define SIGNATURE_MASK 0xFFFFFF80
#endif

..does that work for both pen and touch?

I got it working by changing the following definitions in juce_win32_Windowing.cpp:

#define MI_WP_SIGNATURE 0xFF515780 // was: 0xFF515700

#define SIGNATURE_MASK 0xFFFFFF80 // was: 0xFFFFFF00

Now, all the input methods are working on my ASUS B121 Win7 tablet (stylus, finger and mouse)!

 

EDIT: I wrote this before reading your previous reply, Jules! smiley

ok, great - thanks for the help debugging, I'll push some changes today..