1-The code below displays the properties of the pressed key.Try it by pressing a key and observe the results.
figure('Name','Press keys to put event data in Command Window',...
'KeyPressFcn',#(obj,evt)disp(evt));
you will see outputs like this( e.g upon pressing space bar)
Character: ' '
Modifier: {1x0 cell}
Key: 'space'
2-Now simply add the following line of code to above ( or simply execute it before clearing the workspace)
cameratoolbar('SetMode','orbit');
Now press any key and nothing happens! the control will no longer be transferred to your costume call back function! ( here:#(obj,evt)disp(evt)).
same thing happens for WindowButtonDownFcn, WindowButtonUpFcn too.
How can I get around this? I wanna be able to handle KeyPressFcn or WindowButtonDownFcn after executing cameratoolbar('SetMode','orbit').
I found the answer: Once the cameratoolbar('SetMode','orbit') is called one of these two happens:the handle to the figure is lost or the event handler gets its default value. I am not sure which one though. Therefore we can add the following code to re-assign the lost handler back to our own call back function:
set(gcf,'KeyPressFcn',#(obj,evt)disp(evt))
Related
I'm linking an arcade button connected to a USB encoder with a Max patch. The button is behaving strangely. Here's what happens:
I have the button mapped to the a key. When Max is open, this functionality breaks. Even outside of Max. Even once I close Max, I need to remap the key. I'm not using MAME or anything like that; just JoytoKey for the mapping.
This issue is negated partially through use of the HIobject. Max recognizes the button and I can use it, however it's not functioning as an on/off. Rather a bang is sent on button press and release. How do I make the button work normally (send a single bang on press, and none on release)?
Here's my patch, if it helps. I don't know how useful it is without my video files:
<pre><code>
----------begin_max5_patcher----------
2245.3oc6cszbjpaEdsmpl+CTr1gB8hGYY1jJYaRVMUptvzx1ZtzPGdX6I2J
+2i3YyCoF0.M8hqbMi6FjP5b9zQe5bPvw+92+1Sluj7EMyz3Oa7Cimd524m4
opyUdlmZOwSlmB9JLJHqphlEmnwElO2TzGAowAmnBJIt3DKNhlWcUf1ydNHk
W8bZ5AZbvKQzAExxomp6j+JMllxBMLL9W+i+hgweO4WY4rveyvneymTj219n
tl3X00m7xO+S.+tJWWy7eclVqqlr3bymMLq9uw+9hvkG9NK9sCozv75Zhv9V
DhM+G.B.P1Pf+yF.Hwxl+gKn7CHzx9RajE7A83gf77T1KE4zKeKqATaQ0RrK
pfl7Z646JnOJEkD+lX.dP0NwGhJqhsnBydOIMWgFge9SM3ib7uSSGbosPKro
r+22+V82Z+Rym7OdVYKsSzrrf2ncih4zuxaJPlcFTr4APj4AQt4wBrIbsKsE
P9WrHVrdGS+jKfSU62YyL4ZnRCEnzH45bDKKegyG78rP9k+f7g1HnC.xw.d8
taHwOY4VexhOl7ow4nfeUJ5GYYm6p34TZFMNOHmkDeHhESCSJhyGPTLnJWzO
Hvxydj5g8qFacvk+lX2e19MMNzuKkZUBskOD8RP7ayODAvdkPuCeTojjBh1.
SxH1GTqJ3WDw+zRkft.WGqJCEWaWejKDa6H15AWg0.Rer9TxQZeNNy7zf3LV
KZBWwBOqY.C3cEdj4GrVChbOWqYxXpv0a.yudy0andq4vEQPIfw+DtmKyHij
IiFYPlyhF54Nkv.BpWL.O08.UVs5lr+bwqkuPUU3t.v9lKBY5C.j0B.XfqkM
4AA.dqG.bVK.f7.ON.vctoXBc4XWmh4tZ.VQU3t.vNyBv.eKzCkCya0.rhpv
1GKh+pCDg3uz.Qv1tUNYSpiCcK73Vpd5sd8zcwAbwcRxdmzSEni.R.8EAPpL
+frhPUw6lEhB7L1RFFueHGZwHG.sa1by6koqmkCtLJAOO9uID281BDrTbDx8
sPEQ+drz2rgix65p.sFHaMVoKDVuoE9vvUGruhpvcwyB7r1sDQC96nmEXvpi
NRQU3t.vnYAX.4ACvq91UopJbW.X3rTDdXKviDfQ9qlhPQU3t.vfYAXBxxy+
QBvqN3CUUgECvuFkTdaxl8lq5VuqTv16S8UwtqdmQ6tGquljdJnpCb1Brlb8
6UZEdOy8KUlRt4luoAwGSNY.rUE3qcpwwYYFs2j+XH702aSkvvox616Z67tH
fcEvNsit1hVtqsbyOv8z0Von5B8KXGQU3huoFPf28MfAon5BcFXOQ0EeKT.d
tOHa0E5Avdhp3EipDGkD8Eipkazc6NbO+xPB16ZTIWe0ONDhCAX6iJcJoZqg
Qd27dYitosF8JVqbE6.2whT1WsOGNGYgkMVP5uVf2VXazT0j.br7KOGDh4.B
1Ai4CHt98U5njDtpbNIMefVbLHOXxdnFFwN28vRMXSTexL3krjnhbJWfeuB.
9aw4oIG9mexdKH8TFz5TxGW1.TteUrHZ2VjpPc+MVbMvxKiQKOS+ZTpEC2NV
tzlDmyGgNjwGjnc66aegtZX4bQd6Fqyw1da6ZcwGZER9XVgK101FgvXyg06H
qYObAOOtIJoAJRoCZFDFU0LvQMSoVPqUyeXXOpKRC9LOYxjxdZwgltR3kmy3
7SgAQMk5XOp7ORhZz.qQkTjQOlkew7arbMnrmK+2TPnTwNmv8KK6PFMrwDpx
0U6wcWvwfy4BGLRaFFEHiGKR6lHNQBOmb4Yj3GS6vRjYnTMr7vjHdH.cVHlA
ou8h4zlPXW+ZYfEWlcMo7vfv24cN6+1d4Vf5Iw17kprA.GAh5oLgMUPQdBmO
gEJsT97fTwHKeHNKMT5PbQL6+THQAOKC13C1zzyBundVCcJyyBgttmZoqzFx
ZfgDaBafdHxnRGBGRrpuvDIbVIM9MVbmUyGuZ1rL3fmaitkCmiNkUQQVdHkO
Hec5TEpqlNUSmpoS0zoZ5zRJRvMPmBzzoZ5TMcplNUSmNlNMHH8LRApTo0SS
ipoQ0znZZTMMJTQZTcv8ZZTMMplFUSiJjFEnHMpNndMMplFUSipoQmPi1tq7
pPkd05poS0zoZ5TMc5eToSG9PNYftgmHJC8cKUSnpIT0DpZBUo6gO5F1CeMc
plNUSmpoS+CCcZaASSSX0snYYNBbbdPs5cOHpoG58BZjkTjF11sco.tdJn4Q
ZVNKt2Dlt2YOiq9xfndORTpC2t9yUk9qJ2EtU8nuYeygqqgcYHP1w9lrXDYZ
ZsBPpRQmHjS86.Y+i7qR4GnxyMIEWhr1FEChUBJcuplAbbDj0GpyRN.Gjjx1
F42cKjeemouien5zroP4uprsQ982.4GB8l91zsOxORIweLizH4WnINe5a06s
FBTm2P6ejWc1mzywBONYUVVzkNJI8HMsxQwMRWmkC.3uYjNpgsiLf5zX6sPB
.ag0Iez8AM6BoD6FhrcCYpsRnmjwLu8SDjY13tah.1VhH3reh.PhHP1OQ.JQ
D72MQvEKQDv6mHPtmrXpIBNRDAv9IBtRDA39IBxnlPagHnTfIvsKvDjRdWAm
y6PjfL.QclzQnmiUksIx+XJRIxu+LdGRDjqEZyDPdRJaajek7eXrWFikeGfb
4WjuEan7CuECVY1ObeVmlUFvMQGIJxI7VEcDYS7eyG7nhtff1.4GAgV6mDS1
BIlfq+q2wtHwaQDzHOxNhwaQLyUYY88RhcUJNDxL7f9tBRpzM7f90I4kgGUy
wHb961ww3pjEO45qQggNBxH40ZSyH0nip0s9GsMZiiRZyLyF3FNxzFT88tXz
Q0ZSyrnMTaTZt8XNKUt6LsxO4h1rMRrRtHRPyv36I3OgDMRLr+Lk1iZv+5UJ
Di+M2Z9fym+fll0HO0Jh4ofelTG.+y0GyhqOtNwEZlR+f0dI0ItPyfzv2Y4z
v1cvy7Kml79T0eYYRiKXsAeTBkkccUdXpbeEyNGTCZU4qou+MdE9+qypUK.
-----------end_max5_patcher-----------
</code></pre>
It's hard to give an exact answer without knowing what your USB device outputs, however in your patch whatever exits the [hi] object goes into the [live.text] button, which is set to Button mode, always converting it to a bang.
In the patch below I set the [live.text] button to Toggle mode. I also took the liberty of cleaning some other things up.
The next thing though is that you will need to find out what part of the output of the hi object is the information you are looking for. You can do that with a [print] object. Then you can select that number with an [unpack] and select the 1's and use that to trigger [random] (see the patch below).
----------begin_max5_patcher----------
1559.3oc6Z0ziiZCF9bxuBDmmF4O3ypdpWpZu11SqVE4P7Lw6BXpwjYFsZ+u
WaCjPBDvIgY6glLRCAaiseedd+zjusbg6F9azRWme14SNKV7skKVXZR2vhl6
W3lQdKIkTZFlaBOKilKceptOI8Moo8ew4YV9VG4NpSdU1FpvgkatKkUJUegH
cJekIS1QKc1PkuRo4N.Gh5QfsyUgfVplZhjwyWmxxoI7pbyriZFgZlY4oToY
q.aZjs0rA3a9xOAAtGGIuR1NTP6JPTa.V9KqEzDYsTiBvq.O4.AlKXXj9BBr
B37Y8y78kK0+6IKQmb5qp8QOvoPvNBYSIDwWuLfTadef5CDCgX.BFeThPFAB
MuBTUdAI4qJBT8msxUzvxEto05ljuWPqEJWCjcxEmOeYL.FFrJV+IDDFiCQd
f.EFfhWgMshiQ.LJ.hdxIL7tPjKa.jriyKo055M1.6nBps3S3Mq6hA8kRTTv
GglbIM8nA6IRDpuD4MrDgtDiugj+hlqGknQ.+AH5HCoh89HT1kNrAcQ0U4CZ
V3HCenT57a2EVx8ngQJ3.Ka21GzlYbvynUfqAJX7GCbAsDt7CuQ3B9CFt.Gz
qtC3pR41npciumHxIYz9cvjzr5w+azbpfk33372+4u537G72KkLkSWGacn.O
DIofHTKljJVSyIaRocefqya7jlmP.nu4oxAkVcqg16xzkj8zsqIRofsoRRO9
sxFjrAJ0HVZEk+bayssepvUk0rcA5MJ7vN8jgkxyeYPv+jQkoHuN3zI8UtiK
jSOEsvGptKi9R6kqT4IiVVRdg1yXqqpyTtig9ia1ziyG21P48v+7jNB75GIB
+g3kYGyVy.7UFERmv5zp4CktwPReWuaymz+Elb0qp7s4u5TjRdWuk2xJKlNS
Z73dlQvUQfy3TuXi0afwGnW703lFAFG6s1QskYFX7VG3aT3fH7co2kx1SWY.
7AbY2qyKFoa.0j3n9pId0Aj8uFzEFYi+cofjWxZQXz7vG2XVZCYfLfj+QETP
MZndmqthrHzv4j7MFdXzoYFCQLRF6.6Kw9RJxJ6HC0EFEo9uuen1qFDbLAN7
E0cGpx.z+ANFPgAyPQBOqzQTZTSY2GVmwiIkQePu7ddlKxHlAGXaXL+wr1Ay
mcsARsAN8vmKbymVqxo0VdlCDXIP6aRsLHnGPOklH16GasDHsmtS2o2.poi+
2F32hhs5ESGqgMym.e+.eHHFqMLLG9ENBzA+R47htxs9dAsP4f6rhHFOVU30
q7hmfA1JHuJ4lkv8RjhBmVqryDr2ZKdYKKQOQDw6GYK0iUTIWqU9pDzoNzkl
ZBCF.A8gpv851PHOEV6E34oc6zMmosDI47nXIorhCGBa2vXKbIaJ4opHepMx
Nin964RAe8e8J6EhHqDsJiu+PbEkaEVJ8PfmoG5WUoPVWFAeOipaoy.ZnuJP
jNKe+Pbm9NSqvHD7bohlVWpXJ5g.xcjktLV2hKpCjySaTWOhUlNDMyV+dR3o
Jmn7ssbMQ7xlSmzpb1+T0z8oOqxXkJJNzSaGMgeasDmfJXF7UeKUUX9nTwzC
0JpHvSqc4G8fJFkJf1SEvakJhBLTQ7CpXPpfPDE3oogKMLqn.jef18K3AEbQ
J.YGEbyNj7hMT.7AEbQJ.ZGEbyNhv.sin.zCJXPJnM8GKngwFpcwDPFqA7Cp
XzjVcv1m0pyMGcvGqq5Iv6AYLZtRX6yU5lohvProNo+eQEMMdxY4YlBW8Auc
1O5FSgl51Osn+RdkHoc607xLb5TLIsTxxOTY7mN7CHoyX3hsTgol1AOmAaW3
H0jBmXgMmHsykNQi4TDiFVDg20B6YwBi8lAI7.NM5RMGqDxh0Qe1L28BoOP2
I0OPyA1YgDglKAZRnaNT28sQWXNDIrUJ39yjI7jNKN0MUFaaAW4TswuHLdnW
bVP+WeTj+pPuabb0+9WfPvJu3A55d0Tis.EvygIQnMpp52E68uT1nr1WlpC6
QJJ1SEkMC1rFtYjuvMttidxbKKu9VyAv5Jn6YsiutEhHYGSRSZOnV22BpO.e
WcbbQdEqINfR5VpOYURYoNclxBRsfXNX8kee4+Jwi4ZG
-----------end_max5_patcher-----------
There is data validation in my MS Word user form which returns the focus to the textbox where the user entered something incorrect. Now I am trying to accommodate the user's change of mind: instead of correcting the entry, I want him to be able to exit the form (click the Exit command button), in which case the entry would be discarded. I suppose that a solution would start with not using the text box's exit event. I little help from someone who knows the answer would save me a lot of testing time, perhaps to find out that I can't do it.
Does anyone know?
I understand that you are handling the Exit event of the Textbox, setting the Cancel output parameter if the data is not valid.
There's a tricky but simple solution that permits to keep that working and still have an Exit button. It permits to activate the handler of the Exit button without requiring the focus to leave the Textbox. This way you can unload the Form safely in this handler.
Try this it works pretty smoothly:
1- Set the property TakeFocusOnClick of the Exit command button to False. You can do that at design time in the property-sheet, or at run-time i.e. at UserForm_Activate
2- just unload the form when the Exit button is clicked:
Private Sub ExitButton_Click()
Unload Me
End Sub
#A.S.H provided the key to the solution below. His point is that it is possible to call another event procedure while Cancel is active in the Exit procedure of a control. That other procedure can be used to rectify the condition in the first control which is triggering the Cancel, thereby enabling an orderly exit. The all-enabling condition is that the control on whose click event the rectifying procedure is to run must not take the focus when clicked (meaning it can run without triggering an exit from the control stuck on Cancel). I have added code to the exit procedure to set CmdExit.TakeFocusOnClick = False when a Cancel condition arises there. Now, ...
Private Sub CmdExit_Click()
' 12 May 2017
' if CmdExit can't take the focus it can't be the ActiveControl
If Not ActiveControl Is CmdExit Then
Select Case ActiveControl.Name
Case "Cbx107"
Cbx107.Value = ""
Case "Tbx53"
Tbx53.Value = "0"
End Select
With CmdExit
If Not .TakeFocusOnClick Then
.TakeFocusOnClick = True
.SetFocus
End If
End With
End If
' now CmdExit is the ActiveControl
MsgMe "Cmd Exit: ActiveControl = " & ActiveControl.Name
Me.Hide
End Sub
The issue that I am having is that I am attempting to execute a HoverStylingCommand by calling:
natTable.doCommand(new HoverStylingCommand(natTable, columnIndex, rowIndex, hoverLayer);
and the HoverStylingCommandHandler that is registered by the HoverLayer is never being triggered when the command is executed. However the handler does get hit when the exact same command is triggered from the SimpleHoverStylingBinding.
It doesn't make sense to execute the HoverStylingCommand programmatically. It is intended to operate in combination with the mouse cursor position. IIRC the command handler performs a check on the mouse cursor position. So from the functional point of view it is correct that the command handler is not triggered.
I am working on some modifications to EEGlab's eegplot function (things like vim-style navigation etc.) that need to work through WindowKeyPressFcn.
However, the callback is not being called for some reason. I have been debugging the issue for some time and am a bit lost. I am looking for suggestions on what might be wrong. Unfortunatelly the eegplot function is big, complex and somewhat convoluted and I was unable to reproduce the issue in a simple example. Therefore I am looking for general suggestions on why a function handle that is clearly present in WindowKeyPressFcn might stop being used at some point.
Here is what I have learned so far:
If I go to debug mode in eegplot (set a breakpoint near the end of the setup function [the first half of eegplot]) I am able to run the WindowKeyPressFcn at least once.
However - the function stops being called at some point during debug (sometimes even after being called only once).
If I run eegplot without debug (that is wait for it to finish and return control to me) I am unable to call WindowKeyPressFcn by pressing a key. The function handle is still present in WindowKeyPressFcn property of the figure.
Whener the WindowKeyPressFcn is not being used when I press a key, I can still call it with:
figh = gcf;
fun = get(figh, 'WindowKeyPressFcn');
ev.Key = 'rightarrow';
ev.Character = ' ';
ev.Modifier = [];
feval(fun, figh, ev);
So the function handle is 'healthy' so to speak, but for some reason it is not being used any more when a key is pressed and the figure has focus. When and why something like this could happen? Any ideas on things I should check to understand this issue?
Update:
I found out that WindowKeyPressFcn callback can sometimes be blocked by some window listeners, and tried out the following solution:
hManager = uigetmodemanager(gcf);
set(hManager.WindowListenerHandles,'Enable','off');
It doesn't work - WindowKeyPressFcn is still not called when I press a key. :(
Update 2:
Another thing that does not work:
chld = get(gcf, 'Children');
tp = get(chld, 'type');
chld = chld(strcmp(tp, 'uicontrol'));
set(chld, 'KeyPressFcn', #eegplot_readkey_new)
(eegplot_readkey_new is the function I use for reacting to keypresses)
Update 3:
And another one not working:
addlistener(gcf, 'WindowKeyPress', #eegplot_readkey_new);
Ok - I fiugred it out, although the solution is weird to say the least.
For some mysterious reason using linesmoothing undocummented property prevents WindowKeyPressFcn from being called. I have absolutely no idea why...
My code is really too long to be posted here, even by little portions. So I will just ask for one or two things :
It appears to me that when modifying the 'Data' property of an uitable 'ht' :
set(ht, 'Data', something);
that the "cellSelectionCallback" routine is triggered (as the selection is very likely to have changed, indeed), but not immediatly after the dataset is modified.
Is this true ?
Is there any way to prevent such a behavoir ?
Thanks !
I have code using a uitable, e.g:
tbl = uitable('Parent', fh, 'CellSelectionCallback',{#cell_select_callback fh});
I did a quick experiment and when using set(tbl,'Data',my_data) the callback is triggered only if the set causes the selected cell(s) to change, and this happens immediately (as far as I can tell - I saw no appreciable delay).
To stop that happening you could just unset the CellSelectionCallback property, change the data, and then reset CellSelectionCallback.
I had the same issue. Was getting index out of bounds warnings. To get rid of those I used this in my CallSelectionCallback:
if ~isempty(eventdata.Indices)
// all the code
end
When the set command triggers the CallSelectionCallback the eventdata.Indices is empty.
A similar possibility to Sebastien's answer is to put this in your cellselectioncallback function:
function output = mycellselection(source,event)
if isempty(event.Indixes)
output = [];
return
end
% rest of your code for cell selection
end
If you don't have any output needed, you can just remove it. I just put it in there to remind you that you have to assign a value to any outputs.