I've associated a file type with my application via application properties and by implementind the necessary NSApplication delegate methods. Everything seems to work, but ... this confuses the system. How do i make sure that the files are only associated to the copy of the app that is in Applications folder and not the developement version? Because now my PathFinder shows two identical applications in its open with combobox and i don't want that.
You can't. If you have two versions of the same app, the system thinks that both can open the file because, well, they both can. Once an application registers for a particular file type, they system will always report that the app can open that file type. It looks at what the app can do, not where it resides.
Related
I am developing a Win8 Store app which allows users to download different types of files from an online learning platform and store them locally. I am also considering the function to help users organize these downloaded files by placing them in different folders (based on course name and etc.).
I was using Documents Library previously. But for every type of file that the user could download, I need to add a file type association, which does not make a lot of sense since my app would be able to open such files. So which local storage should my app use?
Many thanks in advance.
Kaizhi
The access to storage by Windows Store apps is quite restrictive, especially the DocumentsLibrary.
As you have noticed, you need to declare a file type association for every file type you want to read from or write to the DocumentsLibrary. This means your app need to handle file activations for these types in a meaningful way, which your app probably should not do.
But even if you jump through this hoop, there is another one that is not documented on the MSDN page of the DocumentsLibrary, but "hidden" in a lengthy page about app capability declarations: According to the current rules, you are not allowed to use the DocumentsLibrary for anything but offline access to SkyDrive! Bummer...
So what's left?
You can use SkyDrive or another cloud storage to put files in a well known place (which might or might not be somewhere on the hard disk). This is probably both overkill and undesirable in your case.
Or you save the files in the local app storage, provide your own in-app file browser and open the files with their default app. Seems viable to me.
Or, maybe, you can do something with share contracts or other contracts. I don't know much about these yet, but I doubt that they are helpful in your situation.
And that's it...
(Based on my current experience. No guaranty for correctness or completeness)
I've been trying for a while now to get a reference file to be loaded externally to no avail.
To be specific I am trying to load a "Microsoft Date and Time Picker Control 6.0(SP4)" which usually resides in C:\Windows\System32\MSCOMCT2.OCX
However some people that run a macro containing this element don't have that "MSCOMCT2.OCX" file on their PCs so I thought I will move the MSCOMCT2.OCX to a shared location and reference the code to use the shared one instead (so everyone will have access to it)
I tried doing that but when I was trying to load a reference with "Browse" from a different location it didn't load it - because I already had that in C:..
So I thought OK... I will remove the file from C:\ so I can only reference the shared file. - so I deleted it.
So I open the workbook again and look at references - I cant find "Microsotft Windows Common Controls-2.6.0(SP4)" - great!
And I proceed to add it manually with Browse from the shared drive.
When I do that however 2 references of "Microsotft Windows Common Controls-2.6.0(SP4)" are being added - 1 from C:\(which is not there) and 1 from the shared drive.
The one from C:\ is always automatically selected.
If I try to disable the one from C:\ and enable the one from the shared drive it automatically changes back to what it was when i press OK.
If I try to enable both - it says duplicate References and keeps only the one from C:\
So.. does anybody know how can I get rid of that C:\ reference from the list so it doesn't get loaded? Apparently deleting the files themselves did not work.
Ultimately my goal is to enable people without C:\Windows\System32\MSCOMCT2.OCX file to be able to use my Date Picker Tool.
Thanks a lot!
ActiveX control rereferences are always GUID-based. The VB IDE shows you the current location of the file as listed in the registry on your computer, as a courtesy, but it really doesn't matter what it says. The control will be loaded from wherever it was registered on the user's computer.
That's the key: the control must be registered on the user's computer.
I must strongly discourage you from doing what you're trying to do. You might be able to concoct a method by which you load the DLL from a network location, but it presents no advantage over doing the Right Thing(TM), and plenty of problems. The Right Thing is simply that if you need that control, you must distribute and register it with your application, just like everybody else does. And you really should install it in the recommended location for it (System32); not on the network.
Here's a quick example of what can go wrong: you provide your user with you app, and it works with the control on the network like you want it. Then the user installs another application that happens to need the same control. The app's installer sees that the control is already registered on the user's computer, so it doesn't try to add it again. Except that this particular app is intended to be used when the user is not connected to a network. Now you just broke someone else's program.
The VB/VBA architecture was never intended to support XCOPY deployment. I'm know it's a pain and that these extra steps are extremely inconvenient when you're just trying to deploy a "macro". Sadly, it's the nature of the beast. I'm sorry
I'm building an app that has projects. A project can have many files in it which are pointed to from a project file. Theses files are copied to the projects folder so I know where they will be but as far as I know in WinJS you can only get access to files the user directly give access to. The user will select the project file, I'll be able to read it but I'll have no way to access the projects files. I do know I can do something like package the project up as a single file and then extract the individual files in my apps local file system but doing so is sub-optimal to me and I'd prefer to do the folder based structure if I can.
I'm not entirely sure I get it, but I'll give it a shot. In a Windows Store app, you do have access to more than just what the user directly gives access to. If you want to pick a file from anywhere on the computer (our from other apps through the FilePicker contract) then, yes, the user has to pick them, but you app has full access to the isolated storage and if it declares access to the user's documents library and the user allows it, then you have access (to your declared file types) in there as well.
I think the choice of going to isolated storage versus the user's document library comes down to whether or not the user would expect to have the project files outside of your app. Might they email a project to a friend? Might they manipulate the project with another app? Might they want to back the project up? If so, then use their documents library. If not, then the data is more application data than user data and could be stored in the local app storage.
Hope that answers the question. If not, then please clarify.
I'm building a Mac OS X application that can be used to create 'projects'. When a user saves a project, they will be saving many resources: image files, text files, sqlite files etc.
I can either create a folder in Documents for each project, and within that folder I can place all the project assets, and just include a single project file that is used to open the project.
I've read about NSBundle which I'd like to use. But I've only read about them in the context of application bundles. Is it possible to use NSBundle in this way? Where the user only sees a single file, and can move it wherever they like.
Does it make sense to do what I'm trying, using NSBundle? Or is there another way to do this?
(I'm fairly new to MacOS X programming)
UPDATE
I believe iPhoto uses this method to store the "iPhoto Library", this is what I'd like to do with my application, is NSBundle what I should be looking into?
Yes, it is possible and was used in quite a few apps in the past. The method is described in this document. Once it's clearly declared in your app's Info.plist, Finder will show the resulting bundle as one file.
However, I can't recommend you to do that. Apple's own Keynote was using the bundle approach in the past, but it no longer uses it any more. Similarly, OmniGraffle (which is a diagramming app on OS X with a long history) used bundles to save projects, but it stopped doing that, too.
The reason is that the bundle is still seen as a directory by the non-Apple email software, or any browser, etc, although the Finder shows it as a file. It would be a mess if a user wants to attach your document in the bundle format to an email s/he is composing in Gmail inside a browser, say. That confused a lot of people.
So, it's possible, but I don't recommend it. One way out is to use the zipped bundle as the user-visible file, and to unzip it when the user opens it into a temporary directory. Then you can use NSBundle and/or NSFileWrapper apis to access files inside it.
Apple's File Wrapper sample seems to be what you want:
http://developer.apple.com/library/mac/#samplecode/PersistentDocumentFileWrappers/Introduction/Intro.html
It also demonstrates how to save a Core Data persistent store in the bundle. You can leave that part out if you just want to store resources.
The NSBundle class represents the application bundle, and can be used to access resources within the applicationm but you would you it for application data, not user data.
For each of the resources you mention, there's a way of saving this type, for example, for image files, you could use NSData to save the image data to disk, and for text files you could use the method writeToFile:atomically:encoding:error:.
You may very well want to take a look at Core Data (http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/CoreData/cdProgrammingGuide.html), a very good framework for managing the user's data model, to see if this would fit your needs.
It would be useful for many people to know how to completely remove an application from your device when testing.
I have downloaded my app many times now, and likewise have deleted it many times. The problem is when deleting the app, it does not remove things like the persistent object related to my app, or the images downloaded through the app. So, when I download the next build, I have no idea if something broke that is related to building the persistent object or fetching the images since those elements already exist from the last build.
I don't know if this is a cache thing. I don't know if this is expected and I have to use some utility to wipe this data after deleting the app. I can't really find much info through basic web searches.
Any information would be appreciated.
Blackberry Bold 9000. 4.6 OS. tested with both SD card and no SD card.
Objects stored in the PersistentStore are automatically deleted on uninstall if their interfaces were defined in your project. If they are from the standard BlackBerry API then they will stick around until they're deleted. E.G if you save a String in the PersistentStore it will stay in the PersistentStore but if you save a class you created it will be deleted on an uninstall. So if you want to have those objects be deleted automatically just create a wrapper class and save that.
Images stored on the filesystem will not be deleted until you or some application deletes them. However, it should be easy for you to write an app that clears everything out.
Another solution you could implement is making your app somewhat self-aware of its data.
Create a simple String value that you persist (or optionally, persist it in a Hashtable so you can store many properties this way) that includes "Version".
At startup of the GUI app, compare the stored "Version" against the application's current version. If the stored version doesn't exist, or if it exists and matches, take no action.
If it exists and does not match, automatically clean up old persisted data; or alternatively prompt the user to see if they want that data to be deleted (which one is better will depend on your implementation)
You can also use CodeModuleListener to listen for an uninstall event -- when that happens, you can clean up at that time as well or instead.
(As an aside and a bit of shameless self promotion, I am actually currently working on a shareable library for Blackberry that makes managing persistence much easier, as well as desktop data backup/restore. I'm doing this as part of the BBSSH project, but I'll be splitting it off into a separate library of core components and publishing it under a dual GPL/optional commercial license. It will contain hooks for data cleanup and data versioning. )