webkit/Chromium on Windows is stealing focus

General
1

I need some ideas and help!

I have an app that is mac/windows, desktop only, but uses HTMLviewers in 3 container controls, to display various information to the user. There is an editing box (textarea), where the user enters their translation. Every time the user types, a timer fires off a thread which checks for errors in the input. If it finds one, it writes a new HTML file to one of the htmlviewers. The user can see that, and fix their entry if appropriate.

So I used the native htmlviewer for years on windows, but a while back our company switched to McAfee antivirus, and McAfee was intercepting every single page load on IE, and thus in the native htmlviewer, which made the tool very very slow for Windows users. So, I re-wrote to use the webkit plugin. Which is really Chromium. But whatever. Some of the things stopped working, I can’t remember now, maybe cancelLoad worked differently, and I could no longer intercept link clicks so I had to change the HTML to use onClick stuff. That worked out ok. But I can’t solve this problem: every time a page loads, or gets some kind of action maybe, the focus is stolen from the textarea. I tried using setfocus() in various places, but it doesn’t actually seem to do anything.

So what happens, for example, is a user types some erroneous thing, and all of a sudden they can’t type any more, because the QA check found an error, reloaded the HTMLviewer, and now the textarea doesn’t have focus.

It’s frustrating because the Mac build doesn’t work like this, and the windows native one doesn’t work like this. Any ideas for working around it?

2

[quote=181802:@Micah Bly]I need some ideas and help!

I have an app that is mac/windows, desktop only, but uses HTMLviewers in 3 container controls, to display various information to the user. There is an editing box (textarea), where the user enters their translation. Every time the user types, a timer fires off a thread which checks for errors in the input. If it finds one, it writes a new HTML file to one of the htmlviewers. The user can see that, and fix their entry if appropriate.

So I used the native htmlviewer for years on windows, but a while back our company switched to McAfee antivirus, and McAfee was intercepting every single page load on IE, and thus in the native htmlviewer, which made the tool very very slow for Windows users. So, I re-wrote to use the webkit plugin. Which is really Chromium. But whatever. Some of the things stopped working, I can’t remember now, maybe cancelLoad worked differently, and I could no longer intercept link clicks so I had to change the HTML to use onClick stuff. That worked out ok. But I can’t solve this problem: every time a page loads, or gets some kind of action maybe, the focus is stolen from the textarea. I tried using setfocus() in various places, but it doesn’t actually seem to do anything.

So what happens, for example, is a user types some erroneous thing, and all of a sudden they can’t type any more, because the QA check found an error, reloaded the HTMLviewer, and now the textarea doesn’t have focus.

It’s frustrating because the Mac build doesn’t work like this, and the windows native one doesn’t work like this. Any ideas for working around it?[/quote]

Place the HTMLViewer on a different, floating window that you position at the same place where the HTMLViewer was. It won’t be able to steal focus.

3

ha! interesting idea. But err, wouldn’t that mean my app would show 4 windows in the task bar? Or do floating windows not count on Windows in that way?

4

When it finds an error, it currently reloads the HTMLViewer with a new source… What about just changing the content of the page through JavaScript and the DOM ?

5

Normally, floating windows do not show in the task bar. You would have to specifically use a declare to have it appear there, as in https://forum.xojo.com/15551-show-floating-window-in-windows-task-bar-list

6

Thanks for the idea about js. I actually was already using that technical in a second HTMLviewer on that window, for a somewhat different purposes. I thought any change to the page was stealing focus, but indeed, it turned out to purely the page load, or possibly the page loaded event, I didn’t end up testing to find out. Problem solved! Saved my bacon!

Michel: good to know, thanks again for the suggestion.