While I realize Adobe discourages use of the application directory for reading/writing, I have been able to successfully write data there on OSX, so long as the user selected the file.
However, this same application is giving me trouble in Windows 7. Even a browseForSave() doesn't seem to allow the FileStream to write to the file.
Is there a workaround for this?
Or at least can anyone confirm that it DOES work for them? If you know a way to accomplish this, example code would be appreciated. I've tried a few different methods to no avail. This is for an internal development tool, and for our purposes it makes more sense to have the file in the application directory rather than app storage at the moment.
Windows 7 manages an application's access to it's own data. Put simply, it won't let you. As such AIR currently prevents you from doing it on any system for consistency's sake. See the linked thread for suggested alternatives from Adobe's Chris Campbell.
While this is a really cheesy work around, you can copy the file from app storage to the app directory after writing to the file. You would still have to write the file in the applicaiton storage directory though.
var theFile:File = new File(File.applicationStorageDirectory.nativePath).resolvePath('myfile.xml');
var theCopy:File = new File(File.applicationDirectory.nativePath).resolvePath(theFile.name);
theFile.copyTo(theCopy,true);
Then you can delete the storage file if you wish.
theFile.deleteFile();
Related
I am using osxfuse to develop a network disk with our service on mac osx, when I open a office2011 file and save in my disk, it will appear this error as below:
"you cannot save while the file is in use by another process.try saving the file with a new name."
but it is fine for office 2016. I am confusing about this and do not know how to resolve it?
who can help you?
I am working on my own FUSE file system and also had this problem. I found that in my case it was because I mounted the file system with the "noapplexattr" option.
It looks like MS Word requires applexattr.
MS Office apps uses extended attributes a lot. So your fs should has support of xattrs at least via apple double files (._fileName)
Also i found that MS Word likes to use exchange operation while saving files.
But it also may be an issues in your read/write/move methods implementation.
When i have such doubts - i use loopbackFS example app and just compare how it works with my FS.
is there a possibility to change the Dropbox sync folder (aka "Dropbox location") programmatically on Mac OSX? By programmatically I mean by executing some command line helper tool or by using the Dropbox API.
I've searched around for this quite a long while now, but couldn't find any satisfying answers.
Sym-linking or using an alternative cloud provider (with a possibly better CLI/API) as suggested here are not an option for me.
As I understand the Dropbox API, it is made for accessing the Dropbox Server storage from within one's own application rather than interacting with the "out-of-the-box" Desktop sync client, is this correct?
The solution I am looking for should also work very reliably, so "hacking" the encrypted SQLite dbx files (as suggested here) or an Apple UI script that changes the sync folder via the Dropbox UI Desktop client are also really not an option for me.
For Google Drive I know that doing this is a simple as stopping the sync client, moving the sync folder, changing the sync path in the sync_config.db accordingly and re-starting the Desktop sync app. -- Exactly such a procedure is what I would also be hoping to find for Dropbox :-)
THX for your replies & suggestions!
No, without using the potentially brittle methods you mentioned, I don't believe there's a way to do this programmatically.
Your understanding of the Dropbox API is correct though. Using the API allows you to communicate with the Dropbox servers directly to interact with the account, and not the local desktop client.
I am trying to install my Metro Application.
So, my question is:
Can I move sample pictures for my Application to KnownFolders.Pictures and Videos during installation ?
And, how can I create installation file for my application?
Thank you
With the installation mechanism for Windows Store apps in Windows 8, there is no need to write a setup or installation program. That will all be managed through the Windows Store once your app is published.
Since you can't write a setup program, to accomplish a similar goal, you can put some functionality in the app to execute when it's first run, then save a setting to indicate you've already performed the first run operations.
This would be where you would put your code for moving sample pictures.
However, your app will also need the appropriate permissions to access the KnownFolders location programmatically - check out this article for details. http://msdn.microsoft.com/en-us/library/windows/apps/Hh967755.aspx
It's also a good best practice to ask the user if it's OK to copy sample pictures to their Pictures library.
I am not sure if there is any utility which monitors hard drive for any new files getting created.
I am using one application that creates many files on my hard drive but I am not sure how can I monitor those newly created files.
BTW I am using Windows VISTA x64 machine.
Thanks in advance !
In native code, use a directory change notification.
If you prefer .net, then use FileSystemWatcher.
If you are a programmer and know Python, you should check https://fascinator.usq.edu.au/trac/wiki/Watcher
It monitors folders/directory for file changes i.e. created, deletion, modification.
If you are a Java Programmer, you should check WatchService in JDK 7. http://download.oracle.com/javase/tutorial/essential/io/notification.html
Check out the FileSystemWatcher class. It will help you by notifying you when something in a particular directory has changed.
I've been asked to update a VB6 application that's been running on WinXP for the last 6 years. The client wants to use Windows 7. Up until now, the app stored its settings in an INI file located in the application directory. One key difference between XP and 7 is that you can't write to C:\Program Files\AppFolder anymore.
I am trying to figure out where on the file system should I store settings? Given that the application is still required to run on WinXP, I am kind of confused.
On WinXP, I have the following:
C:\Documents and Settings\profilename\Application Data
C:\Documents and Settings\profilename\Local Settings\Application Data
On Windows 7, I have the following:
C:\Users\profilename\AppData\Local
C:\Users\profilename\AppData\LocalLow
C:\Users\profilename\AppData\Roaming
Each one of these folders have subfolders that seem to store settings/files for various products
So 2 questions:
Given all these folders, where do I store my settings?
I am assuming that there is a nifty Windows API call that would give me the proper location of this folder. And I am hoping it works on both XP and 7. Is my assumption correct? If so, a link would be much appreciated.
There are a number of special folders you can use, on XP/Vista/Windows 7:
The CSIDL_APPDATA folder is the one you will likely be most interested in. Data stored here is available to roaming users at whatever machine they log in to. This is the best place to store simple configuration data. All users have write access to this (and the last) folder. Note that none of the above folders are for user-generated data! That would properly belong under the My Documents hierarchy.
EDIT: As Cody Gray suggests in the comments, also consider CSIDL_LOCAL_APPDATA for application data that will always be local to the current machine, but is set aside on a per user basis. The data in this folder is not available on a roaming basis, so it should be data that the user will likely not miss if they log in to a different machine.
I shamelessly copied the explanation above from a good article by Karl Peterson, explaining this for VB6 programmers. Karl also has a ready-to-use class that will help you find the directories, but IMHO he's overcomplicated things this time. Bob Riemersma has a better way in one line, using the Shell object, as below. EDIT Bob's comment below explains why it's best to use late binding for this rather than early binding.
Const ssfCOMMONAPPDATA = &H23
Const ssfLOCALAPPDATA = &H1c
Const ssfAPPDATA = &H1a
Dim strAppData As String
strAppData = _
CreateObject("Shell.Application").NameSpace(ssfAPPDATA).Self.Path
In my opinion it's fine to continue to use INI files in these directories.
See the question "Does Microsoft have a best practices document regarding the storage of app data?" for some helpful info.
Maybe you just save your settings in Windows Registry?
That's very easy. Using SaveSeting and GetSetting is much easier than creating INI file.
And there is no trouble in compatibility, from WinNT to Windows 8.