Unfortunately this is hard for me to test myself because I have yet to get a Magic Mouse of my own, but I've been told by my testers who do have a magic mouse that momentum scrolling isn't working in my app. I've not subclassed NSScrollView, but scrollview's document view is all custom. I have not overridden scrollWheel: anywhere, either, and yet momentum apparently just isn't working. I'm not even sure where to begin. I thought it'd just send scrollWheel events and things would take care of themselves. (Scrolling with a wheel or on the MBP trackpad works as expected.) Obviously I must somehow be doing something that's stopping it, but I don't even know where to begin. Thoughts?
I figured this out awhile ago and the problem was that on scroll, I was doing a lot of fancy view manipulation somewhat like how on the iPhone the UITableView adds and removes views as they scroll on and off screen. This worked great for performance - but the more I got into OSX programming, the more I realized this was wrong for OSX (but the right idea of iPhone).
Anyway, what's really going on, it seems, is that when you do something like a wheel scroll, the scroll event is sent to the view that's under the mouse cursor and then it ripples down the responders/views until it gets somewhere that handles it. Normally this isn't a problem, but with momentum scrolling the OS is really just sending ever smaller scrollWheel events to the view that was under the cursor at the time the momentum started. That means if the view is removed during the course of scrolling (because it scrolls off screen or something), it breaks the chain and the momentum stops because the view that's still getting the scrollWheel messages is no longer in the view hierarchy.
The "simple" fix is to not remove the view that got the last scrollWheel event - even if it's off screen. The better fix (and the one I went with) is to not try to use NSViews like they are UIViews and instead just draw the content using drawRect. :) Not only is that about a billion times faster, it Just Works(tm) with momentum scrolling because it's how OSX expects things to be done.
Repeat after me: OSX is not iPhoneOS.. :P
Odd scrolling behavior can occur when you don't set the Line Scroll and Page Scroll properties of the NSScrollView itself.
Beyond that, you're quite simply going to have to get a Magic Mouse - easily said or not :-) - to test this yourself or post the entire code of your custom view as well as the xib containing it. There's no way others can offer you more than guesses (like the above) without it.
Related
So anyway, as normal, my app is working pretty awesome in iOS5.
Then came iOS6 with new Maps app, and it no longer function as it supposed to. (insert Roll Eyes icon here)
I have a MapView with the following user interactions:
User can zoom in/out by pinching.
User can double tap to drop a pin.
This is no longer the case with iOS6, No.2 does not work anymore.
It seems the new MapView no longer detects double tapping directly.
If I disable zooming (in IB) then it works.
So, how can I make this work?
Or perhaps it is better to change the operation from "double tap" to "long tap"?
Any suggestions or how to make it work while enabling zoom
is appreciated.
Thanks yall.
What the heck.
Nobody answers this, so I'm going to answer for myself.
What I did is a simple hack.
implement the touchesBegan delegate in the same viewcontroller.
in there, detect single touch, and if detected a single touch, disable the MapkitView zooming. Hence the TapGestureRecognizer implemented for the MapKitView will response.In this
case a double tap will response as I needed it to.
And when a 2 touches detected (two fingers on the screen), enable back the zooming of the MapkitView.
This works pretty ok.
Hope this helps other people who is facing the same problem with iOS6 Maps app.
Surprisingly, this still works ok for Google Maps (prior iOS6).
Thanks.
I have experienced some trouble with the Slider control on WP7. When I am dragging it, it will only drag a little bit, and then it goes back to where it started. If I let go of the slider quickly, then it goes a little further. E.g. if you want to drag it from the start to the end, you will have to quickly drag many times. What I want is a smooth slider, which follows my finger and stops until I release my finger, and it should stop where my finger is. Any way to get this the way I want?
I am also having a bit of trouble customizing it visually. How can I resize it and put it in the middle of the parent controller? Now, it puts itself in the top section, even though Vertical option is set to bottom..
How do you know where your finger are? Your finger is obviously going to be larger than the Slider itself.
The default slider is perfectly smooth. So all you're complaining about is the level of precision. You won't get 100% precision with a touch-interface that depends on the calibration of touch-input on your touch-screen.
Either you make the slider go in steps (which isn't smooth), or you accept the lower level of precision.
I finally solved the issue. The problem was that you can not(for some odd reason) have a slider and a gesturelistener at the same page. I removed the gesturelistener and the slider was smooth. I will not call that bad programming skills, this is definitely a bug, because the gesturelistener was on a totally different control in the page.
Although I know of a solution to this problem, I am interested if someone can explain this solution to me. I also wanted to get this out there because I could not find any mention of this problem online, and it took me several hours over several days to track down. I have an NSTableView behaving strangely regarding redraws and its selection. The problem looks like this:
Table contents fades in, instead of appearing instantly upon it's appearance on screen. When scrolling through the contents, the newly appearing rows also fade in. When you make a selection (single or multiple), and scroll it off screen, then make another selection (that should replace, not add-to first selection), the first selection does not get cleared properly. If you scroll back to it, it is still there, in addition to your new selection. This is a display-update problem, not selection problem - i.e. your new selection is valid, it is just displayed wrong.
I tracked this through the NSArrayController I was binding to, the underlying Array, sorting, all the connections, and settings, etc., but all that has nothing to do with it.
What solved the problem was:
In the View Effects (right-most) Inspector, uncheck "Core Animation Layer" for the Window's main view.
Can anyone explain what is happening here, and perhaps improve upon the solution ?
It looks like Core Animation and NSTableView aren't getting along so well. The "fading" effect is a by-product of the way core animation works. When you have core animation in one view, it is also enabled in all of that view's subviews.
I don't recommend using core animation on the Mac unless absolutely necessary, because some interface elements (NSTextView and NSTableView, for example) aren't compatible with it. iOS has much better support for table views and such using core animation, mainly because it was designed with core animation in mind.
I know that some more simple UI elements are compatible (NSTextField and NSButton, for example).
If you absolutely need core animation in the rest of the window, put all the other views in a subview of the content view, while leaving the table view directly in the content view. You can then enable Core Animation in the other view.
Commenters, feel free to add to the list of what is and isn't compatible.
I have been trying to create a simple swipe transition. However buttons seem immune to any CAAnimation that crops.
I am trying to get it so that a bar moves across the screen and as it goes over the button it removes the part it has just gone over.
I have tried bounds.width, size.x and many other key-value paths to achieve the affect but I haven't got what I wanted. It just relocates the text which always remains entirely visible
I have also tried changing the UIButton to a UIImage but the text does not seem to print on a UIImage.
I tried using masks too but I have heard they should be used as infrequently as possible as they consume the phones resources. I didn't really get very far with this either anyway as I hadn't used them much before.
I also tried placing it in a container view and then change the dimensions of that but again all of the text remained entirely visible.
I know I could have a view hide the button but I am trying to reveal the view behind as the bar swipes.
Does anyone have any suggestions of how to achieve a swipe transition on a UIButton?
Help would be much appreciated.
Thanks
I think what you're looking for really is a mask. See the tutorial here:
http://iosdevelopertips.com/cocoa/how-to-mask-an-image.html
What I'd do in your situation is create a custom UIButton class, and add a mask as in the tutorial, then animate the position of the mask. Slide the mask of, nothing shows. Slide it on, part shows until the whole thing is visible.
Edit: I haven't really heard anything about hogging resources, especially since it appears to be simple core graphics.
I'm working on a app in which I used a listbox inside a pivot control just like the outlook app does. The problem is sometimes when I scroll the list, a swipe gesture is triggered and it goes to another pivot item. This is very annoying, and it seems doesn't happen to the outlook app. Am I doing something wrong? How do I fix it? Thanks a lot.
If you're just using the default controls in the default way then you're not doing anything wrong in your code.
You haven't said if you're getting this on the emualtor or on an actual device. I find I sometimes do this on the emulator if holding the mouse at a slight angle or on an actual device if holding that in a funny way (such as when lying down).
Whether you scroll the listbox or the pivot will depend on whether your finger (or mouse-if using the emulator on a non touch-screen PC) first moves vertically or horizontally after first touching the screen. In my experience the scenarios described above can lead to this not always working as expected but I've never seen an issue with this on a real device being held in one hand and scrolled using a thumb.