We are trying to modify the default selected paper size for a NSPrintPanel. Using NSNotification we are able to observe and implement changes on our accessoryViews in the NSPrintPanel. However when we try to implement setPaperSize (NSPrintInfo the instance method), nothing happens and the initial paper size (default) for the default printer is selected for all other printers (We have regular printers and receipt printers).
I know the new paper size being set is correct whenever the printer changes. We are programmatically obtaining the paper sizes from the Core Print. While trying to the set the right/desired paperSize, the app doesn't break or returns any stack. So it seems, it seems apple doesn't support changes to the paper size PrintPanel.
While researching the issue, we noticed that NSPrintPanel accessory view from apple titled "Paper Handling" seems to respond to the printer changes, based on the settings you provide to Page Setup (in the file menu, NSPageLayout). So our questions are:
Is there a way to access/set the Suggested Paper size displayed in this accessoryView programmatically?
I know this accessoryView reads from page setup (NSPageLayout), thus I'd like to know if to access set these values in the "Paper Handling" accessoryView is a good approach?
Notes:
- Mac doesn't seem to allow/provide a user friendly way to set default paper sizes for each printer installed.
Accessory View we are talking about:
We have reviewed apple documentation (of course) and posting from other people with similar issues with no avail. We'd greatly appreciate a push in the right direction. Thanks in advance.
It’s been a while since I’ve done this, but what happens when you set it on the NSPrintPanel’s printInfo? Any better? It might make its own temporary copy.
Related
I want to create an e-book reader app, I have tried to use the control RichTextBox to display the content of a chapter in a book, while, it could not display the entire chapter, finally, I am told that the size of any control in windows phone is less then 2048px, and this causes the text located after 2048px (Height) in the RichTextBox could not be displayed. So, I need to find another one control to do such a thing. Is there any suggestion?
Further more, I want the control may meet the following requirements:
it could customize the fontsize, forecolor of the text displayed in it (this may be the simplest one)
it could customize the background pic.
it allow the user to select the text on it freely for copy (this is the most important one of the 3)
Since an ebook is fundamentally a set of HTML pages, you should display your pages using a web control.
By the way, customizing font size etc. is not by any means trivial, because you end up trying to figure out whether or not and how to override CSS rules in the book.
You might want to check out http://openbookreader.codeplex.com/, although it seems to have been inactive for a couple of years.
I have the following issue, concerning the way to fine control Japanese input in an iOS app. To make things clear I include an image to this post (see below).
As one can see I have typed や in the input text field and a bunch of choices (や 役 矢 訳 ヤ 屋 焼き …) appear above the keyboard for possible conversions.
Here is what I would like to know:
The choices presented in the picture make no sense for my particular app. I would like to be able to set myself the possible conversions offered to the user.
In this case it would be (山形県 山口県 山梨県). Does anyone know how I can achieve this?
In other words I am trying to find out how handle the set of data appearing above the keyboard.
Thanks in advance for any relevant information.
I have a bit of a challenge.
In an earlier version of our product, we had an error message window (last resort, unhandled exception) that showed the exception message, type, stack trace + various bits and pieces of information.
This window was printscreen-friendly, in that if the user simply did a printscreen-capture, and emailed us the screenshot, we had almost everything we needed to start diagnosing the problem.
However, the form was deemed too technical and "scary" for normal users, so it was toned down to a more friendly one, still showing the error message, but not the stack trace and some of the more gory details that I'd still like to get. In addition, the form was added the capabilities of emailing us a text file containing everything we had before + lots of other technical details as well, basically everything we need.
However, users still use PrintScreen to capture the contents of the form and email that back to us, which means I now have a less than optimal amount of information to go on.
So I was wondering. Would it be possible for me to pre-render a bitmap the same size as my form, with everything I need on it, detect that PrintScreen was hit and quickly swap out the form contents with my bitmap before capture, and then back again afterwards?
And before you say "just educate the users", yes, that's not going to work. These are not out users, they're users at our customers place, so we really cannot tell them to wisen up all that much.
Or, barring this, is there a way for me to detect PrintScreen, tell Windows to ignore it, and instead react to it, by dumping the aformentioned prerendered bitmap onto the clipboard ready for placing into an email?
The code is C# 3.0 in .NET 3.5, if it matters, but pointers for something to look at/for is good enough.
Our error-reporting window has these capabilities:
Show a screenshot that was taken when the error occured (contains all the open windows of the program at the time, before the error dialog was shown)
Show a text file containing every gory detail we can think of (but no sensitive stuff)
Save the above two files to disk, for latter attaching to an email or whatnot by the user
Sending the above two files to us by email, either by opening a new support case, or entering an existing support case number to add more information to it
Ignore the problem and hope it goes away (return to app)
Exit the application (last resort)
We still get screenshots from some users. Not all, mind you, so my question is basically how I can make the PrintScreen button help us a bit more for those users that still use it.
One option: Put the stack trace and other scary stuff into the error screen using small, low-contrast type -- e.g. dark gray on light gray -- so that the user doesn't really even see it, but the Print Screen captures it.
But if you want to detect the PrintScreen and do your own thing, this looks like an example of what you want.
Wouldn't it be possible to disable the Print Screen button altogether when the error popup is active? Have it display a message along the lines of "Please use the clearly visible button in the middle of your screen to report the error" I agree it breaks expected functionality, but if your users are really that stupid, what can you do...
Alternatively, have it report errors automatically (or store the data locally, to be fetched later, if you can't send without asking for some reason), without asking the user. If you want to be able to connect print screened screenshots with detailed error data, have it send a unique ID with the data that's also displayed in the corner of the popup.
What about offering them a "Print Screen" button that performs these actions as well as performing the print screen? If you're locked into this method of having your customers send error details, this may be an easier route to take.
Lifted from my comment below for easier reference (looks helpful, perhaps):
codeproject.com/KB/cs/PrintScreen.aspx
This is in theory...the best way to deal with it I would think
Intercept a WM_PRINT message or inject one into your process... see this article here
Install a system-wide keyboard hook and intercept the print-screen key and swap it around with your contents prior to the capture. Now, I can point you to several places for this, here on CodeProject, and here also, keyboard spy, and finally, global Mouse and keyboard hook on CodeProject.
Now, once you intercept the print screen, invoke the WM_PRINT message by capturing the contents that you want to capture.
I know this is brief and short, but I hope this should get you going.
The only solution i came up with was to offer big, large, easy to read toolbar buttons that give the user every opportunity to save the contents of the error dialog:
Save
Copy to clipboard
Send using e-mail
Print
And after all that, i use the Windows function SetWindowDisplayAffinity in order to show the user a black box where the form should be:
This function and GetWindowDisplayAffinity are designed to support the window content protection feature that is new to Windows 7. This feature enables applications to protect their own onscreen window content from being captured or copied through a specific set of public operating system features and APIs. However, it works only when the Desktop Window Manager(DWM) is composing the desktop.
It is important to note that unlike a security feature or an implementation of Digital Rights Management (DRM), there is no guarantee that using SetWindowDisplayAffinity and GetWindowDisplayAffinity, and other necessary functions such as DwmIsCompositionEnabled, will strictly protect windowed content, for example where someone takes a photograph of the screen.
If their screenshots show a big black box, hopefully they'll get the hint.
I did add a defeat, if they hold down shift while clicking "show error details", i don't add the protection during form construction:
//Code released into public domain. No attribution required.
if (!IsShiftKeyPressed())
SetWindowDisplayAffinity(this.Handle, WDA_MONITOR); //Please don't screenshot the form, please e-mail me the contents!
I have an application that displays a dialog when the user needs to enter information. The reason for this, is to keep the main form readonly, and only when you need to add/edit data will a dialog appear.
The problem I'm wrestling with is what to display for the label names in the dialog. The application is a WPF desktop app and traditionally desktop apps are very short on label names (usually one or two words). I want to make the dialog user friendly and be more descriptive about the information that is required. Web developers seem to be catching on to this and are much more descriptive with their label names, but most of the forms I've looked at are forms that are only filled in once, whereas I will have data that can be edited.
An example: If I had a label that asked a user if an employee smoked, in most a destop apps the label would normally be something like 'Smokes?' with a checkbox, whereas I want something like 'Does the employee smoke?'. My issue with this is, that the first time you come across this dialog and enter the data, then it seems OK, but what about when you are editing data that is already there. Does this label now make any sense. Past tense and present tense seem to be getting in my way and I was interested in what people think or ways they have approached this. The application I'm writing is a WPF app and I feel that traditional label names are a bit old in the tooth now.
Another example would be entering contact details for a person. Do I just have labels that say Phone, Fax, Email or something more descriptive. i.e. a label that appears before the textboxes stating 'Enter the contact details below' and then the single word labels?
Maybe I'm just being pedantic about all this, but I would like to take a step forward so that my application contains more than single word labels that are sometimes unclear to the user about what is required.
Why not make use of the concise labels and use Tool tips for a longer explanation.
The longer explanation is only required when a user is unfamiliar with the application anyway.
Also, you could re-word a label to make it sound more like a question such as "Is a Smoker?"
Since you are using Stack Overflow, take note of their use of tooltips, I think Jeff Attwood has a blog post or comments in a podcast about the use of tooltips in SO. I can't remember where I heard / read it.
Have you thought about creating a "quickstart" flow or wizard for entering data for the first time? This would give you the opportunity to guide the user through the process, using labels with descriptions, so that they learn to associate the description with the label you've chosen (hopefully something succinct but intuitive). Then when they need to edit data, they have learned the application taxonomy.
If you are running into issues with tenses, steer clear of using verbs or only use the present tense. I would try using nouns - "smoker?" instead of "smokes?"
When you're asking for common data like phone numbers, email addresses, you can probably assume that the user will understand what you mean. Just be clear as to whose contact information you are asking for - using a title for the field set that is explicit is a good idea ("Employee Contact Details"), adding a short description above the field set will help too.
Of course, you should always do some level of usability testing on your application before you launch it to uncover any issues with the interface.
I'm in the process of designing and testing various ideas for an application whose main functionality will be to notify users of occurring events and offer them with a choice of actions for each.
The standard choice would be to create a queue of events showing a popup in the taskbar with the events and actions, but I want this tool to be the less intrusive and disrupting as possible.
What I'm after is a good book or papers on studies of how to maximize user productivity in these intrinsically disruptive scenarios (in other words, how to achieve the perfect degree of annoying-ness, not too much, not too little).
The user is supposedly interested in these events, they subscribe to them and can choose the actions to perform on each.
I prefer books and papers, but the usual StackOverflow wisdom is appreciated as well.
I'm after things like:
Don't use popups, use instead X
Show popups at most 3 seconds
Show them in the left corner
Use color X because it improves readability and disrupts less
That is, cognitive aspects of GUI design that would help users in such a scenario.
For notification, I prefer small notification windows in the bottom right corner. If they have a minimum UI allowing me to take some quick action, it would be ideal.
As model: incoming mail notification from Outlook, Skype notifications for incomming calls, etc.
I have read and recommend:
About Face 3
The Design of Everyday Things
I don't know of any formal articles but the Ubuntu UI design team have considered this issue and you may find something of value in their notification design guidelines or in this discussion by Mark Shuttleworth.
Sorry, no book recommendation here, just one piece of advise: Ultimately, you should let your users decide.
In my experience, what one user considers to be a useful feature is seen as completely broken by the second, while the third doesn't care at all.
Offer them 3-5 options how they will be alerted (including the option to turn alerts off ;-). Of course you should optimise these options as much as possible, hopefully some other answers here can help you with that.
A collection of possibilities:
Change a static tray icon. Useful if the user doesn't have to answer each message immediately, and relatively unobtrusive. Should be an overlay on the original image, making sure that the user recognizes which application it's from, and should be different enough that the user immediately understands that it's not the original icon (for example, a red / yellow exclamation mark on a blue / green background).
Change the tray icon to a dynamic variant. This will be more obtrusive, grabbing the user attention periodically, but is useful when the message is urgent. Could for example be a revolving version of a circular logo, or a pulsating square logo. Depending on the urgency, the animation could repeat endlessly (highly distracting) or once in a while. Use with care :)
Pop-over box in a corner of the screen. This should give some context info, the primary object of which is to enable the user to decide whether or not it's worth checking out immediately. Could afford clicking by using a "More" link or big "+" sign.
Focus the application window immediately. Enormously intrusive, and should not even be used in case of nuclear meltdowns (what if the user already knows the meltdown is occurring, and is looking elsewhere for a solution?). Just don't.
I think an answer depends highly on the specifics of the UI you are working within. However, for general guides
The GNOME desktop environment's human interface guidelines (HIG) is a useful resource if your environment is GNOME, and perhaps informative if it's not. There is a section on using the "desktop notification area": http://library.gnome.org/devel/hig-book/stable/desktop-notification-area.html.en. This covers not overloading the area, etc. (perhaps analogous to the win32 tray).
Apple have their own HIG document. Part of this describes using the Dock for conveying status information: http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGMOSXEnvironment/XHIGMOSXEnvironment.html#//apple_ref/doc/uid/TP40002721-TPXREF139
Apple also have a separate HIG document for the iPhone. there are several notification techniques described within, e.g. "alerts" http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/ModalViews/ModalViews.html#//apple_ref/doc/uid/TP40006556-CH11-SW1 which are specifically described as to be used for critical information (due to their disruptiveness).
Several apple iphone apps adjust their icon to convey some status info: e.g. mail, SMS, phone all indicate the number of outstanding mails, SMS messages, or missed calls/voicemails as part of their launch icon. I can't, however, find any reference to that in a cursory scan of the apple iphone HIG.