In metro, the codes like following will throw exception:
String fileName = #"C:\Test\dd\ccc.jpg";
StorageFile file = await StorageFile.GetFileFromPathAsync(fileName);
However even if I check everything in capabilities, also File Picker was added and all file types allowed. I still can't access this file, the same exception will be thrown.
Does someone know how to read file in arbitrary file path? Is that possible in metro style application.
Not possible. You can get to the Libraries - pictures, documents, videos - and if the user puts that folder into one of those libraries (using Windows Explorer on the desktop side) you're all set. You can even write a desktop exe that will put the folder into the library, but you can't launch that exe yourself or be sure that the user hasn't changed the libraries by hand.
Look up SHCreateItemInKnownFolder for a starting point to the shell APIs for library work. I haven't tried calling those APIs from the Metro side; you can see if they help but my bet is they will not be available. If you don't like the COM interop to the shell APIs you could look at the source code to the Windows API Code Pack - I wouldn't want to bundle all of it with a Metro app, but you could copy parts of it to your application.
Related
I'm developing a VB.NET Windows Forms app to edit files of with extension *.fltp, and I want to use ClickOnce deployment. But the File Association part of my manifests doesn't seem to work.
From my time programming in C++, my understanding is that double-clicking a file in Windows Explorer causes Windows to undertake the following actions:
Scan the registry for the file extension (say, *.doc)
Discover in the registry that the file extension is registered to a command-line scheme (in this case, winword.exe %1)
Run that command-line (i.e. winword.exe "Untitled.doc").
Now, ClickOnce doesn't offer such fine-grained control; in MSVS, I just go to the Publication options and get to associate my app with *.fltp. I assumed it follows the general pattern of putting App.exe %1 in the registry, and wrote my application to that spec.
When I deploy the application, it seems as though the application is registered to *.fltp files: their icon and description changes, and double-clicking on them in Windows Explorer opens the app.
But the command line is blank, so my app just opens a blank new document! When I place in one of my files
Private Sub Init(sender As Object, e As EventArgs) Handles MyBase.Load
MsgBox(Command)
End Sub
the deployed app just shows an empty messagebox. (The same behavior shows if I use System.Windows.Forms.Messagebox.Show, System.Environment.GetCommandLine, or My.Application.CommandLineArgs — it's not the legacy VB functions that are at fault.)
The registry entries are similar to those for a C++ app, but not identical, so I can't figure out what they do.
How can I tell which file the user double-clicked on?
You've correctly deduced that ClickOnce doesn't pass the file as a command-line argument.
The problem here is that ClickOnce (typically) checks for app updates right when the app starts. So if ClickOnce used the fixed registry schema you describe for C++ apps, Windows might start the app with a file location on the command line, ClickOnce realize it needs to update the app, quick download the new executable and update the registry, and start the updated executable in a new process, accidentally squashing the command-line along the way. So it stashes the file in an Appdomain, does any update stuff necessary, and then starts the app in the child Appdomain.
TL;DR: You want AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData instead of the command line.
I have a very particular case and I don't know if this is possible to be done.
I'm using NWJS to run a web app as a desktop app. I need to zip/package the source files because my code should not be available to eavesdroppers. This package will be delivered on a flash drive. And this is were my trouble begins.
There are a lot of .pdf file that must be shipped together with the package. The user can browse which pdf he wants to open, and when he clicks it, the pdf is "downloaded" to his pc. The content of the pdf is NOT available on the application. I have a list with the name of each pdf file.
If I zip/package the .pdf together with the source files it becomes a huge .nw file and it takes forever for my application to load. I need to mantain the pdf on a separate folder and they need to be accessible through the source code. This is easy if i run the application directly without packaging it, as nw uses the relative url to it's root, but when I do package nw uses a temp folder for the source files and I can't use relative url to access the pdf folder.
The only approach i can think of is to write a js script to identify where the flash drive was mounted but i don't know if this is possible.
I have to support Windows and Mac for this case.
Searching on NWJS google group i found that the answer was quite simple. These two lines returns the path where the nw bin is running. From there is quite simple to get the pdf folder.
var path = require("path");
pathstr = path.dirname(process.execPath);
I have accessed normal files and folders, but unable to read the target value from a shortcut file. Any idea how to read a shortcut file in WinRT?
My actual requirement is to find the most recently used/opened files in the system This info was previously available through Environment.GetFolderPath(Environment.SpecialFolder.Recent)
Thank you in advance :)
There is a file AppData\Local\recently-used.xbel which contains this information on Win8. Parsing it should be easy, but the problem will probably be to get access to this file as it isn't in the folders that can be accessed via any manifest declaration. Also the AppData folder is hidden, making it inaccessible via the FileOpenPicker.
My guess would be that this is an intentional change by Microsoft since it is no business of a sandboxed app, which documents were used by other apps. If you want to open files that were recently opened by your app, you can roll your own "recently changed" implementation. Which should be easy because you have to save their token to the FutureAccessList anyhow.
just wondering if it's possible to include some files (one txt file in this case) in the app package that I need in the application folder. The thing is that I might use a piece of code that requires the license to be included in the app as a text file, and I think this would be one way to do it.
Thanks in advance.
Absolutely, it's really no different than including images for instance. And if you need to process the file within your app you can access it via its local path or explicitly use the ms-appx:/// protocol.
See How to reference content and How to load file resources for more details.
Just include the file in your project with Build Action set to Content. You can put it in any folder you like.
The file can then be accessed from the app either using the ms-appx: protocol or using the StorageFolder API:
var license = await Package.Current.InstalledLocation.GetFileAsync("license.txt");
If I try to build an application with the application class outside the default package, so the application file path is /app/AppClass.mxml instead of /AppClass.mxml (as would normally be the case), Flash builder cannot launch the application for debugging because it is looking for the SWF in debug/app/AppClass.swf and the SWF is being output to debug/AppClass.swf instead. Changing the output folder to debug/app makes it put the swf in debug/app, but then it puts the application configuration file "AppClass-app.xml" in /debug/app/app and then that can't be found.
Is there a way to change only the SWF output folder, or the location of the xml configuration file in the run-configuration?
You may use symbolic link to created swf file - http://en.wikipedia.org/wiki/Symbolic_link
for example for Windows :
cd project/path/bin-debug/package/path/
MKLINK ClassName.swf project/path/bin-debug/ClassName.swf
and it's work
or you can use symbolic link for folder:
cd project/path/bin-debug/package/
MKLINK path project/path/bin-debug/ /D
I think I remember this worked for me. But it was long time ago. And, yes, it is a known problem, I also recall Adobe people mentioning it as a limitation of FB.
In my Ant script, you'll need to do the adjustments to reflect your actual file names and directory structure. Also note that it will make it more cumbersome to debug it from FB. You'll need to use the debugging target in Ant, and then connect the debugger to the running application (so that some info, especially on the startup) will be lost. The only way you would be able to debug it, though I've never tried it, is with the commandline tools (I'm not sure of adl syntax for breakpoints / printing / stack frames, so idk how to do it.
Also, for the released application you will probably want to change the signing mechanism.