|
|
Rank: Advanced Member
Groups: Member
Joined: 5/8/2015
Posts: 46
|
Hi,
We are seeing some strange behavior with our client application.
Our client application contains a webcontrol on it's main form and sometimes spawns new forms as required, these new forms also contain a webview (basically our web application calls a bit of javascript to open these new windows, we don't use native new window methods). The forms do not contain anything other than a webview.
Each popup is opened using Form.Show(parent) and we also explicitly set the owner of the popup to the main form.
We are seeing occasionally that clicking on the popup makes it disappear from view completely (i.e. it goes behind the main form), when you then click the main form the window re-appears!. We can't recreate the issue consistently and it seems to be totally random when this happens but I've only see it happen when the user has more than one popup open.
Our original application using the MS web browser didn't exhibit this behavior at all, we open new forms in the same manner and nothing else has changed in this regard so we've come to the conclusion (rightly or wrongly) that the webview or webcontrol is somehow intercepting / injecting window messages.
Can you confirm if you've seen this issue before and also if the browser control does anything with window messages please, like I said this problem is intermittent but happens enough for our customers to complain.
Regards,
Andy.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi, EO.WebBrowser does intercept windows messages in order to handle shortcut keys and focus. These interceptions are done on the WebControl level. If you suspect these are the root of the problem, you can use WebView directly. See here for how to use the WebView class directory: http://www.essentialobjects.com/doc/6/start/webview.aspxWhen you use WebView directly, shortcut key pressed inside the WebView will not trigger for your application. For example, if your application has a shortcut key F1 for help, then it will not be triggered if user press F1 when the focus is inside the WebView, it will function properly if the focus is outside of the WebView. To avoid this problem, you can use the WebView's ShortCuts property to re-define these shortcuts on the WebView level. If you do not want the shortcut handling but still needs the focus handling, you can use WebControl but set the WebControl's AutoProcessCmdKeys to false. Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/8/2015
Posts: 46
|
Hi Support,
We have changed the code to use WebView directly instead of associating it with a WebControl but still have this issue, also there's another issue where you switch between popups and the focus dissappears from the lastly focused element.
The steps we have taken from our original code are as follows:
1. Remove the WebControl from the form
2. Add a icture box to the form
2. On Form_Load create a web view and associate it with the window handle as in the example code (m_WebView.Create(pictureBox1.Handle);)
My next step is to remove the webview completely so we have a blank form and see if it does it (I'm guessing it won't).
Regards,
Andy.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi, In that case it probably won't have anything to do with WebView. What you have might be a timing issue on your end that can be triggered indirectly by the WebView due to the fact that the WebView would be busy initializing when your form is displayed. If you still believe that the problem is related to the WebView, you can isolate the problem into a test project and send us the test project. Once we have that we will be happy to take a look. See here for more details on how to submit a test project: http://www.essentialobjects.com/forum/test_project.aspx Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/8/2015
Posts: 46
|
Hi,
just to let you know I've submitted a test project.
Regards,
Andy.
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/8/2015
Posts: 46
|
Hi,
Digging further into this I've simplified the project (it's been emailed to yourselves).
It looks EO.WebBrowser doesn't play nicely when opened in multiple windows from a parent form.
A very simple test can be performed by creating a project with a single form and a button that opens secondary forms with itself as their owner. Each secondary form contains a web browser. When two secondary forms are opened and bringToFront() is called the problem occurs.
We need a response on this please.
Regards,
Andy.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
This is just to let you know that we have received your test project and already have a fix. We are testing our internal build to see if the fix indeed works and hopefully we can have a new build for you either today or tomorrow.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/8/2015
Posts: 46
|
That's excellent news, thank you!
Andy.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
This is just to let you know that we have posted a new build that should address this problem. Please see your private message for more details.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/8/2015
Posts: 46
|
Hi,
I just tested for this issue with the latest version of the DLL, it's still doing the same thing.
The original issue was reported to yourselves in June last year, can you please look into it as it's causing us major problems?
We are happy to demonstrate the issue and provide our code base, we just need to get it sorted. At the moment we've got round the issue buy removing all tool tips in our web application which isn't ideal.
I look forward to your response.
Regards,
Andy.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
This is just to let you know that we are still working on this issue. We are able to reproduce the problem with your original test project. So as for now we do not need anything else. We will reply again if we have an update.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/8/2015
Posts: 46
|
Hi Guys,
Any news on a fix for this issue please, our customers are complaining...?
Regards,
Andy.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
We have been working on this but we have not been able to find a reliable fix for this problem yet ---- we do not know the root of the problem since by definition an owned window should never be placed behind the owner window. So something must have upset Windows that caused this problem. Unfortunately we have not found out exactly what yet. The previous fix that appeared to work no longer works in our test environment. We did change some related code after last fix and we are restoring the related code to what is was during last fix in our next build but this issue is not resolved yet since we can still reproduce it in our test environment regardless.
Thanks!
|
|