I have a wxCommandProcess cmd. I have code as following
wxCommandProcess cmd;
cmd.Submit(command);
cmd.GetEditMenu(); //NULL
I want to make an action history for the software. I can get the name of the command by calling GetCurrentCommand()->GetName(). It works perfect. Why is the menu is NULL? Didn't I store the command to the menu when I call submit()?
I think there is something very wrong with your understanding of wxCommand and wxCommandProcessor classes as the question just doesn't make any sense as stated. You can associate a menu with wxCommandProcessor just to simplify the management of the standard "Undo" and "Redo" menu entries, but it's not going to somehow synthesize a menu for you out of thin air, you have to set it first.
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:.
The whole day I am trying to solve this simple issue, but without any success.
I found a lot of hints in internet, but seems, that none of them is valid for my problem.
My issue is quite simple: I want to change the caption of a menue item while runtime
But it seems, that all solutions I found are very specific.
My requirements are this:
- it is a MFC application (VS2010)
- It is a SDI application, not MDI
- I want to change the caption of a main menu item (like "File"), not an entry of a submenue.
Because of main entry item, there is no ID for the menu item. Therefore solutions with ON_UPDATE_COMMAND_UI will not work!
My problems are:
- either the code I tried, is generating an assertion or exception
- or the function call returns with false
- or the function seems to work well, but I do not see any result (the caption is still unchanged)
Maybe I am using the wrong functions, or the wrong place for calling the functions.
Has anybody an example, which would work within my application pre-conditions?
Many, many thanks!
Richard
Windows cleverly hides the function to modify a menu under the arcane name of ModifyMenu. I hate it when they do things like that. Really makes me wish for Linux/Unix, with nice clear names like shmdt and mvwaddchnstr. Anyway, getting off my soap box for the moment, you'd call it something like this:
GetParentFrame()->GetMenu()->ModifyMenuW(1, MF_BYPOSITION, 0, L"New Item");
GetParentFrame()->Invalidate();
I was looking at the function CMFCRibbonCategory::RemovePanel and I saw something that I don't understand. The 2nd optional parameter is bDelete which according to the docs:
[in] bDelete
TRUE to delete the panel object from memory; FALSE to remove the panel object without deleting it.
I don't see a way of referencing the same panel elsewhere and this isn't like hiding the panel as there is no way to bring it back, so why wouldn't I want to do this?
Unless this is in case I were to keep a live pointer to it using CMFCRibbonCategory::GetPanel? Sounds kinda like a bad idea.
I agree. There is no real use for Setting bDelete to false at all.
m_arPanes is no where accessed in a way that some one can add a Panel with a plain pointer.
It seams to be a relict when they transported the BGC ribbons implementation into the MFC. The BCG version also have this bDelete flag and it isn't useful there too, but there are more complex functions that handle such panels.
But I don't see this functions and internal customizable panels in categories in the MFC.
So from the design point it would have been better to create a special protected function like InternalRemovePanel. That just remove th Panel and keps the pointer...
I need to detect long-press on a UITextView, which already recognises long-press thus it has a long press recognizer, can I create a new one and add to it? How will it work then, two recognizers will get the same callback when you long-press?
Thanks!
Just add two UILongPressRecognizers with different selectors (initWithTarget:selector:) to the view. It should work just like you think it will work. You may need to return YES from your delegate's -gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer: when both of your UILongPressRecognizers are invoked simultaneously.
Note that you will likely encounter problems with Apple's recognizer for popping up the magnifier loupe.
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.