Skip to main content
Home Forums Silverlight Programming Programming with .NET - General SaveFileDialog? Please help make it possible
21 replies. Latest Post by ksleung on April 23, 2009.
(1)
ksleung
Contributor
5356 points
1,028 Posts
10-22-2008 3:14 PM |
I'm on the verge of doing something silly and I hope the SL team can save me from doing so, and my peer developers can pitch in... :D
When I first found out Silverlight supports OpenFileDialog, I felt this could be significant since it brings web-app closer to desktop-app (and even a competitive advantage over Flash). But the lack of the complimentary SaveFileDialog really makes it a rather moot point, at least less relevant.
But now Flash 10 is out and they support both OpenFileDialog and SaveFileLog, so it is silly to continue to say why SL shouldn't support it in the name of "security". IMO SL should support it ASAP, hopefully no later than 2.1. This feature, though small, gives Flash tremendous inroad into the desktop space without going through AIR (which seems bloated to me).
In my SL app, I already uses LoadFileDialog but the lack of SaveFileDialog drives me crazy... Now I am thinking about having both SL2 and Flash 10 in my application, and when I need to save something, I pipe the data to Flash 10 and do it there. For consistency reason I may move OpenFileDialog to Flash 10 as well. Only thing that stops me from doing so is that I hate Flash development, but I guess sometimes need trumps over desire.
This is really silly... I wish I don't have to go this route... "Here's a great SL app, oh but to run it you need both SL2 and Flash10!"
prujohn
3567 points
703 Posts
10-22-2008 4:04 PM |
Funny, I was just about to write a post about this topic. Glad I scanned the forum first.
I wholeheartedly second this request for SaveFileDialog. When I look at the way the IsolatedStorage is implemented, I see that the SL team went to great lengths to make sure the interaction with the local file system (quota increase) is user initiated. I don't see why the same techniques couldn't be applied to a SaveFileDialog API.
This is important, developers (such as myself) are designing applications that will consume user files and process them. The user will want these files back eventually. Round-tripping a once local file to the server, just so the user can move it local again works, but it's cludgey, and I would argue potentially as unsafe, if not more, than providing a mechanism for client-side save (data in transit twice, across the Internet vs. once on a trusted local machine...).
Looking through the forums, I see many other folks are also interested in this feature. ksleung also makes a very good point about SL's main competition in the client-side rich UI space (though I dare not speak it's name).
MichaelW...
Member
2 points
2 Posts
10-23-2008 8:01 PM |
I have the same need. Looks like I need to do the heavy processing in Silverlight and output using Flash10.
ksleung: Out of interest, how did you pipe the data to Flash 10? Is it directly from the Silverlight control to the Flash control?
Thanks,
Michael
10-24-2008 12:28 AM |
MichaelWalsh:I have the same need. Looks like I need to do the heavy processing in Silverlight and output using Flash10.ksleung: Out of interest, how did you pipe the data to Flash 10? Is it directly from the Silverlight control to the Flash control? Thanks,Michael
Well, I am still looking into it. Flash development is not my forte so my progress there was slow. So far what I got was a Flash app (.swf) that can load from and save to local disk), and I am still writing the hooks for it to talk to Javascript. On the other hand, Silverlight to/from Javascript is easy and elegant (well done, SL team!).
Depending on whether I can call Flash function exposed to Javascript directly from Silverlight, it woud either be Silverlight -> Flash or Silverlight -> Javascript -> Flash. In any case, I would also have to encode the bytes into a string and decode at the other end, since I think Silverlight/Flash/Javascript does not play nice with each other wrt array.
BTW I build the .swf file using Flex SDK (free), not Flex Builder.
There are a few articles that talk about Silverlight/Flash interop (just search "silverlight flash interop", from which I got most of the idea. If I have the code ready I am willing to share but I don't have it yet. One more thing about this convoluted path... I heard it doesn't work on Mac since they need LocalConnection between Javascript and Flash... whatever that means.
Again, I want to say that this is really a silly path that I don't have to go through. I hope the SL team is thinking hard about this...
lingbing
2249 points
406 Posts
10-24-2008 1:20 AM |
MS always says that there is some security reansons, the silverlight app is running is sandbox, and so on. But I think even the coder can show a savefiledialog to user, if the user doesn't save it, the file is still cannot be in the local disk file system. However users maybe don't know what the file is, if the file is a virus, and when it is saved, it breaks... This is a big trouble, so Microsft doesn't like savefiledialog.
If we limit the file type of savefiledialog to just some txt files, it is not ok too. Clearly, we need more. I think there must be a mechanism that can ensure the file that is to be saved to local disk is safe, if we cannot ensure this, MS will not add SaveFileDialog to Silverlight.
10-24-2008 1:28 AM |
ksleung: MichaelWalsh:I have the same need. Looks like I need to do the heavy processing in Silverlight and output using Flash10.ksleung: Out of interest, how did you pipe the data to Flash 10? Is it directly from the Silverlight control to the Flash control? Thanks,Michael Well, I am still looking into it. Flash development is not my forte so my progress there was slow. So far what I got was a Flash app (.swf) that can load from and save to local disk), and I am still writing the hooks for it to talk to Javascript. On the other hand, Silverlight to/from Javascript is easy and elegant (well done, SL team!).Depending on whether I can call Flash function exposed to Javascript directly from Silverlight, it woud either be Silverlight -> Flash or Silverlight -> Javascript -> Flash. In any case, I would also have to encode the bytes into a string and decode at the other end, since I think Silverlight/Flash/Javascript does not play nice with each other wrt array.BTW I build the .swf file using Flex SDK (free), not Flex Builder.There are a few articles that talk about Silverlight/Flash interop (just search "silverlight flash interop", from which I got most of the idea. If I have the code ready I am willing to share but I don't have it yet. One more thing about this convoluted path... I heard it doesn't work on Mac since they need LocalConnection between Javascript and Flash... whatever that means.Again, I want to say that this is really a silly path that I don't have to go through. I hope the SL team is thinking hard about this...
Ha, I just found out that Adobe Flash 10 now imposes a stricter security policy in which a Load/Save dialog request MUST be initiated from a button event and cannot be initiated programmatically. This actually breaks a few applications such as Flickr upload, as I heard. This also means that the route I was thinking of is quite a bit harder, since I somehow need to make it such that a Flash button is physically pressed when I need to load/save.
Maybe they did this to prevent someone like me from doing what they think I want to do. "No Silverlight shortcut for you!" :D
10-24-2008 2:40 PM |
I am very much ok with a user-initiated scenario as long as we can get the SaveFileDialog via Silverlight. That's just a simple matter of asking the user for permission, and let them make the choice. But to have no options at all for this, except for a round trip to a server, seems a bit too restrictive. I'd sure like someone from MSFT to weigh in on this soon...
Jonathan...
All-Star
24929 points
2,425 Posts
10-28-2008 5:28 AM |
Hi All,
We can understand SaveFileDialog may bring much convenience to our daily work. However, not all the users have enough knowledges when they visit websites. Many riskes may be brought by mis-typing or something else. Anyway, thanks for the post.
Best regards,
Jonathan
10-28-2008 1:46 PM |
Again, this is the "security" argument that I detailed. Fully understood. However, I wish you guys can take a look at what Adobe did with Flash 10, which is to open up this capability after 10 years of obnoxious server round-trip. Currently their product has a much higher penetration and is exposed to many more people and many more applications. This would not be something that they did at a whim. In fact, I believe their final compromise -- which is to insist that SaveFileDialog be triggered by a user button click event but never programatically -- makes this feature no worse than existing Flash vulnerability. If you are afraid of allowing the user to generate an action by pressing a button, well, what more can I say.
This is a feature that many web applications can greatly benefit from. After all, why support LoadFileDialog when you can never save? Silverlight is a once in a blue moon great product from Microsoft, and I hope you guys can make it greater, not lamer.
jackbond
2820 points
725 Posts
10-28-2008 10:29 PM |
Jonathan Shen – MSFT: We can understand SaveFileDialog may bring much convenience to our daily work. However, not all the users have enough knowledges when they visit websites. Many riskes may be brought by mis-typing or something else. Anyway, thanks for the post.
I gotta say, I don't understand the security argument at all. If it's so dangerous, why allow IE to save a file at all? And even worse, why allow an OpenFileDialog? With a SaveFileDialog, the worst that could happen would be to overwrite an existing file. So for damage to occur, someone would have to a) see an OpenFileDialog b) select an existing file c) select yes to "Overwrite this existing file". Are you guys really going to cripple Silverlight to protect those so brain dead that they actually fall for a, b, then c? Here's another way to look at it. If someone is that stupid, there are going to be much easier ways to cause compromise their system than a SaveFileDialog box.
10-29-2008 2:08 PM |
Another point for MSFT to consider is that by not providing a secure SaveFileDialog option (giving the user plenty of warnings, etc), they are inviting developers to do what they will inevitably do in these situation: develop workarounds and hacks to get the feature. I would argue this will lead to solutions on top of SL that are, in fact, less secure than a MSFT-sanctioned solution would ever be....
10-29-2008 2:35 PM |
prujohn:develop workarounds and hacks to get the feature
In this case, the work around is to use Java.
http://java.sun.com/j2se/1.5.0/docs/api/java/awt/FileDialog.html
I'm curious. Why is it that java can have a file save dialog and not Silverlight? Are the Sun programmers better than the Silverlight team? It's the only logical conclusion.
10-29-2008 10:40 PM |
Surely, awt can be used in Applet, but it can also in Application. And I think Sun programmers' main point is to use it in Java Application. Microsoft has WinForm and WPF, both of them have OpenFileDialog and SaveFileDialog, in my point of view, it works fine, much better than awt, and I think that's why AWT is replaced by Swing and SWT.
But, it is silverlight, it run in brower and can get data from the web, so that securty issue is important.
Regards!
10-29-2008 10:49 PM |
The main argument for SaveFileDialog, however, is that (1) it substantially enhances the power of RIA beyond pretty banners, (2) it can be done safely and securely as in Flash 10, and (3) there exists an ugly way to make it happen by overlaying Flash 10 app on top of Silverlight and exposing the buttons needed to trigger SaveFileDialog.
So, whether MS does it or not it's really a business decision rather than a technology decision, as it can clearly be done in Flash 10 (as well as Java Applet). I just wish that the business decision will be made wisely.
Patrick8639
575 points
150 Posts
10-30-2008 2:59 AM |
Hello everybody,
a solution to the problem could be a mimic of the download feature of the browsers:
MS adds a new class to the base library, that I will name UserFileStream. This new class has three important functionallities:
When this stream is ready, the SL application will call a special method (Save or Download or ...) and the SL runtime will do exactly what the browser is doing when the user receives a download file.
The user will see exactly the same user interface as if the data has made a round-trip to server.
Patrick
10-30-2008 3:15 AM |
Patrick8639: a solution to the problem could be a mimic of the download feature of the browsers:
This isn't a technical problem that needs to be figured out, it's a marketing problem. MSFT didn't want some moron getting a file overwritten and the ensuing "Silverlight is riddled with security holes" hype that would surely come from the ever reliable anti-Microsoft crowd. So they played it safe, let the world get comfortable with Silverlight, and then slip it in as a great new feature in the next release. They took a similiar approach with the first release of the .NET framework. In the betas, if you clicked on a .NET executable hyperlink in IE, it would go ahead and launch it because the code access security protected the system. They decided to be extra cautious and disabled that, only to re-enable it in a later release. Just recently have they made the change to allow .NET code running from a network drive be considered safe. For my money this was just a ridiculously cautious decision as both Java and Flash provide SaveFile dialogs.
10-30-2008 1:40 PM |
Patrick8639 made an excellent point for all I need, and I guess so do many others, is to have the same server roundtrip behavior without the server roundtrip. We are not trying to look into the file system or anything, but just to save a file!
MS team: can you guys really look into this seriously? I see Patrick8639's solution to be an excellent approach without any additional security risk. It is the same security exposure as what the user is subject to today, which is that a SaveAs request from the server which the application originates from is issued (i.e. non-cross-domain). By supporting the UserFileStream (man, even the name sounds great), it will satisfy the need of most application developers without any additional security risk.
anyeone
Participant
811 points
182 Posts
10-30-2008 5:13 PM |
My app is a secured business application - not something for Joe Blow to walk in on off the street. Our customers will be paying a lot of money to use our app, and we need the ability to be able to save files locally.
Users can do stupid things even without Silverlight. We don't keep cars off the road completely because of the few who drive drunk. Not giving us this basic functionality in the name of security is essentially the same thing.
avbersSL
164 points
78 Posts
10-31-2008 4:39 AM |
Yes.. count me in..
Can somebody open a Microsoft Connect feedback item so we can vote??
10-31-2008 9:51 AM |
I checked out the Microsoft Connect thing. Didn't look like an appropriate channel for this type of request, so I didn't log it. But perhaps I was in the wrong area... I think the best thing to do is for folks to keep signing this post that they would like to have the feature.
earthtec...
12 points
6 Posts
04-23-2009 11:25 PM |
Hi - just curious to know where this thread ended up - is the newest version supporting savefiledialog?
04-23-2009 11:31 PM |
As the one who started this thread, I am happy to tell you that, YES, it is supported in SL3 beta. And it's called SaveFileDialog :D