I have an issue where you have to press the page UP/Down keys 2x before the Ultratexteditor will scroll. The code calls the PreformAction method the first time and that method returns true but the editor does not move until you call the code a second time, then the editor works right until you start moving in the opposite direction. When it stops and takes another call to move in the opposite direction.
I'm not sure I follow you. The up and down arrows will move the cursor up or down a line automatically. So you want to move the cursor down and also scroll the control?
What event are you using to call PerformAction?
We are Overriding ProcessCmdKey and from that we call PerformAction(FormattedLinkEditor, bool, bool) to move the editor up or down; but it takes 2 calls to start the editor moving in any direction. This is kind of annoying to our customers.
Thanks,
blair
FormattedLinkEditorAction
ProcessCmdKey
Okay, now I'm really confused. Your original post was about UltraTextEditor, but now you seem to be referring to FormatterLinkEditor.
Which controls are you using?
What is the behavior you want?
Why are you overriding ProcessCmdKey at all?
Sorry I mistyped the original post.
We are using the UltraFormattedTextEditor (UFTE). And what I want is for the control to respond to the 1st call to PerFormAction. It is not doing this. It is doing nothing and returning that it did do something. This is a bit strange. We are overriding ProcessCmdKey in our form inorder to do some custom key handling one of which is to move the UFTE Page by page either up or down.
Hi Blair,
My only guess is that the control is trying to process the original keystroke along with the PerformAction and the combination of the two is causing some kind of conflict.
But I still don't really understand what you are trying to do here or why you are doing it. The control already has bilt-in scrolling capabilty in response to the keyboard. If you want to change the keyboard behavior, there are probably better ways to do it than use ProcessCmdKey.
Well, you could handle KeyDown and set e.Handled to true. I would have though ProcessCmdKey would have a way to cancel the keystroke, also.
The problem is that we have multiple scrollable controls on the screen at the same time and have to override the behavior of some of them inorder to do the appropriate behavior. So because of this issue we found that ProcessCmdKey was the only way to make sure that we intercepted all of the key strokes and only do the actions that are appropriate. Now is there any way to tell the control to not auto process those keystrokes?