I'm using this (older) framework: https://github.com/rastersize/CDEvents to track changes on the filesystem.
For some reason the flag is always event.isGenericChange. On the FSEvent level this would be the kFSEventStreamEventFlagNone (code 0).
Maybe this has something to do with the framework being older and missing something that changed? I'm not getting any build/test warnings/errors (installed through CocoaPods).
I'm using this code through a delegate:
- (void)viewDidLoad {
[super viewDidLoad];
self.events = [[CDEvents alloc] initWithURLs:#[[NSURL URLWithString:#"/Users/username/Desktop/"]]
delegate:self
onRunLoop:[NSRunLoop currentRunLoop]
sinceEventIdentifier:kCDEventsSinceEventNow
notificationLantency:((NSTimeInterval)0.25)
ignoreEventsFromSubDirs:NO
excludeURLs:#[]
streamCreationFlags:kCDEventsDefaultEventStreamFlags];
}
- (void)URLWatcher:(CDEvents *)URLWatcher eventOccurred:(CDEvent *)event {
NSLog(#"Event: %ld", (unsigned long)event.flags);
}
I tried all actions (rename, edit, remove, create, change meta-data, change rights, etc.) and it's always genericChange.
Fixed it by adding the kFSEventStreamCreateFlagFileEvents flag. Because I'm using CocoaPods I'd rather not adjust the source code so instead of placing streamCreationFlags:kCDEventsDefaultEventStreamFlags using these manual flags:
(kFSEventStreamCreateFlagUseCFTypes |
kFSEventStreamCreateFlagWatchRoot |
kFSEventStreamCreateFlagFileEvents)
Guess it has to do with some radical changes Apple did sometime in the past. I'm now getting the correct flags and also the full path to a file (not only it's directory).
Related
"[GCController controllers]" does not contain any controllers that were connected prior to application launch
TLDR;
I am trying to implement gamepad input on macOS using the Game Controller Framework. When invoked in my code, [GameController controllers] always returns an empty list until new controllers are connected. It never reflects gamepads connected to macOS prior to application launch, except if you disconnect them and reconnect them while the app is running. Does anyone know what I need to do to make controllers populate with pre-launch connections?
Full question
Now that Apple has added support for Xbox and Playstation controllers to the GameController framework, I'm trying to use it for gamepad input on a C++ game engine I'm developing. I'm using the framework instead of IOKit in order to "future-proof" my games to support additional controller types in the future, as well as to simplify my own input handling code.
Like many other game engines, I've foregone using NSApplicationMain() and nib files in favor of implementing my own event loop and setting up my game window programmatically. While my "Windows style" event loop appears to be working correctly, I've discovered that [GCController controllers] does not. The array it returns is always empty at launch, and will only ever reflect controllers that are connected while the game is running. Disconnecting a pre-connected controller does not trigger my GCControllerDidDisconnectNotification callback.
Here is a simplified version of my event loop:
int main(int argc, const char * argv[])
{
#autoreleasepool
{
// Create application
[NSApplication sharedApplication];
// Set up custom app delegate
CustomAppDelegate * delegate = [[CustomAppDelegate alloc] init];
[NSApp setDelegate:delegate];
// Activate and launch app
[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
[NSApp setPresentationOptions:NSApplicationPresentationDefault];
[NSApp activateIgnoringOtherApps:YES]; // Strictly speaking, not necessary
[NSApp finishLaunching]; // NSMenu is set up at this point in applicationWillFinishLaunching:.
// Initialize game engine (window is created here)
GenericEngineCode_Init(); // <-- Where I want to call [GCController controllers]
NSEvent *e;
do
{
do
{
// Pump messages
e = [NSApp nextEventMatchingMask: NSEventMaskAny
untilDate: nil
inMode: NSDefaultRunLoopMode
dequeue: YES];
if (e)
{
[NSApp sendEvent: e];
[NSApp updateWindows];
}
} while (e);
} while (GenericEngineCode_Run()); // Steps the engine, returns false when quitting.
GenericEngineCode_Cleanup();
}
return 0;
}
I've confirmed that even when using [NSApp run] instead of [NSApp finishLaunching], the behavior is the same. As best as I can tell, the problem is that there's something NSApplicationMain() does that I'm not doing, but that function is a black box -- I can't identify what I need to do to get controllers to populate correctly. Does anyone know what I'm missing?
The closest thing I could find to an explanation of this problem is this answer, which suggests that my app isn't getting didBecomeActive notifications, or that at the least, the private _GCControllerManager isn't getting a CBApplicationDidBecomeActive message. I'm not a professional macOS developer, though: I don't know if this actually applies to my situation, or how I'd go about correcting the problem if it does.
After a huge amount of time searching, I found the answer on my own. It turns out that my code wasn't the problem -- the problem was that my Info.plist file was having its CFBundleIdentifier value stripped out due to a problem with my build system. It appears that the Game Controller Framework needs the bundle identifier to correctly populate [GCController controllers] at launch. While a missing CFBundleIdentifier would have been a problem anyway, as a Windows person it didn't occur to me that the identifier might be used for things besides the App Store, so I let it slide until now.
If someone else has this problem, make sure that CFBundleIdentifier isn't missing or empty in Info.plist in your assembled app bundle. In my case with Premake, I had to manually set PRODUCT_BUNDLE_IDENTIFIER with xcodebuildsettings so that $(PRODUCT_BUNDLE_IDENTIFIER) would get properly replaced in Info.plist.
I'd like to know whether anyone has a suggestion for an alternative to using runningApplications, as something like the following appears to be leaking memory:
https://openradar.appspot.com/24067155
https://github.com/bradjasper/NSRunningApplicationMemoryLeaks
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
[NSTimer scheduledTimerWithTimeInterval:10.0 target:self selector:#selector(checkApps:) userInfo:nil repeats:YES];
}
- (void) checkApps : (id) sender {
#autoreleasepool {
NSArray *appsArray = [[NSWorkspace sharedWorkspace] runningApplications];
for (NSRunningApplication *a in appsArray) {
NSLog(#"%#", [a localizedName]);
}
}
}
Is the only option to wait until Apple provides a solution? I'm working in a sandboxed environment, so some NSTask-based alternatives may not work. Thanks in advance for any ideas.
The answer to your question, is there another sandboxable option?: is no. This is how you're supposed to look for running applications.
You might try KVO (on the sharedWorkspace's runningApplications property) instead. The documentation suggests doing just that rather than what you're doing:
Instead of polling, use key-value observing to be notified of changes to this array property.
After a fair amount more troubleshooting, I eventually found that the memory leak issue only occurs when building/running the app/project from Xcode (Version 7.2 (7C68)). If I build the project, and then head into Finder and manually launch the app built, memory allocation appears to stabilize.
I don't have Zombie objects enabled, and I've made no changes from the default project settings. This must be a bug within Xcode.
I'm trying to figure out how to limit my NSDocument based application to one open document at a time. It is quickly becoming a mess.
Has anyone been able to do this in a straightforward & reliable way?
////EDIT////
I would like to be able to prompt the user to save an existing open document and close it before creating/opening a new document.
////EDIT 2
I'm now trying to just return an error with an appropriate message if any documents are opening -- however, the error message is not displaying my NSLocalizedKeyDescription. This is in my NSDocumentController subclass.
-(id)openUntitledDocumentAndDisplay:(BOOL)displayDocument error:(NSError **)outError{
if([self.documents count]){
NSMutableDictionary* dict = [NSMutableDictionary dictionaryWithObject:#"Only one document can be open at a time. Please close your document." forKey:NSLocalizedDescriptionKey];
*outError = [NSError errorWithDomain:#"Error" code:192 userInfo:dict];
return nil;
}
return [super openUntitledDocumentAndDisplay:displayDocument error:outError];
}
It won't be an easy solution, since it's a pretty complex class, but I would suggest that you subclass NSDocumentController and register your own which disables opening beyond a certain number of documents. This will allow you to prevent things like opening files by dropping them on the application's icon in the dock or opening in the finder, both of which bypass the Open menu item.
You will still need to override the GUI/menu activation code to prevent Open... from being available when you have a document open already, but that's just to make sure you don't confuse the user.
Your document controller needs to be created before any other document controllers, but that's easy to do by placing a DocumentController instance in your MainMenu.xib and making sure the class is set to your subclass. (This will cause it to call -sharedDocumentController, which will create an instance of yours.)
In your document controller, then, you will need to override:
- makeDocumentForURL:withContentsOfURL:ofType:error:
- makeUntitledDocumentOfType:error:
- makeDocumentWithContentsOfURL:ofType:error:
to check and see if a document is already open and return nil, setting the error pointer to a newly created error that shows an appropriate message (NSLocalizedDescriptionKey).
That should take care of cases of drag-and-drop, applescript,etc.
EDIT
As for your additional request of the close/save prompt on an opening event, that's a nastier problem. You could:
Save off the information (basically the arguments for the make requests)
Send the -closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo: with self as a delegate and a newly-created routine as the selector
When you receive the selector, then either clear out the saved arguments, or re-execute the commands with the arguments you saved.
Note that step 2 and 3 might need to be done on delay with performSelector
I haven't tried this myself (the rest I've done before), but it seems like it should work.
Here's the solution I ended up with. All of this is in a NSDocumentController subclass.
- (NSInteger)runModalOpenPanel:(NSOpenPanel *)openPanel forTypes:(NSArray *)extensions{
[openPanel setAllowsMultipleSelection:NO];
return [super runModalOpenPanel:openPanel forTypes:extensions];
}
-(NSUInteger)maximumRecentDocumentCount{
return 0;
}
-(void)newDocument:(id)sender{
if ([self.documents count]) {
[super closeAllDocumentsWithDelegate:self
didCloseAllSelector:#selector(newDocument:didCloseAll:contextInfo:) contextInfo:(void*)sender];
}
else{
[super newDocument:sender];
}
}
- (void)newDocument:(NSDocumentController *)docController didCloseAll: (BOOL)didCloseAll contextInfo:(void *)contextInfo{
if([self.documents count])return;
else [super newDocument:(__bridge id)contextInfo];
}
-(void)openDocument:(id)sender{
if ([self.documents count]) {
[super closeAllDocumentsWithDelegate:self
didCloseAllSelector:#selector(openDocument:didCloseAll:contextInfo:) contextInfo:(void*)sender];
}
else{
[super openDocument:sender];
}
}
- (void)openDocument:(NSDocumentController *)docController didCloseAll: (BOOL)didCloseAll contextInfo:(void *)contextInfo{
if([self.documents count])return;
else [super openDocument:(__bridge id)contextInfo];
}
Also, I unfortunately needed to remove the "Open Recent" option from the Main Menu. I haven't figured out how to get around that situation.
My application allows the user to rename documents that are currently open. This is trivial, and works fine, with one really annoying bug I can't figure out. When a file is renamed, AppKit (kindly) warns the user the next time they try to save the document. The user says "OK" and everything continues as normal. This makes sense when something external to the application changed the document, but not when it was actually done by the document itself.
The code goes something like this:
-(void)renameDocumentTo:(NSString *)newName {
NSURL *newURL = [[[self fileURL] URLByDeletingLastPathComponent]
URLByAppendingPathComponent:newName];
NSFileManager *fileManager = [NSFileManager defaultManager];
[fileManager moveItemAtURL:[self fileURL] toURL:newURL];
NSDictionary *attrs = [fileManager attributesForItemAtPath:[newURL path] error:NULL];
[self setFileURL:newURL];
[self setFileModificationDate:[attrs fileModificationDate]];
}
One would think that expressly setting the new URL and modification date on the document would be enough, but sadly it's not. Cocoa still generates the warning.
I've tried changing the order (setting the new URL on the document, THEN renaming the file) but this doesn't help.
I've also tried a fix suggested by a user on an old post over at CocoaDev:
[self performSelector:#selector(_resetMoveAndRenameSensing)];
Even this does not stop the warning however, and I'm guessing there has to be a proper way to do this using the documented API. How does Xcode handle things when a user clicks a file on the project tree and renames it to something else. It doesn't warn the user about the rename, since the user actually performed the rename.
What do I need to do?
There isn't much on this in the main docs. Instead, have a look at the 10.5 release notes: http://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKitOlderNotes.html%23X10_5Notes under the heading "NSDocument Checking for Modified Files At Saving Time"
(In the case of Xcode, it has a long history and I wouldn't be surprised if if doesn't use NSDocument for files within the project)
It is worth noting that moving a file does not change its modification date, so calling -setFileModificationDate: is unlikely to have any effect.
So one possibility could be to bypass NSDocument's usual warning like so:
- (void)saveDocument:(id)sender;
{
if (wasRenamed)
{
[self saveToURL:[self fileURL] ofType:[self fileType] forSaveOperation:NSSaveOperation delegate:nil didSaveSelector:nil contextInfo:NULL];
wasRenamed = NO;
}
else
{
[super saveDocument:sender];
}
}
Ideally you also need to check for the possibility of:
Ask app to rename the doc
Renamed file is then modified/moved by another app
User goes to save the doc
At that point you want the usual warning sheet to come up. Could probably be accomplished by something like:
- (void)renameDocumentTo:(NSString *)newName
{
// Do the rename
[self setFileURL:newURL];
wasRenamed = YES; // MUST happen after -setFileURL:
}
- (void)setFileURL:(NSURL *)absoluteURL;
{
if (![absoluteURL isEqual:[self fileURL]]) wasRenamed = NO;
[super setFileURL:absoluteURL];
}
- (void)setFileModificationDate:(NSDate *)modificationDate;
{
if (![modificationDate isEqualToDate:[self fileModificationDate]]) wasRenamed = NO;
[super setFileModificationDate:modificationDate];
}
Otherwise, your only other choice I can see is to call one of the standard save/write methods with some custom parameters that prompt your document subclass to move the current doc rather than actually save it. Would be trickier I think. Perhaps define your own NSSaveOperationType?
With this technique the doc system should understand that the rename was part of a save-like operation, but it would need quite a bit of experimentation to be sure.
Much inspired from #Mike's answer, I got the "moved to" message not to show up anymore by re-routing NSSaveOperation to NSSaveAsOperation. In my NSDocument subclass:
I overload saveDocumentWithDelegate:didSaveSelector:contextInfo: to determine the save URL and document type (assigning those to self); if the old fileURL exists, I move that to the new location
Inside saveDocumentWithDelegate:didSaveSelector:contextInfo: I redirect the call to [self saveToURL:self.fileURL ofType:self.fileType forSaveOperation:NSSaveAsOperation completionHandler: ...] instead of [super saveDocumentWithDelegate:didSaveSelector:contextInfo:]
This works for me.
Isn't it possible to programmatically answer the question for the user?
Or you can save immediately after renaming, this way a user gets every answer in one go.
I see that this problem is up and running for some time, so telling you to read the reference won't do any good i guess..
Hope i helped a little bit although it doesn't fix your problem directly
I am developing an application which uses both video recording and photo shoting.So i want to show buttons according to os for this i implement these methods.It's working fine when i build for OS 3.1 but when i build for OS 3.0 it shows errors
here are the methods
if ([self videoRecordingAvailable])
{
imagePickerController.sourceType = UIImagePickerControllerSourceTypeCamera;
imagePickerController.allowsImageEditing = YES;
imagePickerController.allowsEditing = YES;
imagePickerController.videoQuality = UIImagePickerControllerQualityTypeHigh;
imagePickerController.videoMaximumDuration = 60.0f; // Length for video recording in seconds
imagePickerController.mediaTypes = [NSArray arrayWithObjects:#"public.movie", nil];
imagePickerController.showsCameraControls=YES;
[self.navigationController presentModalViewController:imagePickerController animated:YES];
}
- (BOOL) videoRecordingAvailable
{
if (![UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypeCamera]) return NO;
return [[UIImagePickerController availableMediaTypesForSourceType:UIImagePickerControllerSourceTypeCamera] containsObject:#"public.movie"];
}
the errors are
error: request for member 'allowsEditing' in something not a structure or union
error: request for member 'videoQuality' in something not a structure or union
error: 'UIImagePickerControllerQualityTypeHigh' undeclared (first use in this function)
(Each undeclared identifier is reported only once for each function it appears in.)
error: request for member 'videoMaximumDuration' in something not a structure or union
error: request for member 'showsCameraControls' in something not a structure or union
how do i solve this issue?
The problem is that the video capture has been added in 3.1, which means that the image picker from 3.0 does not support any of the video properties and methods (see the documentation and pay attention to the Availability sections).
As for the solution, I guess you could try using the message syntax instead of the dot syntax:
[picker setShowsCameraControls:YES];
This will give you warnings though (when compiled for 3.0 and older), and you have to be careful not to do it on older devices, because you’ll get an unknown selector exception. Or you can call the selector dynamically, which will get rid of the warnings and you can also check if the selector is supported first:
SEL msg = #selector(setShowsCameraControls:);
if ([picker respondsToSelector:msg])
[picker performSelector…];
There are already several questions about writing for different OS versions.
Responding to comments: I think the main problem is that you are blindly pasting the code without understading it. Don’t do that. Sit and think about what the code does, until you understand each and every line. Now to explain your problem more thoroughly:
The Image Picker in 3.0 has no video controls, since it can’t record video. Therefore when you try to compile a code such as picker.showsCameraControls, the compiler complains: There is no showsCameraControls property in the Image Picker class, that has only been added in 3.1.
But there is a way around that, you can use the message syntax ([foo setBar:…]) instead of the dot syntax (foo.bar=…). If the foo object has no setBar method, the compiler will warn you, but the code will compile. Now let’s use the message syntax to set the camera controls:
[picker setShowsCameraControls:YES];
When you compile this code for 3.1, it will compile without warning and run without error. When you compile for 3.0, you will get a warning from the compiler and if you run the code, it will fail (since there really is no showsCameraControls property). But that is not a problem, since you can only decide to run the fragile code if the OS supports it:
BOOL videoSupported = [picker respondsToSelector:#selector(setShowsCameraControls:)];
if (videoSupported) {
[picker setShowsCameraControls:YES];
// set all the other video properties
} else {
// do what makes sense without video support
}
This will work, but you’ll still get compiler warnings on 3.0. Now it depends on your default build target. If you build for 3.1, the warnings will disappear and the code should work on 3.0 just fine.