I've implemented ChrisBanes' pull-to-refresh using a Stock Action Bar.
However, after the pull, the "Loading..." message appears and covers all my action bar buttons. This is great, and what I expect. However, if I touch the action bar where I know the buttons normally are, they behave just as if the buttons were there.
How can I get the 'loading...' actionbar header to consume all touch events?
How can I get the 'loading...' actionbar header to consume all touch
events?
The reason it doesn't to begin with is due to how the View is added to the Window. When PullToRefreshAttacher creates the WindowManager.LayoutParams used for calling WindowManager.addView(View, LayoutParams), it uses the flag:
WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE
Which as per the docs indicates:
Window flag: this window can never receive touch events.
So, if you want the header view to consume touch events, you'll have to modify the PullToRefreshAttacher and remove this flag.
Related
In my application when I receive an ON_WM_RBUTTONDOWN() message in a certain window I create a CMenu, populated with some items, and then displayed with TrackPopupMenu(xxx). It has no other interaction with Windows messages to be created. It defaults to accepting left clicks to select items and I can see these messages coming in when I use the mouse.
I'm trying to allow use of this context menu on a touch screen - the parent window can receive WM_GESTURENOTIFY messages (for other functionality) and in all other aspects of my app, such as other windows and dialogs, it handles touch gestures fine - Spy++ shows gesture messages and a WM_LBUTTONDOWN which gives me normal behaviour across the app. I CAN touch select menu items when this menu is opened with a physical mouse right click, with the touch input coming through as a WM_LBUTTONDOWN.
I've tried creating and displaying this menu by calling that same creation code again from a touch message, or just sending the window an ON_WM_RBUTTONDOWN() message manually after a touch, with the same flags. This is created fine and works as normal with a mouse, and as far as the app is concerned nothing is different. However, the CMenu is not receiving any touch messages at all - I get the touch-style cursor showing where I'm tapping, but nothing is being piped through to the menu.
I've tried changing from gestures to registering touch while this interaction happens and ensuring the original gesture handle is closed in case it was blocking for whatever reason.
My assumption is that Windows is doing something additional behind the scenes beyond what my app is aware of to allow these messages to be sent through, so I'm a bit stuck for a solution.
I was able to get around this issue by enabling the tablet press-and-hold gesture (it's normally disabled) which serves the purpose of being treated as a right click and having a properly interactable context menu, rather than sending the right click message myself. Works on desktop with a touch screen and a Windows tablet.
https://learn.microsoft.com/en-us/troubleshoot/developer/visualstudio/cpp/language-compilers/mfc-enable-tablet-press-and-hold-gesture
Adding
ULONG CMyView::GetGestureStatus(CPoint /*ptTouch*/) { return 0; } was what enabled this to work.
In any web browser and in the Windows file manager and in many other applications there is support for forward and backward navigation. This always (or at least most of the time) by default works with extra mouse buttons if your mouse has any.
I want to implement this in a C++ application I'm making based on WinAPI. However I wonder how one would do this? Are the mouse buttons captured "manually" in each application that has this forward/backward navigation or is there native support for it somewhere in WinAPI?
Manually capturing the buttons is probably always an option, but if there already is an existing functionality that handles this then it seems like that should be used instead. That's probably more reliable as well.
To sum up: I want my application to correctly handle/receive backward and forward clicks from a mouse that has such buttons.
The WM_APPCOMMAND message offers the APPCOMMAND_BROWSER_FORWARD ("Navigate forward") and APPCOMMAND_BROWSER_BACKWARD ("Navigate backward") navigation commands. You can handle them in your application, even if it's not a browser.
The documentation has information, how and when the WM_APPCOMMAND is generated:
DefWindowProc generates the WM_APPCOMMAND message when it processes the WM_XBUTTONUP or WM_NCXBUTTONUP message, or when the user types an application command key.
I have a legacy C++ MFC application with a complex GUI with Ribbons. I have a use case as follows : User clicks button A on a ribbon panel and does some work. After his work is done, before he can exercise the rest of the GUI controls, he absolutely must click button B on the same ribbon panel, and failing to click button B in this manner results in a crash if the user exercises some other controls.
Hence, in order to deal with this use case, I figured it would solve my problem if I could disable all of program's GUI controls in Button A's event handler except button B. Button B's event handler then enables the rest of the GUI controls. This way, I ensure that button B always gets pressed after button A.
Hence, my question to you is as follows : Is there a way to disable all GUI controls in one fell swoop, and then enable and disable controls individually?
I know how to enable or disable controls individually, but I have not yet come across an API that allows one to disable all controls.
This way, you get all IDs of the ribbon buttons:
CList<UINT, UINT>& lstItems;
CMFCRibbonBar *pRibbon = ((CMDIFrameWndEx*) AfxGetMainWnd())->GetRibbonBar();
pRibbon->GetItemIDsList(lstItems);
Put the three lines in your view's OnInitialUpdate() handler.
Then use the list to compare the IDs coming through your OnCmdMsg() handler to disable all the buttons (except button B).
I am trying to do some lengthy operation from my mainthread in dialog box. During that time i want to disable few controls. I used EnableWindow(FALSE) for each control to disable it. But apart from button control all other controls (i.e. slider control, CMFCEditBrowse Control, ComboBox control) are disabling perfectly before the processing. But the button controls are taking more time to disable. They are almost disabling when the operation is going to end. Why the button controls were not disabling as soon as i call EnableWindow(FALSE)? Why it is taking time to disable?
You need to perform the background task totally in another thread, and UI/control changes in another thread. You should use PostMessage, if direct call to EnableWindow doesn't work. SetFocus, for example, doesn't work from a different thread.
I have an application that hooks into another application via an API. My application launches a modal window which prevents keypresses to reach the parent as one would expect.
However due to limitations in the API I need to click one of the parents toolbar buttons from time to time (yes it's a kludge).
I wonder if this is possible while still having the modal window of my application active? Is it perhaps possible to send the required command directly into the parent command queue?
Clicking the button programmatically with no modal window should not be a problem, one could go by this link for example: http://forums.codeguru.com/showthread.php?307633-How-to-run-a-very-long-SQL-statement. But I would prefer not having to close my window each time I have to click the button.
Although the fifth answer is what I find interesting as I'm thinking this could make it possible to send the command without having to close my modal window first. Also it feels an ever so small bit less ugly.
First of all, when a modal dialog is shown, it runs its own message pump. So any attempt to fake input messages will land in the modal dialog message pump. Which is no good to you. So, you'd have to send a message rather than fake input.
However, when a modal dialog is shown, its owning windows are disabled. Which means that these windows will not respond to any messages you send. So I guess that means that you could:
Enable the owning top-level window that you hosts the toolbar in question.
Send the message to the toolbar button.
Disable the owning window again.
Not the prettiest way to go about things, but you did ask!