Context:
OS X Application implemented in Cocoa/ObjC
Xcode 6.1
Base SDK: 10.0
Deployment Target: 10.8+
Question:
In my app, I have a custom NSView subclass which implements NSDraggingSource. I'm using the new NSDraggingSession-based API (not the old deprecated one).
I have my dragging source fully implemented, no problems.
I am already implementing:
-[NSDraggingSource draggingSession:movedToPoint:]
I would like to additionally do some hit detection within this method and depending on the results of that hit test, possibly cancel the current drag session programmatically.
So: What is the best way to cancel/terminate the current NSDraggingSession programmatically? (preferably from -[NSDraggingSource draggingSession:movedToPoint:])
It might be nice to also be able to specify the NSDragOperation upon termination too.
Notes:
I've tried calling -[NSResponder cancelOperation:] on my custom view, thinking this might have something to do with dragging sessions, but that doesn't work. I get an exception with unrecognized selector.
I DO NOT need help doing hit detection.
I DO NOT need help implementing NSDraggingSource in general.
Related
Lately I have been playing around with the bluetooth framework and grew a strong enough knowledge to start building an application. The only problem is that all the examples I found and all the practice I have made consist in putting the core bluetooth core code inside the same file as the UIView with which the user is interacting.
I would like my future application to have multiple views in which the BLE scan occurs on the background. I initially thought about creating an object with a name similar to bleDeviceFinder and pass this object through each view. However, after thinking about it I realised that if I want something to happen in the current view I need the function didDiscoverPeripheral to have direct access to the UIView objects which it is supposed to affect.
I know it is probably a stupid question, what would be the best way to do so? I was thinking maybe to set and alert and subscribe every view to that alert; is this a good solution?
A quasi singleton BTLEManager that you pass around in the app. It sends NSNotifications for events like discovery, and your ViewControllers observe these notifications. The truth (i.e. list of discovered devices) stays in BTLEManager. Once a viewController has received such a notification it asks the BTLEManager for the list of current devices and then the viewController changes your views accordingly. The Views should never talk to the BTLEManager directly.
That's how I would do it.
I have an app where I allow the user to drag/drop some data from an NSView, with a custom drag image under the cursor.
I just updated to the Xcode 6 beta, and now my drag/drop code won't compile. This is because Apple has deprecated the following NSView method:
dragImage:at:offset:event:pasteboard:source:slideBack:
Fine, but what am I supposed to use instead? All the Apple documentation I've found still merrily recommends the deprecated method.
There is also a "dragFile:" method, however my NSView represents AV data, and it's unsuitable to write a large new file to disk every time the user begins a drag. The user may well to abort the drag, possibly multiple times in rapid succession.
What is the new way to initiate a drag operation with a custom icon?
Thanks to Kyle Sluder on Apple's Dev forums for alerting me to this. It turns out the replacement is
NSView beginDraggingSessionWithItems: event: source:
I used to disable current view while a method is running in the background(may be an API Call) asynchrnolsly.But as per the Human Interface Guidline I understood that disabling the View while a method runs in the BG, is not a right way.So If I need to avoid user accessing different IBActions while some thing performs in the back ground what is the best method?
I have checked the restorable option on my NSWindow
When I move my application and change its size and close/reopen my application it sets the window size and position to the last size and position
but this doesn't happen on every computer where i test it. it only happens to a few computers
they don't have special settings regarding the resume.
Does anybody have any experience with this?
But this doesn't happen on every computer where I test it. It only
happens to a few computers. They don't have special settings regarding
the resume.
Actually, they do. Take a look into the System Preferences > General pane. There should be an option named “Close windows when quitting an application” which is responsible for the restoration behavior. Additionally, in OS X Mountain Lion, Apple changed default behavior and now the app restores its state only when you quit using Command-Option-Q.
So, you probably should check which OS X version is installed on another Mac, and which preference is selected in the General pane. Hope this helps!
One thing you should know is that checking the "Restorable" option in IB only changes a window property. The actual restoring and saving is in your hands.
First, you have to conform to the NSWindowDelegate protocol and implement the
-window:willEncodeRestorableState:state and -window:didDecodeRestorableState:
methods that encode and decode your window properties (For example your windows frame, which you obviously get by calling [myWindow frame]).
You also need to conform to the NSWindowRestoration protocol and implement +restoreWindowWithIdentifier:state:completionHandler:. (make sure you set your class to restoration class, with the setRestorationClass method)
For additional, more in depth, information, you can visit this Apple Documentation document here.
If all you want is to restore the window's frame use setFrameAutosaveName:.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/WinPanel/Tasks/SavingWindowPosition.html
I have a general question for Xcode programming and the usage of the Xcode tools.
I am quite new (4 months) in iOS development and I almost never used the Interface Builder for my purposes. I always created instances programatically. My question is basically if you think i should get used to work with IB or should/can i proceed like i do now?
If you are fine with defining your UI programmatically, then I do not see any issues with that.
Interface Builder allows you to "graphically" define your interface, and this can be an invaluable tool for playing with your UI prototypes, but apart from that there is nothing that you can do in IB that you cannot do programmatically.
In my case, I see that it depends on the kind of UI that I design. When I need a pretty basic UI, the IB is unbeatable for me. On the other hand, when my UI tries to be a bit custom, then I prefer doing everything programmatically.
An interesting point is that you could use IB to design your UI, deciding on sizes and positions of your elements, and the create it programmatically.
Yes you should use IB, basically xcode having IB for ease of development, no need to setting controlls by using coordinates and each time see their visibility by running the app.
just drag and drop and at the time of making the views, you can see hows your screen going to look.
Also using IB is not a typical task so,start development using IB.