I created a simple scroll view that has many CCMenu nodes. The scroll is working correctly as long as I don't drag the area above the menus (since it has higher priority).
So I solved this issue by registering a mouse event as follows:
[[CCEventDispatcher sharedDispatcher] addMouseDelegate:self priority:INT_MIN+1];
The scrolling works with this fix but the CCMenu selectors are never fired since the scroller has a higher priority.
How can I solve this issue by getting the layer to always detect mouse events as well as CCMenu items working with tapping only (i don't want them to work on dragging)?
Please note that I am working on OSX and cocos2d 2.0.
The 'temporary' solution that worked for me was changing CCMenu to CCSprite and manually check for mouse events in ccMouseUp.
Related
Alright here is my issue. I have a Pivot view. Inside that pivot view a scroll viewer containing many stack panels and grids. On some of the grids I have MouseButton Up Events. What is happening is if I flick the scroll it scrolls as expected but when I release my finger most of the time it fires off the event from mousebutton up. Because technically I let up. The problem is these grids completely fill the screen so finding an area without a mousebutton up to scroll is near impossible. What I want to happen is if the user flicked to scroll I would ideally like it to ignore the mousebutton up event. It does this successfully sometimes but pretty rarely and I have noticed I have to flick pretty fast for it to work as expected.
Any ideas on how to prevent this activity. I assume there is as Listboxes work perfect.
i think u should use windows phone toolkit GestureListener to recognize flick event
I ended up setting a bool for when the scrollviewer was scrolling and based on that allowing the mouseup action to run my code. Here is the the site I used to implement the bool based on scrolling status.
http://blogs.msdn.com/b/ptorr/archive/2010/07/23/how-to-detect-when-a-list-is-scrolling-or-not.aspx
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.
Got an NSOutlineView that is configured in the controller's awakeFromNib, with a datasource and autosaved expanded nodes.
All working like a charm.
The problem is that somewhere, somebody is saving the state of the scroll position, too.
This means that at launch of the app, the outline view can appear scrolled to the bottom - if that was how the user left it last (this is on Lion if it matters).
What is the best way to open the app with the outline view scrolled to the top? Preferably in awakeFromNib, or at least so the user won't be seeing a scroll movement.
I recently started having problems with my NSOutlineView being scrolled down (so that I couldn't see my elements until I scrolled up), and I used this method :
In my applicationDidLaunch: method I use this :
[outlineView scrollPoint:NSMakePoint(0.0f, [outlineView frame].size.height)];
And it seems to work. (I also had the same problem on an IKImageBrowserView, and the same piece of code worked on that too)
Hope this solution suites you better ^^
What about [outlineView scrollToVisible:0]; ?
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.
I want to open an overlay window (pop up window) when a user selects a cell in my NSTableView similar to selecting an event in iCal. Selecting the event in iCal shows a Window to edit the event, but does so by smoothly animating the window open and adding an arrow pointing to the even in the underlying calendar. Does anyone know what is being used here? Is this a bunch of hidden/custom APIs or is this available for public use?
The editor pane appears to be a custom borderless, transparent window with a custom view (the view defines the shape and therefore the shadow it casts). Learn more here. You might even use MAAttachedWindow.
Regarding animation, it's as simple as asking the window's animator to animate the frame and the alpha value (grouping them together). You'll probably want to set everything up directly in its "start position" first (ie, while the window is off-screen, set its alpha to zero, and its frame to some smaller version so it "zooms in" a la iCal), then put it on screen and start the grouped animation:
[NSAnimationContext beginGrouping];
[[window animator] setFrame:someNewSlightlyLargerFrame];
[[window animator] setAlphaValue:1.0];
[NSAnimationContext endGrouping];
Once the grouping is ended, the animation will begin (asynchronously) and your code execution will continue. Something to think about is getting everything "staged" first (including making sure the subviews of your window are already updated beforehand, so they don't change in the middle of your animation ... unless you want them to).
So the two separate techniques you need to understand are a custom window and basic Cocoa animation.
If you're using OSX 10.7 and above, NSPopover will do the job you're looking for.
Are you talking about selecting even from a list at the bottom of iCal app?
Not sure what exactly you are referring to but there is an api for animating transformations within a timespan.
Looking at other Apple's applications, Apple's developers utilize the same api available to anyone else (mostly I guess). There is lots of stuff that can be customized and Apple customizes whatever is required until it looks right from design point of view ...