Focus Problems

0
0

Hello all,

I have an app that’s exhibiting some strange Focus/Accelerator problems.

  • If my code sets focus to the toolbar, after showing the form, then the Form’s Accelerators are still ignored, some of the time.  Not all of the time.  Sometimes it work, sometimes it doesn’t.
  • If the event handler for the ToolBar’s ButtonClick sets focus to the ToolBar, then the next time the Accelerator handler is called, I get a “Cannot implicitly convert type ‘WiseJ.Web.ToolBarButton’ to ‘WiseJ.Web.Control'” error.
  • Also, showing a Form, doesn’t give it focus.  Instead, the browser background still has focus.  So, unless focus is set to the Form, either by clicking on it, or by setting focus in the code, its Accelerators are ignored.  I know I can work around this by manually setting focus, or by adding a Desktop and moving the Accelerators to the Desktop, but I believe that the behavior is different than standard WinForms behavior.  Am I correct?

The attached code demonstrates the problems.

  •  To demonstrate the first problem, run the program and hit ctrl-P.  It should display an AlertBox, but it sometimes pops up the browser’s print dialog.  You may have to try it several times before you see the problem.
  • To demonstrate the second problem, run the program, click File, then hit ctrl-P.
  • To demonstrate the third problem, comment out the call to mainform.toolbar.Focus() in Program.cs, compile and run the code, then hit ctrl-P.

Workarounds or updates appreciated 🙂

Thanks!

David Muse

david.muse@firstworks.com

Attachment
Focus.zip
Share
  • You must to post comments
Filter
Sort by: Recently Active
0
0

Excellent!  That javascript worked for me too.  Thanks!

  • You must to post comments
0
0

Hi David,

I can reproduce but unfortunately it appears to be a bug in Firefox. The problem is not the focus, that is set correctly. Somehow after the print dialog is displayed once, FF appears to re-registers its internal handler or something like that and it handles ctrl-P before our handlers. It’s a really weird thing it does.

The only way I found to make FF behave correctly is to register the keydown event handler very early (too early for wisej) directly in Default.html. Add the script below in Document.html and FF will start acting as it should.

 

<body>
<script>

document.documentElement.addEventListener(“keydown”, function (e) {

if (e.ctrlKey) {
switch (e.keyCode) {

case 80: // Ctrl-P
e.preventDefault();
break;
}
}
})

</script>
</body>

  • You must to post comments
0
0

Ok, I found something that I can reproduce.  Maybe it’s related (I.e. fixing it will fix the other problems too).

  • run my test program with Firefox 52.0.2 (without or without commenting out mainform.toolbar.Focus())
  • hit ctrl-P
  • it should display “ctrl-P” in an AlertBox
  • click on the browser background
  • hit ctrl-P
  • it displays a print dialog
  • click anywhere in the form
  • hit ctrl-P
  • it still displays a print dialog
  • drag the form around
  • hit ctrl-P
  • it still displays a print dialog

I believe that clicking on the form, or dragging it, should set focus to the form, and the Accelerator handler should handle ctrl-P.  Correct?

I wonder if some variation of occurs, sometimes, at program startup – somehow the browser background gets focus, and then the form can never get focus.

  • You must to post comments
0
0

Aaarghhh…  There is definitely a race condition, or something 🙂

I tested problems 1 and 3 with Firefox 52.0.2 and consistently got the print dialog instead of my ctrl-P handler.  So, I installed some screen cast software and tried to get a screencast of the error.  Then, it worked correctly every time.  I thought maybe the screencast software was making the computer run slowly, and somehow that was helping, so I exited the screencast software, and it began to fail again.  Then, I tried to capture it with my phone, and it started working correctly again.  It’s like it knows when I want it to fail 🙂  Now, it works consistently.  I can’t make it fail.

I don’t know what conditions are necessary to reproduce these errors, but they definitely occur.  I just wish I could prove it.

My guess would be that sometimes the code that sets focus to the main form runs before the form fully exists, so the form doesn’t get focus.  But, of course, that’s just a guess.

I’ll keep trying…

  • You must to post comments
0
0

Thank you for the test case. This is what I found:

  1. I can only reproduce on IE, in fact on IE calling preventDefault() doesn’t stop certain system keys.
  2. Good catch! We didn’t consider that some widgets that may be the source of keyboard events if if not visually focused are not Controls on the server side, but are components. Wisej uses “lightweight” components instead of controls for toolbar buttons, tools in editors, status bar panels, etc. The common interface is IWisejComponent. We’ll have to changed the event args. Logged as WJ-8195.
  3. Cannot reproduce. The first window becomes active automatically, you can check using Form.ActiveForm == mainform. The active form automatically focuses the first control in the tabbing order. I tried your sample as-is and added a text box, and removed all controls, it always seems to work in Chrome and IE. But if you click outside of the form, the form loses the focus to the browser but it remains active. Maybe we can improve the accelerator processing to route the accelerator key to the active form also when the keydown is coming from the document element.

See screen cast of the test using your sample:

https://www.screencast.com/t/K68GplaFlK

 

  • You must to post comments
Showing 5 results
Your Answer

Please first to submit.