Having problems popping a UIMenuController when using multiple (side by side) windows.
So I handle a tap in a view then I set the firstResponder to that view, then I present a UIMenuController in that view and the canPerformAction: is called on that view - all good!
I then attempt the same in the adjacent window (same code obviously) and the canPerformAction: is still sent to the previous view (in the other window.) Indeed, pressing the menu also results in the handler being called on the other view.
Both views return YES from canBecomeFirstRepsonder:
Anyone got any ideas?
Thanks
Turns out you need to call [view.window makeKeyWindow] prior to calling [view becomeFirstResponder] prior to presenting the UIMenuController.
Makes sense I guess...
Related
When dealing with login screens, I am trying to work out the better approach - either execute navigation "action" to go to login fragment on first use (and hide back button to actual app), or start a new login activity (with its own nav graph). For the first approach (just using navigation components), I do not know the way to remove the back button without a hack "hide". I tried using navoptions, setpopupto etc., but it does not work. Code below:
val navOptions = NavOptions.Builder()
.setPopUpTo(R.id.home_fragment, true)
.build()
host?.navController?.navigate(R.id.action_global_signUpFragment_dest, null, navOptions)
Two questions then:
1) How to properly handle login transition with just navigation component?
2) Is starting a new login activity, with separate nav graph, a better idea?
I think the first approach is better.
To hide the 'back' button on your toolbar inside signUpFragment you can use AppBarConfiguration, and customize which destinations are considered top-level destinations.
For example:
val appBarConfiguration = AppBarConfiguration.Builder(setOf(R.id.home_fragment, R.id.signUpFragment_dest)).build()
NavigationUI.setupWithNavController(toolbar, navController, appBarConfiguration)
This way home_fragment and signUpFragment_dest will be considered top-level destinations, and won't have back button on toolbar.
Another option for solving the back button problem is how I did it here. Also, rather than show/hide the bottom nav bar, I have two NavHostFragment, one main full screen one, and one contained within the home fragment (above the bottom nav bar).
When I want to navigate to a full screen view I call this extension function,
fun Fragment.findMainNavController(): NavController =
Navigation.findNavController(activity!!, R.id.nav_host_fragment)
then navigate via the main graph.
This makes sense conceptually to me, to have parent and child nav graphs.
I have an MFC MDI application, in which it is possible for documents to have multiple views, and for users to customise and then save layout data for the views. This data is associated with the views, not the documents.
I would like to prompt the users to save if they choose to close a view with unsaved layout changes, and am running into problems, as it seems MFC is only geared towards changes in the document. Here are some approaches I've tried:
Override CDocument::SaveModified function, which gets called by the framework when a document is closed. In this function, I send a message to all the document's views, which can then check for unsaved changes and prompt the user.
Perform the check inside the View's destructor.
Perform the check inside the View's OnClose handler
Each of these approaches has problems. (1) is the best, but it fails to deal with cases where there are several views onto one document, and the user closes one of the views. As the document is still open, SaveModified is not called.
The problem with (2) is that on application shutdown, the application has already disappeard by the time any CView destrutors are called. This can leave an orphan dialog box open on the desktop. This is also the case if I try performing the check inside OnDestroy.
I can't get (3) to work - I can't get my views to respond to WM_CLOSE.
Currently, my best solution is to do both (1) and (2), but this requires some smelly logic to prevent the app from prompting the user to save view changes twice on app shutdown.
Anyone know of a better way of doing this? Where is the correct place to hook in?
I'm not sure if it is your solution, but I have several views that can not close on condition and I handle them in DestroyWindow( ). And a message box there does come up over the app before it closes down. So try using DestroyWindow( ) rather than the destructor.
Concur.
ON_WM_DESTROY()
afx_msg void OnDestroy();
does the trick. It will not prevent the window from closing, but the question didn't request it.
I need to make multiple enable/disable changes to a main menu in a C++ Builder VCL application.
When the application changes state, I loop through disabling and enabling visibility of multiple menus.
This issue I have is that when looping occasionally during the loop there are more menus visible than what will fit on the screen, causing a wrap, which then causes everything on the main form to resize, and resize back resulting in slowness and a huge flicker.
I have tried the Disable and Enable align on the main form, doesn't have any impact.
I have done the WM_SETREDRAW trick on the main form, however while it stops it drawing, calling invalidate afterwards, doesn't get some of the children controls to redraw correctly. An example of what won't redraw is the tabs on a TPageControl.
An other point that may be of relevance, is that code is called from a TTabSheet::OnShow callback.
Ideally I would like to find a BeginUpdateMainMenu and EndUpdateMainMenu method, however I can't find on in the VCL documentation or the Win32 documentation.
Any help is much appreciated. Thanks.
This is not a technical answer but I'm thinking from an end user "useablilty" point of view : how easy would it be for him/her to use "more menus visible than what will fit on the screen"
Do you have the possibility to group the menu items in some way so that they could be dysplayed in sub-menus ?
The latest version of Microsoft Office uses property sheets that have the context help [?] button next to the close button:
When the context button is clicked it invokes the application's help rather than switching to 'context mode', by which I mean the arrow cursor with a question mark, i.e. there is no context help despite this being the context help button (or appears to be).
I'm trying to recreate this behaviour in an property sheet derived from the MFC CPropertySheet. So far I've had no luck. Ideally I'd like a click on this button to act in the same way as pressing F1, e.g. call directly on to the OnHelpInfo function.
Can anyone tell me how this might be achieved?
As per my comment, adding ON_WM_SYSCOMMAND to the message map and then processing SC_CONTEXTHELP in OnSysCommand did the trick.
I always been interested on how we can accomplish this (hide/show the main menu using the alt key), and now some applications do this very often. One that really please me is the visual studio 2010 with this plugin:
http://visualstudiogallery.msdn.microsoft.com/bdbcffca-32a6-4034-8e89-c31b86ad4813?SRC=VSIDE
(firefox also do this, but i think that is in a different way)
Can anyone explain me how this can be achieved or if you known of any sample project that demonstrate this please tell me.
(what i can see in some replies here in stack is that we have to destroy the menu when is to hide and create it when is to show?! but this seems a bit bad solution...)
Thanks
The SetMenu function lets you add/remove the menu from the window. It does not destroy the menu.
Note that most applications which have the dynamic menu hide/show behavior are not really showing a menu. They're showing a custom control that looks like a menu.
You might also take a look at MFC support for auto hiding menus. I used this technique and it worked really well.
in CMainFrame::OnCreate I did
m_wndMenuBar.ShowWindow(SW_HIDE);
which actually works fine in our project
I stumbled across a related pit fall that will show a hidden main frame without your consent:
Whenever the focus for a child window in an MDI application changes (e.g. due to right clicking in it), the function CMDIChildWnd::OnMDIActivate will be called, which in turn shows the main menu (even if it was removed or destroyed previously) of the MDI application.
This works basically by adding the saved main manu from the underlying's CMDIChildWnd m_hMenuShared variable.
A quick&dirty hack to prevent this, is setting m_hMenuShared to NULL (it's protected in CMDIChildWnd so this needs a custom derived child class of CMDIChildWnd) for all child frames.