Window key press function and Slider confliction

Hello, I need to use arrow key to move the crosshair in the figure. This function (crosshair moving) works well in GUIDE and app designer. However, the window key press function behaves differently between app designer and GUIDE.

Let's say I have some buttons, a slider, and an axes/uiaxes in the window. The slider is used to control the gamma of the image.

In GUIDE, when the slider is focused and pressing arrow key, it won't trigger the WindowKeyPressFcn, which means the slider moves (so the gamma changes), but the crosshair in the figure (axes1) doesn't move.

However, in app designer, when the slider is focused, pressing arrow key will trigger both the slider and Window key press function. This results in both gamma changing and crosshair moveing. I don't want such behavior.

Is there a way to make this function behave the same as in the GUIDE?

[dpb]

The WindowKeyPressFcn callback receives a KeyData object as the second argument. event.Source is the handle of the object that had focus when the key was pressed so you can identify when it is the slider is in focus and prevent the crosshair from moving when the left/right arrow keys are pressed.

You might also submit this to Mathworks as an official support request about alternate behavior at <Product Support Page> and see if there might be more sophisticated technique or if Mathworks would consider an enhancement to be able to control the WindowKeyPress callback with more granularity. Indeed, it seems like perfectly reasonable behavior desired..

[Tianlun Yu]

Thank you for the suggestion. However, I tried to see what is event.Source, but it doesn't return me the slider. Whatever is focused, the event.Source in WindowKeyPressFcn is:

h =

Figure (MATLAB App) with properties:

Number: []

Name: 'MATLAB App'

Color: [0.9608 0.9608 0.9608]

Position: [1119 394 960 720]

Units: 'pixels'

I paused the code from the first line, and what I observed is that, the slider moved first, and after that the app paused and returned to the code view window. It seems that, the arrow key triggering the slider takes pirority of the WindowKeyPressFcn.

I'm raising a ticket to the support.

[dpb]

Well that sucks...not much help or even point in that, is there?

[Tianlun Yu]

Well I got the reply from Matlab team. Your idea is correct, but the code is not entirely correct. The current focused component should be called by "event.Source.CurrentObject" instead of "event.Source". One more step down...

[dpb]

OK, thanks. I didn't see any reference in the documentation that there were additional fields; think that would be worth submitting as documentation enhancement. Of course if one is in the debugger one can go poking and would be able to see it, but would have to think of that being what had been done with no prior hints.

Answer 1

[Oliver Jaehrig]

Here you can find some information of my response in the TS case which should clarify this issue:

As far as I see the callback works as documented:

https://mathworks.com/help/matlab/ref/matlab.ui.figure.html#buiwuyk-1-WindowKeyPressFcn

"This callback function executes when the user presses a key while the figure or a child component has focus. If the user presses multiple keys at approximately the same time, MATLAB detects all the keys."

So when there is not a KeyPressFcn on the component level (here the uislider object),

I recommend to do something as follows:

Do an early return in the WindowKeyPressFcn callback by checking if the CurrentObject property of the uifigure shows that it is a slider object and then return.

This will solve that the code gets executed which should not run when a slider is focused.

Here you can find an example:

function UIFigureWindowKeyPress(app, event)
currentObj = event.Source.CurrentObject;
if class(currentObj) == "matlab.ui.control.Slider"
    return
end
%will not run when a Slider is current object
key = event.Key;
disp(key)
end

[dpb]

"...callback works as documented:"

Where in the documentation are the subfields of the event.Source field documented (or is it even mentioned there is/are subfields)?

While I pointed OP to this as being the way to determine in order to solve his issue, from the documentation I expected that event.Source would have the ID of the actual control.

As is so often the case, there's no example showing the use and what examples are shown are utterly trivial so without documentation pointing out how to get the real component ID, the only way for a new user would be to going poking at the object in the debugger on their own. That's a stretch...

[Oliver Jaehrig]

@dpb Thank you for your feedback. The comment you cited was more about me writing when the callback actually executes and not when talking about our documentation and the Source property.

Sorry for the confusion.

I agree that the documentation of event.Source can be improved and I forwarded your feedback to our development team to review this documentation to check if it should be improved in a future release.

If you have any further feedback, please let me know.

[dpb]

" the documentation of event.Source can be improved and I forwarded your feedback to our development team to review this documentation to check if it should be improved in a future release."

My additional comment would be the use of "if" in the above... <g>

IMO, doc isn't complete until there is a link to all objects referenced showing all detail as well as use examples more on the order of @Tianlun Yu's situation in this case. This isn't trivial and does seem convoluted in comparison to GUIDE behavior presuming (as I have little/no doubt) the actual triggering of the callbacks is as described.

As far as the point whether the comment was focused on when the callback executes, the code only works if one knows a priori how to get the actual component reference and that's where my prior response fell short because I had no way to know had to look at a field lower than the top level since it would seem the "source" of the callback would have been the slider.

I don't build complex GUIs; my MATLAB use is exclusively for processing of data I collect for my own use or in support of clients for which I prepare final reports rather than providing tools for the same so I don't have direct experience in such depth despite 30+ years w/ MATLAB. I also have not delved into R2025 as there's little there that matters for my purposes -- while perhaps a disadvantage in Answers in that don't have the environment locally to experiment with, it gives me the advantage that if I can't figure it out from the documentation alone, then other users aren't likely to be able to, either.

ADDENDUM

I guess I do have another comment after all... <g>

The extra logic and finding out which control is the culprit is needed in the window keypress callback because "... there is not a KeyPressFcn on the component level ..."

My comment here then is why is the uislider matlab.ui.control.Slider class hamstrung by not having an event callback thus forcing such code branching logic? This would get very convoluted very quickly and extremely difficult to code/debug it would seem if there are a number of controls in an app with these kinds of interactions.