I am working on a UWP component that relies on Window.Current.Activated event to check whether the window is focused or not. On some apps using this component the technique does not work. Anyone got any ideas on how Window.Current.Activated might not be raised?
Related
We have addEventListener and removeEventListener.
Why we don't have getEventListeners?
Is this because of security reasons?
What will happen if listeners can be found in page context script?
I am trying to write a puppeteer script to trigger a div click event.
But I want to make sure there is an event listener on click-event before clicking it.
And I found that it is very difficult to check if a div has a event listener.
The puppeteer document tells me that to use DOMDebugger.getEventListeners in Devtools Protocol to achieve this.
I was wondering why the browser is designed like this.
Would you please help me to resolve "Blocked Pop-up Window" problem ?
When I submit our app to AppSource, we get following failure message from partner center.
Customer Control 1100.5.4.2 Blocked Pop-Up Window
Pop-up windows triggered by user interaction must not be blocked by browser pop-up blockers on their default settings. A pop-up blocked appears in the browsers when we click on the "insert" button within your add-in. Please update the offer to correct pop-up window behavior and re-submit your offer.
This is happened when our app calls displayReplyAllForm by user interaction. How can I resolve this problem technically ?
Because of following investigation, IMO, Office team should handle this problem.
In general, I should call window.open directly from user-interaction for avoiding popup blocker.
For detecting and handle popup blocker, I can utilize returned value from window.open.
But, I can't do this because window.open or something popup logic is wrapped in displayReplyAllForm. So, I think it should be handled by Office team.
My suggestion is that Office team provide promptBeforeOpen option for displayReplyAllForm. I can avoid popup blocker with promptBeforeOpen when I use Dialog API, and want to use it in other functions provided by Office.js.
Microsoft product team has repro the issue and has added this to their backlog. Let's wait they'll fix the problem and we can avoid bad UX in the future.
https://github.com/OfficeDev/office-js/issues/1377#issuecomment-690049886
Now I'm developing windows phone 8.1 app with WinRT
I'm trying to support swipe-right-to-go-back gesture in my app.
I try to capture the manipulation events on my page. My page's root is a grid and have a ListView inside. I used the UIElement.AddHandler method with "handledEventsToo=true" to add the event handlers. But when I touch the screen, only the ManipulationStarting event is fired, other events seems to be eat by listview.
Could anyone tell me about the manipulation event behavior or other methods to implement this feature? Thanks!!
You won't normally capture events on LisView, beacause it has a ScrollViewer which intercepts them.
There is a way to do it - you will have to disable ScrollViewer and then perfrom some actions when the events are fired and perform scrolling manually. This answer will guide you.
In case someone encounters this page, I spent the better part of a week figuring out why manipulation events were only firing half the time on my UWP charts using the winRT xaml toolkit.
You may need to check that the background is not null on whatever element has the event handler attached. Templated controls are not necessarily hit test visible unless they have one. Otherwise, the input can go right through to the element behind it.
https://msdn.microsoft.com/en-us/windows/uwp/xaml-platform/events-and-routed-events-overview
I'm developing an app that needs to generate mouse events on a window Win32/WPF which may be minimized or hidden from view on the desktop.
I have tried the user32.dll APIs SendInput, SendMessage, PostMessage etc. These work only if the window is visible on the desktop. Would you know about any methods that work for hidden/inactive windows?
I've also tried .NET's UI Automation library. In this case, a window is brought to the front or I'm not able to get a clickable point for the control.
Any ideas how I can proceed? If I can proceed?
I don't know if you're still interested in an answer (I just stumbled upon this question out of sheer dumb luck), but have you tried making a global windows hook?
I have no honest idea on how to properly go about implementing one; but I know you should be able to add a global windows hook to, well, Windows, to listen for whatever events you want (should include mouse and keyboard events!)
Good luck...
in a former thread ( Adding a user interface to an image viewer plugin ) I have got some good insight on how to add GUI controls to a firebreath plugin. Taxilian pointed out that when I use a windowed plugin under Windows it should be straighforward. Basically like developing any other Windows App.
Now, to make sure I understand correctly. I'm suppose to create a child window from the window handle supplied by the onWindowAttached event. To create such a child window I need to register such windows class with ::RegisterClassEx(...) to have my own Window Procedure. Is that correct? I mean how else would get access to WM_COMMAND events?
Once that is done I need to ::CreateWindowEx(...) my child window with the hwnd from the plugin.
Is that the right way of thinking?
Thanks ahead,
Christian
Actually creating a child window is optional; WM_COMMAND events for your actual plugin window will be delivered encapsulated in a WindowsEvent that you can catch the same way you get an AttachedEvent. All windows events are sent that way.
Another option is to do what you describe and register a new class with a WINPROC and create a child window. The main reason for doing that would be that you might be able to more easily interact with an abstraction like wxWidgets, etc because it will not know what FireBreath is to get events from it that way. Either method should work fine.