I have 5 NSTableView's instances that have the same contextual menu. When I get the message that the menu has been clicked I need to know which table sent it. I've checked the NSMenu documentation but I don't seem to find a way to check which of the tables opened the menu..
I'm thinking of subclassing NSTableView and send a message to the delegate on menuForEvent, would that be the best way?
UPDATE:
Thanks Joshua, I,am using 5 tables to display a 5 day week task planning. Each table represents a week day, and I added the contextual menu for adding and removing tasks. So when a user clicks "add task" on a week day I need to know which one. I've got it working by subclassing tableview and sending a message to the delegate when the menu is opened. In this manner my controller knows which of the tables was the last to call the menu.
But it doesn't seem to me like the best implementation to get this, maybe is like you said the problem lies on the UI, what do you think?
Jose.
I don't see a way to get this information. Menus aren't "attached" to anything; they're displayed in a location. Your -menuForEvent: override might work but it gives me the willies.
While this isn't an answer to your question, I confess my first reaction is "why do you have multiple tables with exactly the same menu?" This strikes me more as a UI issue. One would think a contextual menu would be pretty specific to the specific kind of thing (or view thereof) that it represents. That begs the question: why do you have 5 table views that all have exactly the same context? If all 5 tables represent things that are controlled in the same way by the (presumably) same controller, it's highly likely there's a better way to represent your "collection of things" than 5 separate tables.
I'm making a lot of assumptions, granted, but my curiosity is getting the best of me, I suppose. :-)
Related
I have little experience in developing GUI for desktop applications, but I want to develop a typical GUI for creating/editing entities (e.g. Customer, Suppliers, etc.) which would be similar for many cases and would be comfortable for the users.
[* Please don't close the question. I put much effort in preparing the question and I really need help. *]
After analyzing our tasks I designed the following possible options:
1) In simple cases it is possible to solve the task by using an ordinary grid:
I.e. the workflow is: On pressing the Add button, a new row is added to the grid. On pressing Delete the user is asked for confirmation if he/she really wants to delete the focused entity instance. On pressing Save all previously made changes are saved. On pressing Close the form is closed (user is asked if he/she wants to save changes before closing).
Cons: I think such a GUI will only work for very simple cases. Editing something complex in a grid is not comfortable neither for a user nor for a developer (implementing complex editing in a grid will not be trivial I think).
2) For more complex entities the following option is possible:
The grid is used here only in the read only mode. On pressing Add a modal form for filling information about a new entity is shown. On pressing OK in that form the data is validated and if everything is ok the object is added to the grid datasource. On double clicking on a grid row the same form for editing the chosen entity instance is shown.
Cons: For every entity we will have to create 2 forms.
3) Another possible option:
The grid is also in the read only mode. When focusing a row in the grid, the fields above the grid are filled and a user can edit them. On pressing Add a new entity instance (object) is created and added to the grid's datasource, then the new row is focused, fields above the grid are cleared (binding helps here), the cursor is placed to the first field and the user can start typing.
I don't see any cons here except that maybe you will not have enough place for the grid and the fields on the same form. I like this option though I don't remember that I saw it anywhere.
I tried to ask the users of my program to help me decide which GUI is better for them, but the typical answers are "I think both options are ok" or "I don't know, you decide which one is better".
Now I would like to ask people with experience in GUI design the following questions:
1) Which option do you use usually? Maybe another one (not shown above)?
2) Would be nice if you also said a couple of words about your implementation (dataset/custom business objects/binding, etc.)
3) Which cons did you notice in my options?
4) Any advice on what I can read on the subject?
Thank you for help!
Junior1993, This is a great question, and there are many online resources that will spell out the trade-offs of each of these interaction design patterns, when to use them, and when they are most effective. You did not provide project-specific details, so it's impossible to answer those questions.
The "Work With" pattern is the foundation of your write-up, and you were asking about the pros and cons of different variations. Here is some reading on "Work With": http://quince.infragistics.com/html/PatternView.aspx?name=Work+With
All of the patterns you described are well-documented and can be modified to fit different purposes.
Your #2 pattern is "Edit-In-Place". It can also be found on the Quince site.
Your #3 pattern is "Two-panel selector".
This one takes many forms, but it helps to preserve context while editing.
The one you did not mention was "New-Item Row". You might want to look at that one, too, and select the pattern or combination of patterns that best fits your users' goals and the content they are creating/editing.
There are other pattern websites out there, and most build on the work of Jennifer Tidwell, author of "Designing Interfaces", an interaction design classic.
Best of luck to you!
when i use pivot with in the panorama .pivot are used as a gallery view. i want to move pivot when i swipe it .but the problem is this because of both panorama and pivot are the same gesture event so both are they move .
i want swipe only my pivot view .
I would like some sample code or any other suggestion to do this.
so please give me a solution for doing this and
also give me a link where i easily understand this. Thanx in advance
You shouldn't have a Pivot in a Panorama control. End of discussion.
I believe it is achievable, because I've already solved similar issues with having WebBrowser control inside a custom horizontal-scrollable overview container like Pivot/Panorama, but believe me, it is NOT worth it. I've had to dig very deep into the visualstructure of the controls and attach my own manipulation-handlers to their viscera, manually choose which horiz/verti events to pass and which to cancel, and so on. This is not so easy, takes a lot of time, and doesn't guarantee that on the end you will have something behaving in a way you wanted to achieve in the first place. If you are not bound by some contract to preserve the shape of the UI, please, drop the idea and redesign your UI, just to save on your sanity and nerves.
But, if you are already insane or really want to dig where noone should, start on analysing your UI as a two rectangles: large pano and small pivo, and think which part should behave how on different possible touches/h-v swipes/h-v pans/pinches/so on. Write it down just to for reference, or soon you will probably start making small mistakes that will interfere with your understaning of the flow of the events.
I've checked the version I have, and "my" Panorama uses internally the UIElement.ManipulationXXXX events. In that case:
Display visualtrees of your UI and try attaching manipulation-events to every control. In those events, write/log which control's which handler was invoked. Then make some swipe/scroll on your APP and observe events. Analyze how they were bubbling and try cancelling (e.Handled=true) the manipulation-completed and/or manipulation-delta events somewhere between pivot and panorama. Your goal is to have the panorama see that e.Handled=true, while your pivot must see e.Handled=false. Your Pivot will probably see the event sooner than the Pano, so that point should be relatively easy.
If it fails to work, then you should check your version of the Pano, and check how it detects movements. If, for example, it uses the GestureListener - try the same trick with it. Etc.
And remember, you can always make your own horizontal-overwiew-container that will look like Pano, behave like Pano, and that will work with Pivo better - because it will be your code and you will tell it what and when to move. if you want to go this way, start on google and check all the preliminary Panorama previews that random people have published before that control was published by MS.
I'm relatively new to Cocoa and I would like to implement the ability to add or delete items from a pop-up menu in the same way that the OS X System Preferences/Network Location pop-up works. Selecting the 'Edit Locations...' option rolls down a window that provides the ability to add to, or delete from the existing Location list. My interest in doing things this way is as much about conforming to the relevant Human Interface Guidelines as having a way to dynamically change the menu content. (I have no real problem with the 'background' coding side of things, it's the user interface that's my primary issue at this stage.)
Is this a standard IB View?
On the surface, I can't see anything appropriate, but maybe that's just my inexperience. I'm assuming that, because this is not an uncommon sort of requirement, the task should be pretty straightforward and that Apple, or someone, would even have a relevant code sample to show how to define such a window.
Can anyone point me in the right direction?
Sorry for the late answer. I found this tutorial: http://cocoadevcentral.com/articles/000014.php
I was just wondering if it is possible to create a drop down or popup menu with a hierarchy? The application I am currently working on tracks Assignments, Courses, and Subjects. When the user creates an Assignment they will need to be able to select a Course that it belongs to from a drop down but I also wan't the drop down to be organized a little bit by having headers so the user can easily see what Subject that Course belongs to.
Example:
Select Course: [drop down below]
- Life
--Chores
--Eating
--Vacations
- Math
--Algebra
--Calculus
Etc...
Not the best example but the entries "Life" and "Math" would be bold and unselectable and all of the others would be regular menu items. Does anyone have any suggestions? Let me know if you need more information on what I am trying to do.
Yes, if you build them manually in code or in Interface Builder. No, if you're using Bindings.
NSPopUpButton takes an NSMenu full of NSMenuItems.
One of the things that has been talked about a few times on the podcast is whether menu items should always be enabled to prevent "WHY ISN'T THIS AVAILABLE!" frustration for the end user.
This strikes me as a good idea, but then there's the issue of communicating the lack of availability (and the reason why) to the user. Is there anything better than just popping up a message box with a blurb of text?
As I'm about to start on a fairly sizeable cross-platform Windows / Mac app I thought I'd throw this out to hear the wisdom of the SO crowd.
One thing I've seen a printer manufacturer do with their printer properties dialog is to have a little help baloon icon beside disabled items that display a tooltip when hovered over.
Another thing you can do with disabled items is to add in parenthesis why it's disabled or what the user would have to do to enable it. E.g., "Save (already saved)" or "Copy (select something to copy)".
I don't like keeping it enabled because then it will instill hesitation in users to select any menu item in fear that they'll just get an error message making them feel stupid for not realizing that they couldn't possibly perform that operation at the time.
Menu items that spring dialogs have elipsis (...) after them to let users know it's not just click and carry on. Required form fields have an asterisk or bold label to spare the user from being scolded with a validation error message.
You have to consider the alternatives.
Hide the menu item. This is bad. Now you have menu items disappearing and reappearing all the time?
Disable the menu item. Now the user can find what they're looking for, it just isn't obvious how to enable it. This is better, but still leaves the user slightly puzzled.
Keep the menu item enabled, but make it display a dialog that explains what needs to be done when the program is in a state where the menu item can't be properly used.
I agree with Joel on this one, #3 seems like the best choice.
Joel has a post on that http://www.joelonsoftware.com/items/2008/07/01.html which might be a good place to start thinking about this.
#Bill the Lizard: I'd combine #2 and #3 - disable the item, but have a tooltip that indicates why it is disabled.