When getNextAudioBlock is called during another File’s Playback, Is releaseResources called by Juce to stop any previous playback? If so, How would you override that?
Related
How do I override the close button action to show a confirm dialog?
Would placing code in the app delegate's
applicationWillTerminate
be the correct place for such code?
I have an app using CloudKit.
It saves way too constantly, where it causes errors trying to save to iCloud.
So I'm trying to show a dialog to confirm if the user wants to sync before quitting.
If you want to block a window from closing, the NSWindow's delegate is where it's at. Be it either the AppDelegate (which is the default for most Xcode templates) or an NSWindowController if that's how you presented your window. The method you want to implement from NSWindowDelegate is -windowShouldClose: or -windowWillClose:. If you want to prevent the closing of the window, simply return NO from -windowShouldClose:.
If you want to stop the app from quitting, you should look into NSApplicationDelegate and override -applicationShouldTerminate: and return NSTerminateCancel to prevent the app from terminating.
In short, the "should" methods allow you to prevent the action from occurring, the "will" methods are just saying that it will happen and you can deal with it.
I'm looking to differenciate a dock clic from a click on the app icon in the finder.
Can I know what called applicationShouldHandleReopen or is there another way to do it ?
applicationShouldHandleReopen:hasVisibleWindows: is sent to the application's delegate. Delegate messages are normally sent by the delegating object, which in this case would be the application object.
The application object sends that message to its delegate in order to handle the reopen-application Apple Event. So, to find the sender, install your own Apple Event handler for that event and get the sender from the event. (The sample code is in Pascal and uses Apple Event Manager, but you can translate it to Objective-C and NSAppleEventDescriptor.)
That said, what you're doing is very dubious from a UI perspective. Reopening is meant to do the same thing no matter which application is reopening you—and it is not limited to the Finder or the Dock. In the common case, it is literally the user trying to launch the app while it is already open.
It may make more sense to only do your “reopen” behavior when no windows are open. Cocoa's built-in document-based-apps support does this automatically; if you don't respond to applicationShouldHandleReopen:: or you return YES, the application tries to open a new document. You can perform the same check (it even tells you whether you have any windows open) and perform your desired behavior under the same condition.
Under Win2K(or later), by sending a Virtual-Key VK_LAUNCH_MEDIA_SELECT, can start a player.
If more than one player software installed, how to determine which one it will start?
A sample VBS code:
Wscript.CreateObject("Wscript.Shell").Sendkeys chr(&h88b5)
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx
http://msdn.microsoft.com/zh-cn/library/dd375731
VK_LAUNCH_MEDIA_SELECT
0xB5
Select Media key
VK_LAUNCH_MEDIA_SELECT is actually received by the system and translated into a WM_APPCOMMAND with lParam as APPCOMMAND_LAUNCH_MEDIA_SELECT. So theoretically, any program implementing a handler for this could be launched. This page (albeit old) lists default applications which listen for WM_APPCOMMAND:
Internet Explorer
Windows Help
DVD Player
CD Player
Media Player
Volume Control system tray applet
Obviously, only a few of those are actually applicable for APPCOMMAND_LAUNCH_MEDIA_SELECT.
However, I don't know how the translation mechanism actually works. It appears not every application will receive the translated WM_APPCOMMAND message. On my keyboard, I tried pressing the button which sends VK_VOLUME_UP. The volume goes up as expected because it is handled by the volume control system tray applet. However, I opened an instance of notepad.exe and monitored its messages with Spy++. It did not receive any message even when it was in the foreground. Curiously, VK_MEDIA_PLAY_PAUSE is received through WM_APPCOMMAND if the play/pause button is pressed as long as notepad.exe had the focus. I would test with VK_LAUNCH_MEDIA_SELECT, but I'm not actually sure what button that corresponds to (or whether my keyboard has it).
Thanks, for Mike Kwan's reply.
Through testing a lot of settings a program associated with a variety of audio files.
Finalized, this will depend on the CDA (CD Audio) files associated with which program.
If you set the default association for the CDA (CD Audio) files to Notepad or Paint or any other program, it can still send the same virtual key to open the corresponding program.
The foreground window can do whatever it wants in response to the WM_APPCOMMAND message, if it does not handle the message then shell hooks (HSHELL_APPCOMMAND) gets to handle it, if no hooks handle the message then Windows checks the AppKey key in the registry. (You can use Process Monitor to find the number for a specific key-press)
I am attempting to handle the loss of focus of my application, either by a phone call or other event, and also by the pressing of the home key.
I have tried setting a flag in the OnNavigatingFrom/OnNavigatedFrom and OnNavigatedTo event handlers but each time the app starts (either after pressing home, or something else) it always seems to be resetting the flag.
Which are the correct events I should be using in order to correctly "pause" and subsequently "resume" my application if it loses focus?
You should read the documentation about application lifecycle.
When you press the Home button, or when you receive a phone call, the application is paused.
If you pressed Home, you can then restore the application by pressing the back button.
to handle these events, in App.xaml.cs by default the methods are: Application_Activated and Application_Deactivated
Of course you can manage to store data before the pause, and restore it when application is restored.
This is called tombstoning.
What you need is described in the following links:
http://windowsphone7.vectorform.com/2010/11/16/wp7-application-lifecycle/
http://www.windowsphonegeek.com/articles/WP7-Application-Lifecycle-and-Tombstoning
Read this. This is a microsoft tutorial on how to save state.
It'll give you how to save your ApplicationData when it is tombstoned.
Basically edit the Application_Closing and Application_Activated methods in the App.xaml to save the data to the system using isolated storage.
I am familiar with iOS programming, but I don't know where to put my logic when I start a Cocoa project for OS X. Are there any good online resources for transitioning to OS X from iOS?
EDIT:
Thanks for the help so far. My main question is where my code goes in the default template.
My main question is where my code goes in the default template.
Assuming a single-window app, I make a separate custom controller to own that window, and I have the application object's delegate own that controller.
So:
The application object's delegate
Owns the custom controller.
Creates it in applicationWillFinishLaunching: (note: not Did; I change this).
Releases it (and nils out the instance variable) in applicationWillTerminate:.
Does not own the primary window (I remove that ivar and all references to it).
Responds to applicationShouldTerminateAfterLastWindowClosed: with YES, so that the user can quit the application either by specifically quitting or by closing the primary window.
May also respond to application:openFile: or application:openFiles:, typically by passing the file(s) along to the controller to import or something.
The MainMenu nib
Owns the application's delegate.
Does not contain the primary window (I remove the blank one).
The primary-window controller
Owns the primary window.
Owns the model displayed in the window.
Creates initial/empty model in init.
Loads the primary-window nib with itself as owner in init.
Closes and releases window (first) and releases model (second) and subordinate controllers (third) in dealloc.
The primary-window nib
Named similarly to the controller; e.g., “SnippetListController” for the controller and “SnippetList” for the nib.
Contains the primary window.
Primary window has “visible on launch” (really on nib load) turned on and “release when closed” turned off.
The advantage of all of this is that the lifetime of every object but the application's delegate is clear and explicit, as is the area of responsibility. My application's delegate is little more than that; the only thing it does that isn't specifically an app-delegate job is owning the primary-window controller. Likewise, the primary-window controller does nothing but own the primary window and whatever model I have to show in that window. And at quit time, everything but the application's delegate gets deallocked.
For document-based apps, I stick pretty close to the template. I delete any template methods I don't need to customize, and I may switch one or both of the I/O methods to one of the other versions (e.g., from readFromData:ofType:error: to readFromURL:ofType:error:), and maybe delete the write method if I'm writing a viewer only; that's about it.
Dive in.
Seriously just jump in with both feet. Find something that you want to make and just make it.
From what you've said you've already got a fair bit of experience with Objective-C and Cocoa and most things carry straight across.