My application is using ncurses and has several windows that are continuously being updated.
In that application I have one window acting as a 'message box' (e.g. dialog) showing up when the user hits 'q', asking them if they want to shutdown. This works fine until the other windows are updated. At that point the other windows will be drawn over the dialog box making it (partly) invisible.
Calling wrefresh() on the dialog's window doesn't seem to help. How do I force the window to be on the foreground?
I had been reading manual pages all day, couldn't find anything. And of course, 5 minutes after asking my question I found the solution:
redrawwin(dialog_window);
wrefresh(dialog_window);
My dialog now stays on the foreground.
Related
I'm working on a WPF application, mostly targeted at windows 10 but it could also be run on older versions. By default, if I open the app while in tablet mode, the keyboard will open when I focus a textbox, and close when the textbox loses focus, but if I manually close the keyboard it won't open anymore (very annoying as this is a natural thing to do). I can live with that, but the problem is that the keyboard opens over my application, so the user can't see 50% of it, including most of the text boxes, which makes it hard for them to select something else to 'defocus' and close the keyboard.
If I could get some notification when they touch keyboard opens, it'd be fairly easy to have some UI code to make sure the proper things are displayed, but I can't find any way to get an event when the keyboard opens.
You can use this on Windows 10 Anniversary Edition and above to get notifications from the touch keyboard.
I have a legacy application that uses Win32 (not MFC) to create graphical screens. One of the control types we use is a combo box with the droplist style (using the new Common Controls module). We have discovered a very strange thing about this control lately.
If I start the application with a mouse click, the focus indicator on the droplist does not show! This can be done using the Start->Run dialog (click OK after filling in the program to run). This can be done using a desktop shortcut (double-click). This can be done by clicking the Go button in Visual Studio 2010 to debug the program. Our user discovered this by using a small Delphi app that acts similar to Start->Run (fill in an entry field of a program to execute, and press a Launch button). If you click the Launch button, the focus indicator is missing.
If I start the application with a keypress, the focus indicator shows! Again, Start->Run dialog (but press Enter to activate the OK button). Desktop shortcut (single click to highlight the icon, then press Enter to activate it). F5 from within Visual Studio. Even the Delphi app - if you tab to the Launch button, and press Space or Enter, our application starts and shows the focus indicator on the drop list.
I have tried to create a small MFC application with just a drop list, and have started that application in all the ways described above. However, this small application always shows the focus indicator of the drop list, regardless of how I start it.
I have examined the styles of both drop lists (on my small application, as well as my actual application). They are slightly different, but changing the style of my small MFC app to match my desktop app doesn't change the behavior. Nor does changing my desktop app to match the style of the small MFC app change the behavior of my desktop app.
I modified my desktop application to require the user to press Enter after the main window is displayed, but before any graphical controls are shown. This causes the focus indicator to now show!
I have found that, when debugging my desktop app, if I set a breakpoint after the main window is shown, but before any controls are drawn, and then press F5 to continue, the focus indicator now shows. But if I click the Go button instead, the focus indicator does not show.
It seems like interacting with the keyboard somehow causes the focus indicator to show.
Note that a drop list combo box looks like a push button with a small down-arrow on the right hand side. The focus indicator is a dashed line near the inside border of the button.
I have struggled with this issue for two days now, with no indication that I am getting closer to an answer. So any insight into what may be causing this will be much appreciated.
The first comment to the question provided a partial answer. Changing the Control Panel setting for keyboard accelerators also causes the focus indicator to show, regardless of how the application is started. However, I believe this is only a partial answer.
When the CP setting is off, keyboard accelerators are supposed to show once you have pressed the Alt key. My understand, based on the blog post that Jonathon Potter linked to, is that focus indicators should show up once the keyboard is used. Entering text into an entry field probably doesn't count as "using the keyboard", but I would expect tabbing between controls to count as such.
Also, if the CP setting is off, the behavior of my application is different, depending on whether I start the application with a mouse click or a key press.
In summary, I find the behavior inconsistent. Perhaps it is correct. I find it hard to say.
I am not even sure how to ask this question...
I have a WPF app with a main window in full screen. It launches new windows in full screen and makes them a child of the main window upon some user interactions. If the user's machine only has a single monitor this child window is supposed to be the focus until closed. However, I have found that using Windows Aero if the user hovers over my application's taskbar icon a preview of both windows appear. This in itself is not an issue except if you try to select the main window of the app nothing happens because the child window is always on top but the peek functionality gives the illusion that the user can switch to the main window and it looks like a bug.
I would like to detect which window the user is selecting and, if it is the main window, simply close the child window. Alternatively I would like Aero to stop showing multiple windows if only one will work.
Anyone had any experience with this?
I'm not sure that's the right way to say it, but what I want is to for my wpf main window to have it's own bar that will behave like a taskbar, and any children windows that will be open from the main one will be placed in that bar in a similar way like the taskbar works in windows - a rectangle showing the window name for example, on click it opens you the window, if you click minimize it will minimize it to the bar, and with some option, to get it out of the main window and move it to the real windows taskbar, with another option for putting it back in. The problem is I don't know if this is even possible, and I don't know the name of such an element, so if anyone can give me any tips I'll be really thankful.
I worked on an application years ago (.NET 3.0: first WPF release!) that did exactly that. We ran into a lot of issues getting it to work, but we were pretty successful in the end. One thing we didn't support was moving it to the Windows taskbar.
The best option would be to set an attached property on each Window. This would register a Window with your custom taskbar, so if you wanted to move the Window out of your custom bar, you'd set the property to false. Setting the property to true would add it to the collection of application windows, as well as register event handlers to track the state of the Window.
One of the major pain points for us was getting the Window animations correct. If you're not running in XP, this probably less of an issue, as the animations in Vista (or is it 7?) and above aren't really showing where a Window is going on minimize. In the end, we had to do a lot of low level Win32 (p/Invoke) work for this.
Take a look at AvalonDock and WPF MDI:
http://avalondock.codeplex.com/
http://wpfmdi.codeplex.com/
I've been working on injecting input into a WPF application. What makes this project hard is that I need to be able to inject the input into the application even though it's running in the background (i.e. another application has the input focus). Using the SendInput() function is therefore out of the question.
So far, I've got keyboard input working but am having trouble injecting mouse input.
I used Spy++ to observe the window messages that get sent to the WPF window when I physically click the mouse button. I then simply craft these same mouse messages (such as WM_LBUTTONDOWN and WM_LBUTTONUP) manually and send them explicitly to the WPF window to emulate mouse input.
Unfortunately, this doesn't work as expected (not even when I, for testing purposes, have set the WPF window as the foreground window).
I've added a button to my test WPF window which when clicked displays a message box. Injecting the appropriate mouse messages when I've manually positioned the cursor over the button doesn't cause the button to be clicked, however (i.e. the clicked event isn't fired by the WPF framework).
If I add a handler for mouse clicks on the actual dialog (the client area), that handler does get called if I position the cursor over the dialog itself and inject the same window messages as before:
this.MouseLeftButtonDown += WndMouseDown;
public void WndMouseDown(object sender, EventArgs e)
{
...
}
Strangely enough, if I change the push mode of the button to Press (i.e. it's considered clicked on mouse down rather than the default mouse up), the button clicked event is now fired when I inject the same messages as before. (It's worth mentioning that the handler from the example above correctly fires for both mouse downs and ups, so it'd seem the WPF framework does process both messages successfully.)
It seems like there are some other criteria that need to be fulfilled in order for a mouse clicked event to be fired by the WPF framework. Does anybody know how mouse input is handled internally in WPF, or why it's not interpreting my mouse up and down messages as a click on the button?
(It's worth mentioning that this approach [sending window messages] works fine on ordinary Win32 windows, such as the Start->Run dialog. The difference here is that WPF only has one physical Win32 window and the rest is WPF specific, which means all window messages go to that top-level window rather than the actual button.)
I've been searching high and low for an answer to this and would appreciate any thoughts or ideas.
I'd highly suggest going the UIAutomation route. You create an AutomationElement by window handle. Crawl to the button and invoke it. I'd just like to know how you managed to get the keyboard input working. I am currently trying to resolve the converse issue. How to get a WPF window (I've managed to get a hWnd to it via Win32 calls), to respond to virtual keyboard messages. I've logged ++spy sessions on the window in question and replicated it's input without success.
Use UI Automation to do this - trying to manually simulate input via window messages is a textbook mistake, like trying to start a land war against Russia.
Your strategy is basically sound but in order to send a message to a window owned by another process you must first register the message.
Here is an article explaining the whole business. The sample code is unfortunately in VB but I'm sure that won't stop you.