I have a document based application.
If i open a saved file via double click on the file then a old version of my program (that I removed from the system) is opened instaed of the newer one. The application is a stand alone application.
How can i avoid this?
If it is removed from the system it won't launch. You do in fact have another copy of the app somewhere. Launch services cannot tell te difference between them and may launch either one.
You need to locate the old version (and any other instances) and at least move it to the trash.
Related
I know I can associate my application with a certain extension by editing the Info.plist file in my app bundle:
...
<key>CFBundleTypeExtensions</key>
<array>
<string>myext</string>
</array>
While this works, my "Open with" list gets littered with duplicate entries of the different versions of the application I'm developing on that machine. There are even entries for really old versions that I've never opened on that very computer! (It's a new machine being synced with Dropbox so there are older releases in my file system.)
It seems as macOS would scan for app bundles even outside of /Application and adds all applications it finds to "Open with". A workaround is to reset the "Open with" list with this command I found somewhere here on SO I think:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain user;killall Finder
How is the "Open with" list populated internally? Is macOS really scanning my drive looking for Info.plist files with CFBundleTypeExtensions entries? And is there any way to avoid having my "Open with" list littered with older versions other then deleting (or zipping) them?
NB: I'm not using Xcode but build my application on the command line using the clang compilers and creating Info.plist by a bash script.
How is the "Open with" list populated internally? Is macOS really
scanning my drive looking for Info.plist files with
CFBundleTypeExtensions entries?
I think so, yes. Check the documentation for Launch Services, specifically the section "Application Registration". Specifically, the OS can find your app and register is in the following ways:
A built-in background tool, run whenever the system is booted or a new
user logs in, automatically searches the Applications folders in the
system, network, local, and user domains and registers any new
applications it finds there. (This operation is analogous to
“rebuilding the desktop” in earlier versions of Mac OS.)
The Finder
automatically registers all applications as it becomes aware of them,
such as when they are dragged onto the user’s disk or when the user
navigates to a folder containing them.
When the user attempts to open
a document for which no preferred application can be found in the
Launch Services database, the Finder presents a dialog asking the user
to select an application with which to open the document. It then
registers that application before launching it.
And is there any way to avoid having my "Open with" list littered with older versions other then deleting (or zipping) them?
I'm not sure about that part. Probably not, although it seems like once you reset the Launch Services database using the command in your question, the old versions shouldn't get added back to the Open With list unless you are doing something to trigger getting re-added. Is that the case?
On Windows, how do I get my app to tell another app to open a file that I just generated. For example, "WordPad, please open 'foo.rtf' that I just made." Or Word, or other big apps that may already be open with other files. I have to assume that the app may or may not be open already.
Alternatively, if I could only do the equivalent of double-clicking the file, so as to open it with its default application, that would still be all right.
Depends on how your application handles opening other files.
One would think that assuming filetype associations are configured properly in Windows, it should know what application to open .rtf files with (per your example).
In powershell, you could use gc if you're only looking at plaintext data.
http://www.ats.ucla.edu/stat/mult_pkg/faq/general/powershell_examples.htm
In Python, you would handle the file as an object, per the example here:
https://docs.python.org/2/tutorial/inputoutput.html#reading-and-writing-files
But if you wanted to launch a specific secondary application to open the file, you might try running an outside program (executable) in python?
I've been playing around with an app I want to submit to the Mac App Store, and part of the functionality is simply grabbing a file the user chose by dragging or opening, and saving a modified of it to the same directory as the original file (but with a different file name).
I don't want to use a 'Save' dialog box, as that destroys the utility of the application I'm building, but it looks like that might be the only way the app would be allowed—under sandboxing requirements—to write a file to an arbitrary location (arbitrary, in this case, being in the same folder as the existing file) on the disk as a new file.
Is there any way I can approach this without disabling sandboxing? Also, if I submit the app without entitlements/sandboxing turned on today, will it be approved by Apple (supposing it passes all the other requirements), or are they already turning down non-sandboxed apps?
For your first question, no, I don't believe there is any way to write to a file the user didn't specify, unless it's either in your app's container, or (as of 10.7.3) in a directory you have a security-scoped URL for. See the documentation here. If the user specifies a file, I doubt you get permissions to the enclosing folder, but it's worth a shot.
Answering your second question, as of today, Friday April 27th, 2012, the App Store does not require sandboxing. The latest deadline given was June 1, 2012.
I have written an application suite on Windows which amongst other things installs a Firefox add-on which once run modifies the Firefox network preferences by interfacing with nsIPrefService.
The extension itself resides in a folder under Program Files along with other parts of the application which work together with each other.
Since the application consists of a number of components, the correct way to uninstall it is via the Control Panel or via an uninstall shortcut I provide for the users.
I have no control over whether Firefox will be running or not when the user chooses to uninstall (possibly I could try to detect if it's running in the uninstaller and request the user close it to continue).
Since the purposes of the uninstaller is to remove all traces of the program from the end-users system i.e:
all the files under the Program Files folder, including the extension components
remove the add-on from Firefox (by removing the registry key under HKEY_CURRENT_USER\Software\Mozilla\Firefox\Extensions, causing the add-on to unregister on next Firefox restart)
remove application specific registry keys
Then after uninstall there isn't any of my code left on the users system capable of restoring the network preferences to what they were before the component was installed. This results in end-users not being able to browse the web and being very frustrated!
The only way I can figure out how to do this at the moment is to have my component write to the window's registry the location of the users profile folder - which I can do with my add-on:
Components.classes["#mozilla.org/file/directory_service;1"]
.getService(Components.interfaces.nsIProperties).get("ProfD",
Components.interfaces.nsIFile).path
And then have my uninstaller modify the prefs.js file in that location directly. But this will only work if I can guarantee Firefox isn't running during uninstall (since prefs.js is re-written on FF close)
To me this is not an elegant solution:
It seems not to be future proof since it is dependent on the format and symbols used prefs.js which may change in future FF releases.
Firefox has a nasty habbit of not always closing properlly (sometimes other installed add-ons prevent it from completely unloading from memory. This would break my uninstaller).
This wouldn't work (without elaborate modification) if the user has multiple FF profiles setup all using my add-on.
Is there a better or "standard" way to achieve this simple task?
Did you try to package defaults files (defaults/preferences/myprefs.js) in your extension? I didn't check if it works for overriding Firefox-wide defaults, but it should.
Can't the uninstaller "insist" that Firefox be closed? eg,
check if FireFox is open
if open, inform user "FF must be closed, or cancel uninstall" ok/cancel
loop
I've had several installers do this to me. Not unistallers, though, that I can remember.
Also, this doesn't future-proof the solution, nor deal with profiles.
I have a application using Flash.ocx to get the frame picture from SWF file, after updating adobe flash player to the newest, the frame picture is totally wrong.
Is there a way to keep the old Flash.ocx in my running folder and my application will use that instead of the one in the system folder? I tried add the flash.ocx within application manifest file, but it doesn't work.
You can try to use flash wrapper: F-IN-BOX. I didn’t use it, but it has version compatibility feature.