I tried using Window's ButtonDown event as well as Grid's ButtonDown (all window elements are inside this grid). However, these events never seem to fire.
Where, logically, should the code for handling button down events (as to implement hotkeys) be in a WinRT application?
I thought someone recently blogged about this, but I can't find the post right now. You can check these articles though: MSDN link, link.
Basically you would handle Window.Current.CoreWindow.KeyDown/Up, store the current state of the modifier keys (Ctrl, Alt, Shift) and respond to combinations to handle them. Then you should also specify accessibility and help strings like these on your controls:
ToolTipService.ToolTip="Shortcut key: Ctrl+P"
AutomationProperties.AcceleratorKey="Control P"
Related
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.
This is more of a best practices question rater than something technical.
I'm working on a mobile app using the Flex 4.5 SDK and I'm trying to figure out the best way to handle notification windows. In most cases these windows will be alerting the user to when something goes wrong. Ex: bad login, no data, cannot resolve server.
I'm using a singleton design pattern, I have a Requests class that handles server calls. Most popups will be originating from this class (IOErrorEvents from my loader being used to access the API). Since this class is a singleton and is used from all Views inside the app it is not aware of applications current view. I'm also not sure having this class keep track of the current view and having it push popups on top of it would be best practice.
I'm hoping that I can use PopUpManager to keep track of where to add popups and what popups are currently on the stage. Though all examples I've seen online about this show static Components being used in a views Declarations tag.
I'm really just looking for any examples or input on how you would solve this problem. Any help would be greatly appreciated!
I had the same problem, and sorted it by making an Alert popup component that you can call from anywhere in the code base, and it will pop up in the currently active window. It also has an always visible scrollbar text area which is handy
http://bbishop.org/blog/?p=502
It works for a view navigator application, but if your using a tabbed navigator application, you can add a call for that, or simply change the code to
mainTabbedNavigator = FlexGlobals.topLevelApplication.tabbedNavigator;
currentTab = mainTabbedNavigator.selectedNavigator as ViewNavigator;
Is there a way to listen to layout engine events ? , something like "finished_rendering_element" or something of that sort ? , i.e. : i want to be informed when a div with an id of "mydiv" has been rendered ? i could do that by including a settimout in the top of the page and testing the dom and execute approximately at the time it is avaliable but i was wondering if there is a better way ?
I am not aware of any JavaScript interfaces or events on this level being exposed by any browser.
And probably rightly so: I can hardly think of scenarios where such fine-grained event control would make real-world sense.
It is possible to place <script> tags after an element:
<a id="my_link">Link</a>
<script>....</script>
you can safely assume that the a element is available to you in the script.
Other than that, you are left with the DOMReady and load events.
In an Access (2002 / 2003) data-bound form, a turn of the mousewheel moves to the next/previous record, even if the cursor is inside a multiline text field or a listbox. This is a major annoyance to users and cannot be turned off easily.
I recently discovered a DLL called MouseHook (http://www.lebans.com/mousewheelonoff.htm) which can effectively block this mousewheel behavior and replace it with more expected behavior.
However, when an external ActiveX control is added to an Access form, this module does nothing. For example, I have a form with a FlexGrid control on it, and it can contain a lot of rows. When a user tries to scroll in there using the mousewheel, Access again simply goes to another record instead, even with MouseHook DLL loaded.
Is there a solution like MouseHook DLL but which also works for external ActiveX controls? Or is the source code of the MouseHook DLL available so it can be modified to deal with controls like FlexGrid?
PS: I wanted to ask the author of MouseHook DLL, but he is currently "on a hiatus" until June 2009.
If you really have to alter the UI and change how the user expects the mouse wheel to work, I would actually recommend just disabling it rather than altering how it scrolls. While it's scrolling may seem odd to you, it is how the program works. What would you do if you had to read PDF's all day, and then one day one person decided that the way the mouse wheel scrolling worked wasn't good enough and changed to so it defaulted to huge jumps or horizontal or whatever. Yes, it may have been a better solution, however it is annoying to the user because it doesn't do what it is supposed to do.
Why are you using a flexgrid in Access? To me, this is a read flag that you likely are approaching the project with an Access-hostile point of view, since you seem to be choosing non-native controls to do things that are almost always much more easily accomplished with Access's native controls.
Hook the flexgrid, intercept the WM_MOUSEWHEEL message, ignore it and call your intended behaviour.
Not a direct answer to your question, but the way we deal with the mouse wheel movement is to prevent accidental changes of records after the user has started editing. When the user opens the form, the wheel moves the records willy-nilly as normal. As soon the user edits something on the field, and then moves the mouse wheel, the BeforeUpdate event fires, which causes our code to put up a prompt saying they must save the record first. We have a save button which the user must explicitly press to supress the warning in the BeforeUpdate event.