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]
Related
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
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'm working in a legacy application using MFC.
We have a mechanism to enable/disable controls depending on some business logic.
This mechanism is implemented in the CView-derived class. The way it works is all the views in the application derived from a common CView-derived class (CBaseView) and on the PreTranslateMessage all controls of the view are enabled/disabled.
This worked fine so far because all controls send at least WM_PAINT message when they need to be painted. So the system worked without the user having to move the mouse or anything. I recently added some drawing features and I had to use WS_EX_COMPOSITE to get ride of some flickering. With this flag activated my CView-derived class is not getting any called to PreTranslateMessage when creating the view....so the controls are not disabled until the user moves the mouse over the control.
I understand there is no way to send WM_PAINT using WS_EX_COMPOSITE but is there other message I can use to get the same behaviour???
Edited:
I am currently using the OnIdle approach but it has a big drawback, the windows doesn't become idle until after drawing all the controls...so when you enter the screen al controls are enabled and inmediately they are disabled...this makes a quite ugly effect!
More solutions???
Thanks in advance...
The logical place to enable/disable controls would be CView::OnUpdate, it is called by the framework after the view's document has been modified and from OnInitialUpdate(); you can also call this function if there is some change that would trigger re-evaluation of your business logic.
EDIT
After reading the question a bit more closely, what you could also do is to post a private message at the end of OnInitialUpdate and "catch" it in your PreTranslateMessage:
PostMessage(WM_APP, 0, 0);
Calling InvalidateRect followed by UpdateWindow against the window in question will mark the entire client area as dirty and force an immediate repaint. Remember that WM_PAINT is not really a message, in the queue in the usual sense, it is pushed out after all other messages have been processed for that window, which would include any invalidations of the area being drawn. No message is generated at all if there are no invalid segments of the active window display.
I am new to MFC. In the project I am working on the dialogs are created in resource file(.rc).
In that there are OK button(id ID_OK) and Help button (id ID_Help). I am not able to find the event handlers for these two buttons. There are other buttons where the event handlers mapped are easily found. If someone teach me how to find those event handlers it would be very helpful.
And how can I find the functions which get called on clicking of the particular button by debugging in visual studio?
Thank you.
Double click the button (shown in rc) opened in Resource View in Visual Studio and you will be automatically placed by Studio where the Event handler is located in your code.
If this does not work, then probably delete the Button with ID's ID_OK and ID_Help in your resource view and again add it to the resource using different ID and then try to generate the event handler by double-clicking those buttons in resource view. This is because sometimes the value of ID's conflict with other ID values and hence Studio is not able to generate the Event-handler for you in that case.
Buttons don't have direct event handlers as in other frameworks (like in C#, WinForms etc). You must use message-maps in MFC.
ID_OK maps to virtual function CDialog::OnOK, you can just write your virtual function implementation. Framework will call it for you. You can also handle this message with WM_COMMAND message entry.
There is no standard resource ID as ID_Help - it is always capital, and has to be always in caps! No one is stopping you from using small letters, though - it for consistency and better readability.
Instead of fiddling with resource files (.RC and resource.h), mapping the same with your dialog class and things like that. I suggest you to go, and learn, without resource file. Start with drawing in frame (circles, filled-triangles whatever). Learn and know why virtual function are there for some messages, and message-maps for other (most) messages.
My two cents.
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.