I am developing an app with a custom subclassed WKWebView, and I am trying to disable the default options when a user selects some text inside the webview, and implement my own options. However, it seems there are 4 options that cannot be removed and will always show: Select To Here, Look Up, Learn..., and Share...
A previous answer claims it's possible by overriding canPerformAction() or swizzling canPerformAction on WKContentView, but I've tried both and it hasn't worked. Specifically, there is no UIResponder selectors available for the 4 options, even though they show up when I print a list of all actions coming into canPerformAction.
Another answer have claimed it might be possible to disable default options if canPerformAction() returns false from the First Responder, except WKWebView refuses to become the First Responder by calling becomeFirstResponder while selecting text, and forcibly doing so by calling resign on the WKContentView seems to disable interactions with the WebView altogether. Also tried swizzling canPerformAction on the child WKContentView, but it seems not to make any difference.
I can only assume the default options are being handled further down the chain, but when I break the chain by setting the next UIResponder to nil, canPerformAction no longer gets called and no menu shows up anymore.
I'm at a loss here, how can I simply show a customised menu upon text selection?
Testing on
XCode 11.6
iOS 13.6
Related
How can I remove or add an entry to the WorldMenu in Pharo at run time?
For example I have a menu option that loads extra tools for working with web tools. Running the code setting up these tools would include adding items to the menu to stop and start the web service. I don't want these stop and start items in normal use but the code setting up the items would be in the image.
I have seen and used the method in this question However this adds the item when the code is loaded.
Let me clarify what #Peter and I mean
Choose any class, and in the class side add your #menuCommandOn: method on the lines of
menuCommandOn: aBuilder
<worldMenu>
self showsItem ifTrue: [
(aBuilder item: self itemToken)
order: 0.1;
action: [self performItemAction]]
This way, even though the method would be invoked every time the world menu is about to pop up, it will add the menu item only if the logic behind #showsItem enables it. Notice that the dynamic nature of the menu doesn't require you to remove menu items, instead you simply do not add them. In your case such a logic should reflect the availability of the web service.
The #itemToken message send is a placeholder for the Symbol you want to use to identify the item. In other words, you would probably want to inline it as a literal rather than sending the #itemToken message. This Symbol will be used as the item label.
For further optional configuration features take a look at other implementors of #menuCommandOn:.
I followed this link http://www.wintellect.com/devcenter/jprosise/handling-the-back-button-in-windows-10-uwp-apps and "successfully" make my button work. I mean I can make my backbutton work between pages. However, if I navigate to a control which is inside this page and will cover the whole screen, then it would not allow me to back to the page. I will stuck in that control.
I'm wondering how to solve this problem. Currently I can think two possible ways (0) Override OnBackRequested() inside the control's code behind or viewmodel? (1) Override OnHardwareButtonsBackPressed() inside the control's code behind or viewmodel?. I don't know if these are correct way to do it or there is some better way to do it. Another reason for me to override is that I need to make some changes to the page navigation behavior.
As you have guessed, you simply need to hide the control again when the back button is pressed or back is requested in some other way. I would listen for the BackRequested event (not the HardwareButtons.BackPressed event) in the page's code-behind, and in the handling method you can check to see if the control is currently shown. The reason I recommend the BackRequested event is because it is universal, while HardwareButtons.BackPressed only works on a phone. Anyway, if the control is visible, then hide it, and set the Handled property of the event arguments to true. If the control is already hidden, don't do anything special to handle the event (because in that case you will want the navigation system to handle it by navigating to the previous page, if there is one). There are many aspects to navigation in Windows 10 -- please see these pages on Navigation and the SystemNavigationManager.
I have some legacy code and for some reason, menu items are being enabled or disabled on launch. My question is, how? Is there any way to do this without calling the EnableMenuItem() function? Is there a way for MFC to do the opposite from what the resource settings say?
I'm also at a loss as to why the current ones are being disabled or reenabled in a SDI when the last child window has closed. This is probably due to me not understanding the framework well enough and I thought I've read through all of the docs here.
With MFC, menu items could be disabled if there is neither a ON_UPDATE_COMMAND_UI handler nor a ON_COMMAND handler for the menu item -- according to this MSDN article,
If the framework does not find an ON_UPDATE_COMMAND_UI entry during
command routing, it automatically enables the user-interface object if
there is an ON_COMMAND entry somewhere with the same command ID.
Otherwise, it disables the user-interface object
...
It is possible to disable the default disabling of user-interface objects.
For more information, see the m_bAutoMenuEnable member of class CFrameWnd in the MFC Reference
[this applies to menu-items and toolbar-items]
I have a CoreData / NSPersistentDoc app. It works fine.
I added a new entity to the MOM, and updated the version.
Now, when I create new instances of that Entity inside the MOC, the "Save" menu item remains disabled until/unless I create any instances of the old Entities that were already in the app.
The red dot button on titlebar correctly goes black to show that the document has changed - but OS X / NSDocument refuses to acknowledge this - it is impossible to do a Save.
Any ideas?
I found the cause / solution - it was my own bug, but this answer may help others with similar issues.
I was using Apple's official approach for enabling the Copy/Paste menu items (by implementing validateMenuItem), and returning true/false for copy and paste at the right times.
And I was returning NSPersistentDocument's implementation for everything else (which included Save, although I didn't see that).
Then, when I added my new NSManagedObject, I added a sub-view, and sub-view-controller, and I delegated the validateMenuItem to this - i.e. so that it could handle it's own copy/paste status.
...but I had no code path for "if it's not copy paste, and it's not handled by the child, and it's not handled by my NSPersistenDocument subclass ... then hand it to NSPersistentDocument to decide"...
...and so the Save menuitem was never being enabled.
I have a core data document based cocoa app that is working well except for one slightly odd problem.
For some reason, if I make a change to any of my fields the menu/window don't seem to recognize it - ie. the red close button doesn't get the black 'dirty' indicator and the File/Save menu item isn't enabled. However, if I attempt to close the application (via command-Q), I do get the popup asking me if I want to save my changes.
It seems that the document's dirty flag is being set, but the window/menu items aren't reacting to it. I am curious as to where I might look to see why this might be the case. I suspect that it may have something to do with my window not knowing about my ManagedObjectContext...
The only slightly atypical behaviour is that my document's makeWindowControllers method has been overridden and I am adding my window controllers using a call to my document's [self addWindowController:xxx] method. My window controllers subclass from NSWindowController so I had to add my own instance variable to each window controller to hold the ManagedObjectContext, but I suspect that this isn't getting passed to the window/menu. Not sure what the normal pattern is here...
Anyway, any thoughts would be much appreciated. Thanks
From the description it sounds like your UI elements are not actually bound to the document itself. If so, then the UI elements are not observing the document and are not reacting to changes in the document. Check the bindings.
Thanks in part to TechZen, and also re-reading my own question (in particular, where I said "I suspect that it may have something to do with my window not knowing about my ManagedObjectContext") I started to look at the bindings for my WindowController subclass.
As it turned out, I hadn't bound the window outlet for the File's Owner to my actual NSWindow. As soon as I did that, the black dirty dot and the window's menus started behaving correctly.