|
|
Rank: Advanced Member
Groups: Member
Joined: 2/11/2015
Posts: 122
|
On another note, you might consider looking at the tunneling part of hte WPF event model.
With Tunneling events you setup aPreview handlers to handle the event, allowing your application to capture the event before it makes it to the control its destined for.
Then the WebView, if it received the event through tunneling, could bubble the event back up the tree, this is an event conversion.
For example;
Left clicking on the WebView causes a Tunneling event on the host Window, PreviewLeftMouseButtonDown, which is invoked on each element it passes through on its way to the WebView.
The WebView would traditionally invoke this preview event as well.
Once WebView fires its PreviewMouseLeftButtonDown event, it would Raise a RoutedEvent for a MouseLeftButtonDown, which would bubble back up the tree.
This provides the opportunity for applications to handle the event before it hits the WebView, while still allowing normal Bubbling to occur.
This setup prevents the issues with ListBoxItem and ScrollViewer consuming events before they hit the WebView, as they handle Bubbled events, but are not handling Preview events.
This is also exactly how the WPF Event model is setup.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,221
|
Thanks for the information. I am certain this issue and the TextInput issue you reported are related and we will try to resolve them together. Give us some time to dig into this thoroughly and we will post here again when we have an update. We may need additional test code/project from you through the process, in that case we will contact you again.
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/11/2015
Posts: 122
|
I've provided more that enough work for you, however if you want to reach out to me personally, I'm willing to contract out additional work for your company.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,221
|
Hi,
We do not have this kind of contract relationship with our customers. We would always focus on resolving the issues for our customers as fast as possible. The information you provided to us will help us resolving the issues faster thus would benefit everyone. The alternative would be waiting until we find/catch the problem ourselves, or somehow it is brought to our attention by other users. Most of the time it will eventually get resolved but it will take longer. Because of this, we see this as you and us working together to resolve the issue for you faster and more effectively, not as "you have provided work for us". We can not offer financial incentive for this process because then we could run into issues where users may decide to intentionally withhold important information from us in the hope of "selling" such information to us. So we do not do that.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/11/2015
Posts: 122
|
It's fine that you don't have this contract relationship with your customers. Your update claimed to bring EO closer the WPF event model, a VERY simple analysis showed this to be false.
This suggests to me that no one bothered to actually verify they implemented the model correctly, or worse, put in a lazy hack and failed to evaluate the implications of that lazy hack.
This issue arises from a distinct lack of practical and methodological development practices to design, implement, test and verify that changes result in the expectations layed out.
In this case that lack of effort has resulted in a significant design failure being released as a major version to your customers which will inevitably lead to unexpected behavior in your users products.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,221
|
There is no doubt that issues can slip through our test process, or even we can make design errors. Our license agreement explicitly stated that there is no guarantee of any kind. In many cases, there is no clear right or wrong on the way things are implemented, which way is better and more convenient would emerge over time based on customers feedback. This is what we are trying to do. We try to listen to our customers, and address an issue as soon as it is brought to our attention.
In essence, we will do our best to work with you if you work with us. We will not tolerate any kind of finger pointing or "you should have done this" kind of approach because this will not help resolving the issue. So if you continue to take this approach against us, not only it won't help anybody, but you will be shown the door very quickly. The refund offer we mentioned early still stand. I hope this makes our position clear enough to you.
We have temporarily suspended your forum post permission until we have an update on this issue. We see no point of keeping arguing while the focus should be resolving the issue itself. If you wish us to proceed with the refund, please contact us through our contact page. Your post permission will be restored after we have an update build for this issue.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,221
|
Hi, This is just to let you know that we have posted a new build that should resolve this issue. And as promised, we have resumed your posting permission. We apologize for having been "aggressive" with you during our past discussion. Our primary goal is to keep the focus and effort on resolving the issue themselves other than getting into any kind of non-productive finger pointing/arguments with our customers. Our commitment to you have always been that we will try to resolve any issues brought to us as quickly as we can and will continue to do so. We have thoroughly reviewed this issue and I feel our current implementation should address most of these issues. The key points of the new implementation are: 1. Events model for the host application and the web page are NOT combined. As you originally mentioned, nobody would want the hosting application's event model to be extended into the web page. This is correct. WPF event handling must remain WPF way and web page event handling must remain the web page's way. We implement this by clearly dividing event handling into different stages and maintain their own original semantic in each of these stages. You can find more details here: https://www.essentialobjects.com/doc/webbrowser/advanced/input_events.aspx2. While hosting application events always occur before web page events (this is necessary to both simplify the event processing flow and make it easier for our users to use and understand), for WPF only the preview events can actually "consume" an event. Bubbling event while technically still occurs before it reaches the web page, logically it is treated as if they occurred after the web page has already processed the event. Thus marking the event as handled in bubbling stage will not prevent the event from reaching the web page. Previous version allows both previewing and bubbling event to consume the event. This was the primary cause of the original mouse button down issue; 3. An additional IInputMsgFilter interface has been added to allow you to further customize the above event flow; We understand that there might still be issues and maybe even design flaws. We will continue working with you to our best ability. Your past posts have helped us greatly both in understanding and resolving these issues and they are much appreciated. In the future if you have any feedback they are always welcome and will be highly appreciated. We have also resolved other issues you reported. We will reply each issue separately. You can download the new build from our download page. Thanks!
|
|