HAL_Button need to be pressed twice

I have some problems with HAL_Buttons. Sometimes I need to press them twice to be activated, but not always. What can make this behavior? I might have overlooked something in the manual or some setting in Glade, but what?
You can see it here at 3:20

Regards
Henrik

Might want to attach a sample of your hal config with info on the button that needs to be hit twice.

Rick G

I don't think it can be anything in HAL config, as for example, my probe touch off Z button sometimes need to be pressed twice. And that button is just executing a MDI command that calls a O-sub. Anyhow, I attached my compete config, the most interesting parts regarding this would be in the GladeVCP ui file. Appreciate any help.

/Henrik

I think I've seen this too, with different configs - I dont think the config makes a difference

if anybody wants to look into it: a good start would be tracing the event and update functions around here, and the base class: git.mah.priv.at/gitweb/emc2-dev.git/blob.../hal_widgets.py#l109

- Michael

Are you hitting the button from Manual or MDI mode? and are the results the same?
I have had in the past O-sub calls from a joypad (I believe ones with MSG) in them that worked in MDI mode but not Manual mode.

Rick G

Good to know i'm not the only one

Some more info, the button press signal is detected by the python handler, but no further when the error occur. I know this as I set a signal handler on the "pressed" event in glade and print some debug info to console from python handler.

Rick, you can be onto something here, I would not say never, but I have not get the error to occur in MDI mode (testing ~50 presses), going back to manual mode, after 5 tries or so the event was not catched by linuxcnc (but in python).

thinking a bit more before posting..

this might very well one of the problems incurred by embedding a gladevcp panel into Axis

the background is that the Axis support code (Tkinter) does not play well with embedded windows which use the 'Xembed' spec, as gladevcp does - there are numerous workarounds which had to be done to get this work at all, in particular issues with focus and event forwarding

to triage this, run the gladevcp panel outside Axis, i.e. do NOT embed it

if the behaviour changes, then this is a strong hint the above situation is a cause

see also: www.linuxcnc.org/docs/devel/html/gui/gla...key_handling_in_axis
the full uglyness can be found here: git.mah.priv.at/gitweb/emc2-dev.git/blob...n/gladevcp/xembed.py

This code addresses key events and 'focus stealing' by Gtk which hides key events from the parent window, which is not a good idea e.g. for the e-stop key - if you were doing input in Gtk input field and pressed the estop key it wouldnt be forwarded to the parent (Axis) window.

Given the fact that Tkinter development is de facto dead in the water, there isnt really much hope other than patching around or using non-Tkinter apps like Screen

- Michael

Thank you for your input. Unfortunately, runnig the glade panel outside Axis does not help the situation. Have tested it now and if anything, it's worse. From time to time now, I getin console where I started Axis. After this message, next press on button is ignored. Sometimes the button gets stuck with a bluish color till next time I press it. I also get missed pressed without the above message.

Another thing to track this down is that when the button works, I first get my message (in console) from the python handler, then a "Emit interp-run". When it misses the press, I get my python message, but not the "Emit interp-run" message. Might shed some light on the issue.

Yes, I have read the key-focus thing, and have had a couple of "WHHHHAAAAAAAAT THE H**L!!!" moments where the router has moved after I released the cursor keys.

Oh, tested now with my separate glade window. To activate the probe button, it starts to probe, change focus to axis window and press esc. The probing stops as expected. But next time i hit the probe button, the press is missed.

I don't know how you mean with using screen. But maybe a complete own GUI with Glade (no Axis) would solve those kind of problems?

/Henrik

I think we need to make clear what we are talking about here.

What I had assumed so far is that there is an issue with the HAL button widget per se, and my comments pertain to that.

A completely different thing is any actions associated with that widget, and whether they succeed or fail.

please explain.

- Michael

I posted my config earlier in the thread. I have a gladevcp panel with a z touch off button. This button calls a Mdi_action in glade. This mdi action is in turn calling a O-word routine with my touch off program. I have also defined a signal handler for the "pressed" event in glade editor. This event is handled by the python code and just makes a debug print to the console that the button is pressed.

when pressing the button, sometimes my o-word is not executed, but the debug message from python handler is.

Are we talking about the same thing now?