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.
Related
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 have a question regarding coded ui UIMap.
Every time I record an action on the same application, coded ui generates a new object for the same window in the application.
It looks like:
UIAdminWindow
UIAdminWindow1
UIAdminWindow2
and so on...
every window class holds different buttons, even though it's the same window.
Thus it's very hard to keep code maintenance.
What i would like is that every time i perform actions and records on a window, even if not at the same time, the already generated class for this window, will be updated with the new controls.
any suggestions to why it happens?
Thanks a lot!
You can clean up your UIMaps by doing two things:
Use the UIMap Toolbox (from codeplex) to move controls within the UIMap so they are all under one control tree.
When you have duplicate UI controls, go to the properties for the action that references the duplicate control and change the UI Control property to point to the original control in the UIMap.
The duplicate trees should now be unreferenced and you can delete it from your map, keeping things clean.
And yes, it's a pain to do, but it's worth it for maintainability.
In UIMap.uitest you can change the action name and the control name for better maintenance.
For example: you can set UIAdminWindow as FirstAcessWindow or other name that will express comfortably the control or the action.
What I can guess is that there is some randomly generated content or element identification data such as class or title that may be causing it. This may be caused by different username for example. Also you can update the element from UI map element tree.
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 Glade GUI description file with a GtkTreeView in a GtkHBox in a window; and there's a handler for the row_activated signal. Now, Glade has automatically set the "events" property (inherited from GtkWidget) of that treeview to some value (GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK). And there are two strange things with this:
removing the pre-set value (so that the property is empty) doesn't seem to break the application (at least not with the old GTK 2.10 I have atm).
in fact, an annoying bug I has seen before (where the treeview items would not correctly react to expand or collapse clicks) is now gone!
I have yet to test this with a newer GTK version, but the question is already there: exactly what is the purpose for this events property? And why does Glade automatically and unnecessarily set it to some value? Does this have some side effects I'm not aware of?
It's a bug in glade, it always sets the event property of widgets it create. It has no notion of the default value of a property so it always sets it.
Doesn't this mask indicate the events you're willing to receive? In this case, you'll probably want to receive notification that the user has clicked or double-clicked an item in the GtkTreeView, and you'll want to register callbacks to handle these events.
me.yahoo.com/a/kUQ7zeQ: but even if I set the property to an empty string as mentioned, the row_activated handler is still called when I double-click on a row (or press Enter or Space). So the treeview still gets events...