In WWDC 2019 Session 401 "What's new in Xcode", at about 6:30, the presenter shows the minimap and manages to "zoom in" it.
I couldn't find how to do this.
So how to zoom in/out of the minimap?
The presenter uses Command + + (and Command + -) to enlarge the text in the editor, which also makes the minimap bigger. As far as I know, there's no way (yet) to resize the minimap itself.
Related
When I control Seekbar in Android Wear device, red circle with x button pops up.
There is no exception or force to close dialog. If I push the button, it just terminate the app.
I wonder why red circle with x button pops up and how to avoid that.
thx!
The "red circle with x" is a DismissOverlayView, that is,
A view for implementing long-press-to-dismiss in an app.
(as described in the documentation for the Wearable UI Library).
The idea is to provide an alternative way to close an app when you specifically prevent swipe-to-dismiss (by setting android:windowSwipeToDismiss="false"), for example when swiping is an integral part of an app.
A canonical example (as explained in this Google I/O talk, around the 23:00 mark) is when displaying a ViewPager on the drawable: you may not want the user to accidentally exit the app by swiping right from the first page, but you still need some way to exit it.
So they settled on long press as the pattern for doing so.
I am trying to provide users 3 options when they zoom into a d3 chart with the mouse wheel with
d3.behavior.zoom():
zoom x and y: No modifiers
zoom x only: Hold Alt
zoom y only: Hold Shift
This works fine in firefox, but chrome is preventing my zoom from working when shift is held down. This same problem can be seen in in the d3 zoom example, if you hold down shift, the mouse wheel zoom no longer works:
http://bl.ocks.org/mbostock/3892919
I would try to use Ctrl instead of shift, but ctrl is already reserved for Browser Zoom Level.
Any idea if shift+mouse wheel is already reserved in chrome or if this something can be fixed in a future version of d3?
I had the same issue earlier today. When I investigated, I found that it was a "bug" in the d3 zoom behavior. You can find my pull request here: https://github.com/mbostock/d3/pull/1938.
If you look in the d3 repo at src/behavior/zoom.js:327, you'll see that the function is using d3.event.deltaY to get the scroll wheel delta, which is used to update the scale value. The problem is that, in Chrome, holding down the Shift key while scrolling scrolls the page horizontally, which sets deltaX instead of deltaY. Since d3 is only checking deltaY it gets a 0 value every time the Shift key is pressed.
Unfortunately I don't have a good work-around for you at the moment. In my case I may modify the d3 source file that we're using until/unless my fix is applied. Maybe someone else will have a better work-around.
We are developing an application that uses a plot to show data. We allow zooming in and out - no scrolling up and down is necessary.
Double click is used to zoom in, backspace to zoom out. + and - keys are zoom in and out
We have been unable to standardize on up and down arrows - does an up arrow typically mean zoom in or zoom out?
We are writing the code to do the zoom and it is a UI question - if there is a better site, please migrate.
Double-click to zoom and backspace to zoom out do not seem like an intuitive choice.
I'd say that +/- would make sense as zoom keys, like browsers do, but only if you combined them with a CTRL modifier.
Arrow keys are an absolute no-no for zoom. Arrow keys mean move caret, or scroll when there is no caret. Never use them for zoom.
Ctrl + + / - and Ctrl "Mouse Wheel" are the common zoom keys for web browsers.
Image viewers/editors and other specialized software might omit the Ctrl modifier if zooming is a common operation...
I'm not sure why you're allowing so many different methods for zooming in and out; consistency with other applications would suggest that if your app doesn't do scrolling, the arrows shouldn't do anything at all.
If you insist, I'd use up arrow for zooming in (making things larger) and down arrow for zooming out. Up would correspond with + and down would correspond with -, I think that would be the least confusing.
When you get around to wondering what the scroll wheel should do, check this old Joel On Software thread: http://discuss.joelonsoftware.com/default.asp?design.4.630539.38
To add onto to all these good answers... the Microsoft magnifier (the one that comes for free with the Intellipoint software, as opposed to the one that comes with the OS) uses another scheme: once the magnifier is visible, if you hold down the scroll wheel for a second, then the scroll wheel up/down begins to control the zoom in/out. Before this second timeout, the scroll wheel functions normally for the current window.
This may not be the kind of question one should ask on StackOverflow, but here's a frustration that I've been trying to find a work-around for.
When using the form designer, suppose the entire form does not fit in the space allotted to the form designer, and I have a control say, down near the bottom of the form.
If I try to re-size that control, or move it using the mouse, the work area will auto-scroll to the top of the work area. This essentially pulls my control to the top of the screen. It isn't possible to scroll with the scroll wheel while "holding" a control, and even ScrollLock does nothing for me.
Is there any way to just turn the auto-scrolling off? That way I can at least work on my form without guessing numbers to type into the properties window.
Can't you just turn off autoscroll for the form?
I think it's off by default.
Form.AutoScroll = False
I am trying to create a full-screen control panel window with many controls: buttons, sliders, list boxes, etc.
I can create a dialog window and add controls to it, but everything is scaled in dialog units. I just want to create a window in the GUI editor that is scaled in pixels, not derived units like dialog units.
I can sort of lay out all the controls in the GUI editor and then resize the window programmatically to full-screen using SetWindowPos, but the dialog window in the GUI editor will not look the same as the final product. I want it to be WYSIWIG in the GUI editor.
This is the front end for a small dedicated instrument control computer running XP. The SDK is written in MFC. I have to add and change controls frequently. The screen is small, 7" # 800 x 600, so of course I am developing the program on a different computer. I don't want the program window to change when I change monitors -- I want it fixed at 800 x 600, and I want the controls to be fixed in size and layout as well.
There must be a way -- this is more basic than the default functionality.
Thanks.
Dialog Units are based on properties of the font used by the dialog. A horizontal dialog unit is equal to 1/4th the average width of the current font.
A vertical dialog unit is equal to 1/8th the average character height of the current font.
I'd recommend using method 2 (MapDialogRect() for a 4 x 8 dialog) to figure out how many DLUs 800x600 corresponds to on your output display then make a reference form equal to that size. You can later use that reference form while you're designing.
p.s.-I'm glad Visual Studio no longer emphasizes dialog units since they were always a pain to deal with.
Thanks. I was able to make a reference form by just resizing the form manually in the GUI editor over and over again until it exactly filled the screen... No kidding that dialog units are a pain. From your response, I guess in the current Visual Studio there is a better way to do this? (This is my first experience with Windows programming).