The default search scope is always 'Entire Solution' which just BEGS for the end user, at some point, to exercise the option in Source Control to undo pending changes. :)
Is there a way to have a blank in this drop down or custom set it to Current Document?
Personally, why invite disaster as the first option? Let's have the Nuclear Option as one that must be intentionally selected, not just set it as the default.
It's obviously not because of an alpha setting, since Current Document should come up first if that were the case, which means someone decided this was the best default, maybe the guiding thought is 'Let's just see who's not on their toes today.'
Enough of a rant ... if there is a setting to force Alpha Order, that solves the issue. If it can be customized, even better.
Thanks!
I recently installed ReSharper within Visual Studio 2017. Whenever I hover over method that has a lot of overloads, half my screen is being covered with suggested candidates.
This is rather impractical as I cannot keep editing the method that I put my cursor on nor can I select portions of the method, since the overlay covers the method in question.
Is there a setting within ReSharper where I could turn off this feature?
Maybe there is a setting that would even limit the number of rows?
Within ReSharper's IntelliSense settings, I disabled Automatically show parameter info after x-milliseconds, as well as Display signature at once. Prior to that I checked that Limit the number of candidates to 5 was active.
However, none of the options had any effect on the resulting screenshot below:
Screenshot of half the screen covered with possible candidates - removed the code and possible candidates - hopefully this doesn't make it even more confusing than it is already ;-)
I support an old (late 90s) Domino DB that has a growing number of Mac users. In some docs, layout regions become grayed out once you click anywhere in the doc even though it's still editable, i.e. if the cursor was in a text field and you type something blindly and save it, it will be there when you reopen the doc. It doesn't happen in all docs and I have found no pattern.
Any Domino designers seen any behavior like this? I don't this there is anything too weird in the code; onBlur or onChange used in some cases - that sort of thing. Nothing too complicated really. Thanks!
Layout regions are a nightmare to maintain: there can be objects with differing hide-when formulas stacked on top of each other that might be causing this. I suggest making a copy you can work in without worry: inspect each object fully (keeping notes) then delete. Keep drilling down until you hopefully hit an object that matches your grey-out. If you don't find one, then it could be a bug as posted by Richard Schwartz. As Richard and D.Bugger suggest, perhaps it's time to rebuild the functionality without using a layout region: layout regions never worked with a web browser.
I have a Cocoa application managing a collection of objects. The collection is presented in an NSCollectionView, with a "new object" button nearby so users can add to the collection. Of course, I know that having a "delete object" button next to that button would be dangerous, because people might accidentally knock it when they mean to create something. I don't like having "are you sure you want to..." dialogues, so I dispensed with the "delete object". There's a menu item under Edit for removing an object, and you can hit Cmd-backspace to do the same. The app supports undoing delete actions.
Now I'm getting support emails ranging from "does it have to be so hard to delete things" to "why can't I delete objects?". That suggests I've made it a bit too hard, so what's the happy middle ground? I see applications from Apple that do it my way, or with the add/remove buttons next to each other, but I hate that latter option. Is there another good (and preferably common) convention for delete controls? I thought about an action menu but I don't think I have any other actions that would go in it, rendering the menu a bit thin.
Update I should also point out that delete should be an infrequent option - the app is in beta so users are trying out everything. This is a music practise journal, so creating new things to practise happens every so often (and is definitely needed when you start out using the app), but deleting them is not so frequent.
Drew's remark is always your first consideration. All other things being equal, I'm not a fan of making deletion as easy as creation; it's a dangerous and comparatively rarer action, and the UI should reflect that fact. However, not having an explicit delete control can indeed lead to support enquiries (the same happened in MoneyWell after the minus buttons were removed). The issue is that you won't hear from the people who avoided accidental deletion by hitting a too-close-to-the-plus deletion control; those people are happy and quiet. You will, however, hear from those who can't immediately find a button to click for deletion, even though almost all of Apple's applications have no such control.
If you feel that you need explicit UI for deletion, I think you can find a middle ground. The problem with deletion controls is accidental triggering, and the conventional "solution" to that problem is a confirmation alert. The problem with that is how intrusive and jarring they are, because they're modal. iPhone OS can teach us a lesson here: you can make confirmation entirely contextual and non-modal.
Examples are row-deletion (swipe to put the row into its "are you really sure you want to delete?" state, which visually tends to slide a red Delete button into view), then interact again (by tapping Delete) to actually confirm the action. There's a similar model on the App Store whereby tapping the price button changes it into a Purchase button; it's essentially an inline, non-modal confirmation. The benefit is that if you tap anywhere else (or perhaps wait a while), the control returns to its normal state on its own - you don't need to explicitly dismiss it before continuing work.
Perhaps that sort of approach (non-modal change as a sort of inline confirmation) can get rid of the support queries by making deletion controls explicit, but also patch up some of your reasonable concerns about intrusive confirmation.
I would say this depends on how important deletion is to the particular task. Is it something that the user has to do often, or very rarely. If it is rare, delete should just be left as an Edit menu option, and perhaps as backspace (Why cmd-backspace? If you can just have backspace, you probably won't get as many queries.)
As with everything in interface design, my take is to apply an 80-20 rule. If something belongs to the 20% of most used functionality, it should be exposed directly in the interface. If it is in the other 80%, you can hide it deeper (eg in a menu, action menu etc).
A + button is definitely in the top 20% --- you can't do anything without it --- whereas a delete is usually not a common operation, and is destructive, so can probably better be hidden away a bit.
The usual solution to this problem is to put the [+] and [-] buttons next to each other (see, for example, the Network pane in System Preferences). I generally find those buttons large enough that I don't hit the wrong one by mistake, although I can see that potentially being a problem.
If that option doesn't suit you, maybe take inspiration from Safari: put an 'x' inside the selected (or hovered) item.
Since your app supports undoing of deletion, I would suggest that you err on the side of making deleting stuff easy (at the expense of making it too easy) and make it obvious that these mistakes are easily undo-able. GMail does a decent job of that.
HTH.
How frequently is delete needed? Does the data and the user's expectation encourage deleting this data often? (is it a list of tasks, for example)? If so i'd certainly include a contextual action menu, even if Delete was the only option.
Cmd + Backspace may be a little unusual for people too - I know it's used in other places on OSX, but those places also provide context menus to expose the delete - i'd be surprised is every user knows about Cmd + Backspace, so i'd probably change it to Backspace (you do have undo support, so you're covered there).
Finally, and hopefully I don't sound like a git, but it suggests that the built-in help doesn't offer enough guidance on this - might be worth revising it?
Matt gave pretty much the same answer I was going to write.
Note that when you delete the object, you should animate it away: this provides valuable visual feedback: the animation (about 1/3 of a second is good) is long enough to catch the user’s eye, and they’ll see the object disappearing. If the object just disappeared without animating, the user would notice that something had changed instantaneously in the list, but would be less certain what it was. The animation reinforces the meaning of the delete button in the user’s mental model.
I'm using VS 2008 and I notice a lot of wasted screenspace, such as the Error List upgrade I propose below. Is there any way to change the way panels are rendered to make them smaller? Or maybe some addon to VS that does what it does but with compacted panels.
Current Error List - Only 2 errors visible
Future - 6 errors visible in same space
I don't know how to customize panels the way you're asking, but I've found my own way of dealing with panels I don't need all the time.
I keep panels like errors, search results or output set to Auto-Hide. That way they can take up a pretty decent amount of space when I want to see the lists, but they're not visible at all the rest of the time. Works well for me. When I'm not using one of those panels the only windows that are visible are the solution explorer and the code editor.
If you can afford more monitors, get them. You won't have to worry about auto-hide and you'll have enough room for it all.