I have a WinRT app that, in part, does file downloads from an online service and manages the local copy of the files. When stored locally, the files need to be encrypted, but during editing/viewing, as that happens in external editors (office, pdf, etc) they need to be decrypted.
Is there a way within the WinRT API set to launch an external browser (ie. Windows.System.Launcher.LaunchFileAsync) and somehow get notification when that app has been closed?
Right now, I can download and encrypt the file fine, but when I want to view it, I have to decrypt it and launch the external editor with no way of knowing (or even necessarily running again) when it's finished so I can re-encrypt the file.
Ideally I would like to somehow bind the external application to mine so that my app is unavailable until the external editor is closed, but would settle for notification when the app is closed or any other creative solutions.
Your app scenario looks something like skydrive app from Microsoft. It downloads files from the skydrive service, integrates with file open and file save pickers.
Try integrating with file picker contracts.
you can start here. There are sample code also available to implement file picker contracts.
Related
In my web-app (WebPages, C#.NET) I have a drag and drop file box where user's can drag files from windows explorer and, once dropped, it will save in a given location on a shared drive. This part is working fine. The box looks something like this:
The problem is, that it also reads files from the same directory and my user's would like to be able to open the files from this interface on dblclick. I have written an ajax request with jquery (the ajax, too, is working fine), but I can't seem to get the files to open on the user's machine no matter what I try.
Most references I try and look up point me towards System.Diagnostics.Process.Start(#"<directory goes here>") but this doesn't really do anything. It will open some process on the server side, but nothing opens, either on the server or on the user's machine.
What they'd like to do, for instance, is double click 'Hazcom.xls' and it would use the default associated application to open the file. In this case, of course, Microsoft Excel.
Is this even possible or am I chasing a wild goose here?
Sources I've Tried:
Open file with associated application
http://www.csharp-examples.net/open-file-with-default-application/
How can I open Windows Explorer to a certain directory from within a WPF app?
c# open file with default application and parameters
There have been a few more sources I've tried, as well, but they're all pretty much in the same vein as these.
Additional Info:
The internal Intranet application runs on a server using IIS 8
The solution is desired to be opened on the user's machine and not, say, the server itself.
The path to the files is dynamically changing depending on what they have loaded into the interface.
Though, I'm not expecting this to be a solution viable for client side (jquery) I'd be happy to look into that if that's the only solution available.
I'd also settle for simply opening the file location, instead of the actual file itself, but I've had no luck with this either, for what looks like the same reasons as the original problem.
I have created an app that makes use of file types that are not standard to Windows Phone and I have registered my app to these extensions and they can be opened in my app perfectly from example the email client.
My application can modify the file as well as generate completely different ones. I then have an internal file manager page where users can delete files and choose to open then.
My problem now is that I want the user to share these files via email, Bluetooth, tap+send(nfc), etc. with a menu pretty much like the you get in the gallery(photos) app on Windows Phone. Is this a standard function that I can somehow access, or is there another standard library or anything really that I can use to as quickly as possible implement file sharing?
There is a ShareMediaTask but it is intended for sharing media files on any kind of files, so you need to implement everything by yourself.
I'm looking to create a synchronization mechanism for a document storage service.
The essential idea is that the user downloads a stub file say somefile.stub that contains a link to the file on the server.
When the stub file is clicked on an app on the users machine (associated with .stub) opens up looks in the file and downloads the document from the server in the background.
Once I've got the file locally I'd like to get windows to open up the file in the appropriate editor e.g. word. I really don't want to have to save out the file and then open word or whatever via Process and a command line.
Also, I'd like to be able to grab the document when its saved and send it back to the server to keep everything in synch.
I'd prefer to write the client application in c# if possible.
You have to create a service running continuosly on the client machine, that should orchestrate the stub file transfer and the opening of them. Opening with the proper program can be achieved by using Process with StartInfo.UseShellExecute = true;. You can also use a FileSystemWhatcher to be notified when the external app modify the file.
Here is one solution:
Create a Class 2 WebDAV Server and publish your MS Office documents via it.
In case you target MS Office 2013 you can use the following link to open documents for editing directly from your WebDAV server:
ms-word:ofe|u|http://mywebdavserver.com/path/document.docx
This will eliminate download/upload steps and will work in the SharePoint-like manner. You also do not need to deploy any client application in this case.
I have a website that occasionally needs to have a handful of the tables in its database updated. The updates come from another system that exports to comma delimited text files. I can then either FTP the text files to the web server, send them in through an admin upload page, or manually log in to Remote Desktop to download the text files. I have all my C# code written to parse the files, check the database contents, and decide what to do.
Should I code the sync logic to be part of a file upload page, protected in the admin section of the site or should I create a Windows Service that constantly looks for files to process in a particular directory that I can drop files in through FTP?
I have used Windows Services in the past and they have worked great, but if I ever have to make a change to the code it can take longer than it would if I just had to modify an ASPX.
Are their security benefits one way or another?
Performance benefits?
ASPX page wins the "ease of maintenance" category.
I would create a Windows Service to watch a secure folder and use a directory watcher to look for new files. Since the files are coming from another system, it is asynchronous in nature, and it is much more performant to have a Windows Service running separately to watch for updates as they happen. It can also parse the files and update the database for you.
Depending on who maintains the remote system, the easiest way is to grant permission to the service to access the files on a secure, shared folder. Then you won't need to do anything manually.
To summarize, as we all know,
a) Silverlight is expected to be hosted by a browser, and runs in an isolated sandbox so that there won’t be any security issues
Silverlight don’t have direct access
to the file system, other than the
isolated storage area
There is no
direct way to open common dialog
boxes like File Save in Silverlight (Though Opendialog box is supported).
b) Silverlight can’t access local resources like a printer
What are the ways to go beyond the sandbox, so that I can host a Silverlight application locally, to read files and save them back if required, to hand over data to a printer, and so on..
Update:
Is full WPF is not an option for me? No. I'm also interested in a cross platform solution - for instance, you could host Silverlight in Mono Web browser control, so that you can run it virtually anywhere.
The idea is to re-use the same application that I'm building for web in my desktop as well, by providing separation of concerns at some areas - like persistence, resource access etc.
Scenarios:
1- Some kind of gadget container, with access to local resources.
2 - A desktop Silver light based media application
Update:
I just did a POC to enable me to access printer and save files locally, of course through a shell where I'm hosting my Silverlight application. If you wan't you can have a look at the post here in my blog
Two ways I can think about is,
Create a "Shell"
Host the HTML Page with Silverlight, in a Winforms desktop application, using a web browser control, and communicate to and fro using HTML DOM. Then I can request the hosted shell to do things like printing. See details here
Mono also has a web browser control - based on FireFox XULRunner instead of IE - not yet succeeded in loading Silverlight inside that. Another option might be using Webkit.
Embed a web server
Embed a light weight web server with in the Host application, and handle requests to perform such operations. You can probably define a protocol on top of HTTP for things like saving to a local folder, sending data to print etc.
Is a full WPF application not an option for your situation?
As you probably know Silverlight uses a subset of WPF so you may be able to change your application relatively easy.
A wpf app would be easier than having a web server etc bundled within your application.
You wont in the foreseeable future be able to have access to resources such as printer and files (apart from isolated storage) through Silverlight as you know.
You could have a seperate part of your app to upload files to the webserver then read these in your silverlight app from a service.
Depending on your printing requirements (e.g. if you just want to send everything to an office printer) you could send the informaton you wanted printed to a service that will then print it for you. However I am guessing you want each client machine to be able to print in which case this wont work for you.
I am attempting to also reuse a codebase for both desktop and silverlight. There are two options that I know of in addition to the ones mentioned
If you directly reference (instead of a project reference) a silverlight dll from a normal project, it should work. This would let you reference a silverlight dll for both projects.
Have two project files (one wpf, one silverlight) that point to the same set of files. You might have to have to use a few compiler flags here and there, but this should let you use the same files for both.