Oddity with touch-driven mouse events

wxPython Users
1

Please accept my advance apologies if it is bad form to repost my unanswered mailing list question here.

…

I’ve been working on a front-end for an automated vendor, which runs on the raspberry pi 4 and a 10.5" touchscreen from Eyoyo. All the hardware seems to perform flawlessly.

The piece of the front end I’m working on provides an opportunity to capture a signature from the end-user, which is to be made on the touchscreen.

I’ve been working from the very excellent ‘doodle.py’ at https://wxpython.org/presentations/OSCON2006/examples/doodle.py. This code works fine, but see additional detail.

I’ve stripped it down a little (I don’t need the menus, and also need only one brush size and color), and integrated it, and it seems to be trying to work, but…

…that’s not actually the issue, but rather an observation I’ve made while troubleshooting my own code:

I added a bit of instrumentation, of the most basic sort; a simple ‘print()’ method call to display the name of all callable methods in the script. I’ve done this to both my code and the doodle code, in the interest of a parallel trace to track down the issues in my own code.

What I’m seeing is the event callback method for ‘wx.EVT_SIZE’ being called repeatedly.

The problem is, no resizing of the window is taking place.

Either I’m missing something here, or that event should not be firing.

Does anyone have any ideas? This could possibly impinge on the issue I’m having, as it is not possible to resize the window in question, and so I have no such bindings or event callback methods in my script.

Does anyone have an idea what’s going on? tangential but peripheral question: does my code need such a callback method stubbed out with a ‘pass’ statement?

Thanks in advance, and stay safe out there!

Cheers,

James

ADDENDUM:
This morning I added the wx.EVT_SIZE binding and event callback method from doodle.py into my own code, and now it no longer renders the widgets in the frame (or out of it, afaict). Interestingly my code is also firing wx.EVT_SIZE, which makes no sense as my window style precludes any sizing of the window whatsoever.

2

Adding the event handler and corresponding bind did other things as well: when I attempted to make marks in the drawing area within my dialog, various exceptions were thrown. These were due to some ham-handedness on my part pursuant to integrating the doodle.py workflow into my dialog window.

Correcting the first of these got me a new, similar error, but does permit me to make marks in the drawing area. Unfortunately, the remainder of the widgets in the dialog still do not render.

If I disable the event callback method and corresponding bind, the other widgets render, but the signature/doodle piece stops working at all. I should perhaps note for you all that the window hosting the doodle-like operation is a modal window, class derived from wx.Dialog.

Cheers,

3

…and finally, if I disable all functionality in the wx.EVT_SIZE handler, leaving it a stub with nothing but the identifying print() instrumentation: everything still works fine.

Why is the size event firing at all? why does it have no immediately appreciable impact on the running code if the associated event callback method does literally nothing?

EDIT: it feels a lot like I’m going through the motions of supporting an event I’m not using in the interest of somehow appeasing the widget library.

Cheers,
James

4

If you can, please reduce your code to a small sample application that shows the problem and share it here.

5

Hi Robin, thanks for your reply. I think we can answer the most fundamental of my questions (why does the event ‘wx.EVT_SIZE’ fire when the window has not been resized) with an examination of doodle.py.

If I can get that question answered, it will provide much clarity for me about what is transpiring in my own application.

Thanks again for the reply :slight_smile:

Cheers

6

So an unmodified doodle.py has the constant sizing problem? It doesn’t for me on any of my testing platforms.

Which version of wxPython are you using? Is the value of event.GetSize() in the EVT_SIZE handler changing between events? Is there a window manager running in this environment? If so, can you test it with a different one?

Also, if you’re using wxPython4 then there is an updated version of doodle.py at https://github.com/wxWidgets/Phoenix/tree/master/samples/doodle

7

So an unmodified doodle.py has the constant sizing problem?

I don’t know that I would call it a sizing problem, as resizing the window is not something that ever happens. Only the event happens.

Which version of wxPython are you using?

wxPython 4.0.6 on raspbian as of a few months ago

Is the value of event.GetSize() in the EVT_SIZE handler changing between events?

This is an excellent question, for which I’ve yet to obtain an answer (because I hadn’t actually thought of it ;))

Is there a window manager running in this environment?

Indeed there is. It is the typical raspian openbox derivative. I hadn’t thought it useful to test on a different desktop environment as doodle.py does work – it just exhibits this odd behaviour with the size event, and if I strip it of size event methodology completely, it should break, according to what I’m seeing elsewhere.

Also, if you’re using wxPython4 then there is an updated version of doodle.py at Phoenix/samples/doodle at master · wxWidgets/Phoenix · GitHub

This is good to know. I will compare the new one to the old and see if this sheds any light on the topic.

Here’s a link to the doodle code I’m currently running:
doodle.py with instrumentation

ALSO Thanks for your help Robin :slight_smile:

8

concerning the github/newer doodle.py, that one seems to be the one I have, as it is line for line the same as that which I started with :wink:

9

:frowning: my pastebin got removed, dangit…

10

Well, I’d categorize a constant stream of size events with no actual size changes as a problem. :smiley:

But like I said, I don’t see it here, so I expect that it has something to do with that particular runtime environment.

11

Well, I’d categorize a constant stream of size events with no actual size changes as a problem. :smiley:

But like I said, I don’t see it here, so I expect that it has something to do with that particular runtime environment.

Not a constant stream - and they are intermixed with mostly wx.EVT_IDLE events.

After init() I get a call to SetColour, then Notify, then MankeMenu, then InitBuffer and one to DrawLines – after that, a wx.IDLE, followed by three wx.EVT_SIZE, then a wx.EVT_IDLE, InitBuffer and DrawLines again, followed by four wx.EVT_IDLE, two wx.SIZE, an wx.EVT_PAINT… and then I start drawing and the wx.EVT_SIZE events stop.

I apologize for not being able to show you code. Idk what happened with pastebin; the code I’m working on is a couple hops away on a different machine and is difficult at best to get to this window for pasting.