I'm using a character application. In the first page, there is a frame f-selection where the search fields are entered. When I search for something and open some other frames in that search, then I press F10 which is for opening another frame, the new frame opens but f-selection also appears on it. I'm suspecting this code makes it pop up again:
else assign ll-lgst-key1:SENSITIVE in frame f-selection = TRUE
ll-lgst-key2:SENSITIVE in frame f-selection = FALSE
because when I comment these lines, the frame doesn't pop up. But then I can't use these fields at the first frame where I should, too. I don't know why this code is called again; but is there anything else I can do to fix this issue? I tried to write hide frame f-selection everywhere possible but it doesn't work.
That snippet of code is making "key1" of your frame sensitive. In order to be sensitive it needs to pop up...
So the issue is why is that block of code executing? You say "I don't know why this code is called again". Neither will anyone else because you have shared such a tiny little bit of the overall code. Apparently the flow of control is taking you through that block so you should work on understanding why that is. You might try using the debugger to step through the code execution or you could insert some old fashioned MESSAGE statements to get to the bottom of it.
If you want to kludge around the problem you could wrap that bit of code in conditional logic. Define and set a variable that determines the desired state of the f-selection frame and use that to control the sensitivity logic:
define variable f-shouldBeVisible as logical no-undo.
if .... then
f-shouldBeVisible = yes.
else
f-shouldBeVisible = no.
...
else
do:
if f-shouldBeVisible then
assign ll-lgst-key1:SENSITIVE in frame f-selection = TRUE
ll-lgst-key2:SENSITIVE in frame f-selection = FALSE
.
end.
Of course that looks kind of silly -- but it is just an example with grossly over-simplified logic.
OTOH if you know enough to set the variable you ought to be able to figure out why the ELSE branch is executing. But maybe it is a useful first step.
Related
I'm working on a vector layer where I have to merge all n+i [id] attributes into entity(n)[id] where entities(n+i)[id] equals the entity(n)[id], then delete all n+i entities.
All works fine but I call several times startEditing functions before commiting changes, and my question is: does calling commitChanges closes startEditing, or does it let it opened, like if it was a file descriptor or a pointer which we needed to free after the job's done?
The code is:
olayer.startEditing()
olayer.changeAttributeValue(n,id_obj,id_obj_sum,NULL,True)
olayer.commitChanges()
olayer.startEditing()
i= i-1
while i >=1:
olayer.deleteFeature(n+i)
i=i-1
olayer.commitChanges()
As you can see, we call several times olayer.startEditing, even more because all that code is in while body...
So will that spawn hordes of startEditing "pointers" or will it just continuously set the olayer editable status as "open to edition" ?
Actually the code works, but it's painfully slow, is this the reason why ?
By and large, you should not start the edit mode more than once in your layer.
You can commit at the end of all your changes to the layer, so that your modifications stay in an edit buffer in the meantime.
QgsVectorLayer.commitChanges() can let the edit mode open if you pass a False as parameter (the parameter is called stopEditing, see the docs). Like this:
# If the commit is sucessful, let the edit mode open
layer.commitChanges(False)
Also, have a look at the with edit(layer): syntax in the QGIS docs. Using such syntax you avoid starting/committing/closing the edit mode, QGIS does it for you.
with edit(layer):
# All my layer modifications here
# When this line is reached, my layer modifications are already committed.
Edit:
After doing a little more debugging I found that it doesn't work only when I start the game and have the panel/canvas that it sits on disabled. If I have the panel/canvas enabled the whole time then it redraws correctly. However, this obviously isn't a proper solution because I can't show the results before the end of the quiz. I need the panel to be disabled so that I can show it later after the end of the quiz.Is there a reason this is happening? How can I fix this?
End Edit
So I found a script on GitHub that basically creates a UI polygon. It works great in the Editor, however, I want to modify it at runtime. From everything I read all I need to do is call the method SetAllDirty() and it will update the MaskableGraphic and Redraw it. However, whenever I call it, nothing happens. SetVerticesDirty() also did not work. Can someone see where I am going wrong here.
All I am doing is calling DrawPolygon and giving it 4 sides, and passing a float[5] I modified it so that right after I finish setting up my new variables I call SetAllDirty()
Something like this:
public void DrawPolygon(int _sides, float[] _VerticesDistances)
{
sides = _sides;
VerticesDistances = _VerticesDistances;
rotation = 0;
SetAllDirty();
}
Like I said, it works fine in the editor(not runtime), and I am also getting all the values passed to the script correctly(during runtime), but it is not redrawing. As soon as I manipulate something in the inspector it will redraw to the correct shape.
The rest of the script is posted here:
https://github.com/CiaccoDavide/Unity-UI-Polygon/blob/master/UIPolygon.cs
This is the method that I call DrawPolygon from on a Manager script. I see in the log that it prints out the statement, Quiz has ended.
void EndQuiz()
{
Debug.Log("Quiz has ended.");
QuizPanel.SetActive(false);
ResultsPanel.SetActive(true);
float[] Vertices = new float[5] { score1, score2, score3, score4, score1};
resultsPolygon.DrawPolygon(4, Vertices);
}
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.
I want a form that when I set at the bottom of the z-order it stays there. I tried:
SetWindowPos(Handle,HWND_BOTTOM,Left,Top,Width,Height,SWP_NOZORDER);
and when I overlap it with some other apps it stays at the bottom as I need. However when I click on it, it rises to the top. I then tried:
SetWindowPos(Handle, HWND_BOTTOM, Left, Top, Width, Height,
SWP_NOACTIVATE or SWP_NOZORDER);
and various other switches from this website...
http://msdn.microsoft.com/en-us/library/ms633545.aspx
But it still rises to the top.
SetWindowPos sets the position of a window only when it is called, it does not establish a state. Handling WM_WINDOWPOSCHANGING is the correct way to do this:
While this message is being processed, modifying any of the values in
WINDOWPOS affects the window's new size, position, or place in the Z
order. An application can prevent changes to the window by setting or
clearing the appropriate bits in the flags member of WINDOWPOS.
type
TForm1 = class(TForm)
..
private
procedure WindowPosChanging(var Msg: TWMWindowPosMsg);
message WM_WINDOWPOSCHANGING;
end;
..
procedure TForm1.WindowPosChanging(var Msg: TWMWindowPosMsg);
begin
if Msg.WindowPos.flags and SWP_NOZORDER = 0 then
Msg.WindowPos.hwndInsertAfter := HWND_BOTTOM;
inherited;
end;
Never tried it, but you might get somewhere trapping the message WM_WINDOWPOSCHANGING, and twiddling with Z order. Could get complicated though and I personally would find it irritatingly non-standard.
A menu option equivalent to cacsade but with a z-order sort might be a better option, I mean if they clicked on it they expect to see it.
Out of instinct, I wouldn't trust that the app will always work as you expect. Other applications may have a much more strict method of forcefully bringing its self in front of yours, or vice-versa in your case, sending it to the back. For example, a timer which repeatedly sends the window to the back. Then if you have two of such apps layered, you would watch them fight each other, basically flickering back and forth. In the end, I wouldn't count on a permanent 100% solution for this because you never know what other applications might do to override yours.