I know this might be an unusual question but is there any way to turn off this annoying popup?
I made a custom animation player which sets a different track for a custom property
i.e. if I press add key of custom_property it will add the key of position instead,
and in doing so the track of custom_property is never made, so every time I add a key of it this pops up
Oh never mind I found it,
it was in the Editor>Editor Settings...>Animation
and deselect the Confirm Insert Track
Related
I originally had code that set the focus to the first widget in a dialog, in the onInit method. But there were problems with it: if I pressed TAB, indeed focus moved to next control (wxTextCtrl), which got the blue 'focus' color, but the 'focus' color/highlight was not removed from previous focus widget. So now it looked like both first and second control had focus at the same time...
When cycling manually (by pressing TAB) full circle (till last control and then wrap around to the first), suddenly all worked well. That is, when moving focus from first control to next one, the first visually lost focus (blue color was removed) as it should. From now on, only one item had the focus color/highlight.
So instead of setting focus on the first control, I tried a different approach: I set the focus to the last control in the dialog, which is always the OK button. Next, I want to emulate programmatically that a TAB is pressed and received by the dialog. So I wrote this (inside Dialog::onInit):
m_buttonOK->SetFocus();
wxKeyEvent key;
key.SetEventObject(this);
key.SetEventType(wxEVT_CHAR);
key.m_keyCode=WXK_TAB;
ProcessWindowEvent(key);
Now the focus indeed moves away from the OK button, but it does not wrap around to the first control.
Only when I manually press TAB after the dialog opened, the first item gets focus.
Question: why does this wrapping around to set focus on first widget not work with the code shown above?
First of all, your initial problem is almost certainly related to not calling event.Skip() in one of your event handlers, see the note in wxFocusEvent documentation.
Second, you can't send wx events to the native windows, they don't know anything about it. In this particular case you can use wxWindow::Navigate() to do what you want, but generally speaking what you're doing simple can't, and won't, work reliably.
I am SwapMouseButton function to change the primary mouse button from right to left.
It seems work, the mouse buttons are swapped, and I can go check in the settings and see that they are indeed swapped...
BUT,
If I reboot the computer, the setting goes back to the original setting, undoing my programmatic swap.
Any clue as to what might be going wrong there?
Swapping the mouse buttons via code is not a permanent operation. As you have already discovered, it is reset on the next OS restart. If the user wants the buttons swapped permanently, they should be setting that in the Control Panel, not in your code.
That said, if you really want to handle this in code, then every time your app is run, have it use GetSystemMetrics(SM_SWAPBUTTON) to check if the mouse buttons are currently swapped, and if not then swap them.
So I have looked through existing answers tagged with dockpanel-suite and have not found what I am looking for (as I type this, it is also not appearing in the Similar Questions area). For starters, note that I am NOT asking about saving and restoring the entire Workspace.
So here is the scenario. I have a graphical window (we will call it "Timeline") that is added upon user request. When it is added, it is automatically docked to the bottom-most area of the main form. The user then takes the Timeline window and redocks it somewhere else (could be docked to an edge, or within another docking pane) and changes its docking behavior (floating, auto-hide, tab, etc.).
A demonstrable example is in Visual Studio. If you have the Solution Explorer on a tab within an docked pane on the right and close Solution Explorer, you can go to View -> Solution Explorer and bring it back up again, and it restores to the correct location.
Now the user closes the Timeline window entirely by hitting the [x] on its pane, and in the future, they request to add it to the application again. I want to bring it back in the last dock state and position it was in when it was last closed.
Now, I appear to be able to catch the closing of the pane with the ContentRemoved event, but in there e.Content.DockHandler.Pane, e.Content.DockHandler.PanelPane and e.Content.DockHandler.FloatPane are all null so I have no obvious way to get the previous dock geometry. e.Content.DockHandler.DockPanel is valid, but it is the parent/root docking panel, and calling SaveAsXml(...) does nothing for me because it would get the entire workspace.
Even if I were able to capture it here, information I need. However, I do not appear to be able to simply call LoadFromXml(...) on anything either.
If I try to do it before the DockContent object is added to the DockPanel, DockHandler.DockPanel member is null, so I appear to have no place to restore the XML into, even if I was able to get it.
There are no other events hanging off of DockPanel that seem to be able to help me here.
So - is there a way to do this, and what is the correct way to do it? I want to make sure I am not barking up the wrong tree with trying to capture the dock information as XML when closed and restore it later.
I have toyed with the idea of not actually closing the window but just undocking and hiding it, but have not explored that very far yet. Same with hooking the DockChanged event, but it does not seem to fire on the DockContent objects being docked/floated/etc. and I am not sure why.
Also the solution needs to be robust enough so that I can correctly handle scenarios such as if the last docking parent no longer exists. For example, if it was docked as a tab somewhere, but now that parent window (containing the tabs) has also been closed. I do not know if LoadFromXml, presuming it is the right way to do, is robust enough to handle this scenario, as I have not been able to test it yet.
If I understand the question, what I do is to trap the Closing or FormClosing event, .Hide() the form and set e.Cancel = true. If you are using DockContent, then there is a HideOnClose() that does the work for you. Then when you want to "re-open" the window, you simply use an empty .Show(), and it will Show right where it was when you "closed" it.
As far as saving if the last docking parent no longer exists, I agree with Lex Li, that will take a hack.
I have an audio recording application for Windows Phone. It consists of a pivot control with two pivot items. One is for recording control, and another one is for reviewing and listening the recorded items.
When the recording is taking place, I need the way to prevent the user from navigating away from the current pivot item, but to retain the feel that an entire pivot item moves, but doesn't flip to the next item, as if there is none.
I know I could use GestureListener from Silverlight Toolkit, but using it I will need to implement a simulation of pivot movement myself.
Is there a build-in way to prevent pivot navigation?
If no, can you point me to an example on how I can animate control movement on gesture flipping?
Is it mandatory that the user has to remain on the one PivotItem?. If not, you could just disable the second PivotItem so that the user knows that it's there, but can't actually interact with it.
secondPivotItem.IsEnabled = false;
Alternatively, you could dynamically insert the second PivotItem when you want it and remove it when you don't. For example, when recording:
mainPivot.Items.Remove(secondPivotItem);
then when you want the second PivotItem to appear:
mainPivot.Items.Add(secondPivotItem);
The only "problem" with this is that when you only have one PivotItem on screen, the user can't scroll. However, this is how a Pivot control is supposed to function.
If you really want the user to scroll back to itself, you could create a blank PivotItem (with no header). Then, handle the Pivot's LoadingPivotItem event. Check if the item that it about to be loaded is the blank one. If so, then use Pivot.SelectedItem = recordingPivotItem to navigate back to the recording PivotItem. You can then use the above method to dynamically add the second PivotItem when the recording is over. This isn't the normal UX for pivots, but should do what you're trying to achieve.
Seems to me that the best solution is making the pivot control invisible to hit test altogether. I simply set PivotMain.IsHitTestVisible = false and set it back to true whenever I am done recording.
There is a good attached property approach on how to make a particular element hit test visible, while casting an entire panorama or pivot item hit test invisible:
Here is the link to a blog post of an author with the source code:
http://blogs.msdn.com/b/luc/archive/2010/11/22/preventing-the-pivot-or-panorama-controls-from-scrolling.aspx
Works for me until the dynamic loading and removing of the pivot items with textblock header will be added to the SDK's pivot control.
The down side of locking a person into a pivotitem or disabling one so that a person cannot navigate is that you are going to frustrate the user. PivotItems are meant to be flicked to and from, and writing an app that has behavior different than this is going to take away from the user experience, because the app is not going to behave the way they expect it to.
Personally, if you are going to lock them into one pivot item, I think you should go ahead and create another page without a Pivot control and navigate to it. Also, whether you choose to do it this way or not, you need to keep in mind that regardless of whether they are locked into a certain pivotitem or they are navigated to another page, the back button must work as expected, or the app won't pass certification.
It's a longshot that anyone can help with this, but here goes. I inherited a VB6 app with a Janus GridEX control. It iterates through records, and is editable. Problem is, if I edit a cell and hit the button to go to the next record, the change is applied to the next record, not the one I was editing. It's like, I need it to finish up the edit before going to the next record. I've had this sort of problem before in VC++, and sometimes you have to "KillFocus" on the control you're on or something. I just don't know what to do here. I tried sending a carriage return, since if you return out of the edit cell, it works, but sending a carriage return manually doesn't work. What's the secret?
Is your grid bound or unbound?
It's hard to tell from your description, but I imagine that if your are having this problem then it's probably bound.
As the other answer asked, is the button the RecordNavigator that is built into the control or is it a separate button? The reason I bring this up again, is that I have seen issues in the VB6 applications I support where a toolbar will often intercept and interfere with how the JanusGrid should work.
To get around this limitation, I have added the following code in the click handler of any toolbars where there is also a JanusGrid control on the form.
If jsgxYourGridName.EditMode = jgexEditModeOn Then jsgxYourGridName.Update
This way any changes are immediately applied to the current row.
If this does not help, then I have also seen problems where the recordset that is bound to the grid gets out of sync with the internal recordset in the grid. You can check this by comparing the bookmark of the grid to the bookmark of the recordset.
Ie. mrsYourRecordset.Bookmark = jsgxYourGrid.ADORecordset.Bookmark
At one point I may have also used something like this.
jsgxYourGrid.ADORecordset.Bookmark = jsgxYourGrid.RowBookmark(jsgxYourGrid.RowIndex(jsgxYourGrid.Row))
Finally you can try setting a breakpoint in the BeforeUpdate, RowColChange and/or AfterColUpdate events of the grid, to see what record the grid is really on when clicking on the button.
It depends whether the button is internal to Janus GridEX or not. If it internal then just about the only thing you can do is look at the events the control exposes to see if there a sequence that can let you know that this problem occurs. Then you can try to take corrective action by restoring the row you moved to and put the edit in the row you left.
If the button is external to Janus then you can use the debug mode to trace sequence of statement that control the transfer of focus to the next row. It could be something out of order or a side effect of the particular sequence of commands. I have run into both with different controls.
Remember that you can edit while in debug mode so you can try different approaches and test until you find one that works.