In the old days for WinForms, if your user was creating/editing some information in a DialogBox, it was easy to detect the Window closing and if the data was dirty, ask if they wanted to save.
My question is, how do you approach this scenario in Silverlight where everything seems to be done in UserControls, which have no obvious way of knowing when the page is closing, ie switching to another page within the Silverlight app would simply open a different UserControl without checking the previous UserControl needed saving.
There must be some standard way of achieving this?
If you need to ask the user a question about whether to save or not then you will need to handle this in the browser the onbeforeunload (whilst not a standard event it is supported by those browsers on which Silverlight is officially supported). It may be possible to set up a little javascript to call back into your application when onbeforeunload fires.
That said I'm not a fan of the "Are you sure, you want to lose all that work you've just done" type of question. "Of course I don't want lose it, save it already, as long as I can undo it later if necessary I'm happy".
You can handle the Application.Exit event to execute code on application shut down. Be warned that at this time the networking stack has already shut down so you can't send any messages from the Application.Exit. You cannot cancel the event.
+1 Michael. It is a current limitation of SL. You can however persist to isolated storage from the app exit event, would it be feasible in your app to check if dirty, and if so save to iso storage. Then next time your app loads you could load the dirty data from iso storage ready to carry on editing..?
Related
In my GWT application, I have been saving everything that the user does instantly to the datastore in the background whenever they make changes. So far this has been fine because the things that the user can change aren't being changed a whole lot.
But now I have added a series of check boxes that the user can check & uncheck:
Would it be proper to save everything instantly to the database everytime the user checks/unchecks a box? The thing that's on my mind is reducing the amount of times my web application has to go to the server to save data. Facebook, Google, (and many many others) use a "Save" button whenever a user makes changes to a large amount of fields (say, to their user information).
I am trying to stay away from having a Save button, and so the thought came to mind about saving these values whenever the user closed or refreshed the page. I don't know if that's proper either (what if there is a loss of power, and their system shuts down!), but I know that I could use it like this:
public void onClose(CloseEvent<Window> event) {
//save changes to the datastore
}
I'm torn between the three methods and don't know which path to take! Any information will be helpful
Thank you!
Your current system follows a really excellent design pattern which a lot of apps (web- and otherwise) are picking up lately: Eliminate the manual operation of 'saving'. I think you should stick with it.
That said, if you want to reduce the number of round-trips and server load, you can do a couple of things: You could restrict the number of saves-in-progress to one, so that if the user makes a change while you're waiting for a 'save' request to complete, you wait until that request completes before sending a new one. Or, you could start a timer when the user makes a change, and commit any changes when the timer expires - this is pretty much how GMail's auto-save of draft messages works.
Either way, don't rely on a close event to trigger sending state to the server: If the user's browser crashes, the close event won't fire and they'll lose all their changes.
I want a automatic update notification in my application. A message box should appear which tells that an update is available, if user wants then it can download the latest version in downloads folder of windows. Nothing else (user will install it manually) not application.
-I'm using Installshield so no Click once solution.
Thanks
If you want an out-of-the-box solution to this problem you're likely to be disappointed. I haven't found anything that works except ClickOnce, and I dislike it. I did find this:
http://windowsclient.net/articles/appupdater.aspx
My solution was to roll my own. It's actually not that difficult. I wrote a small bootstrapper application that first checks for updates, downloads them if necessary, and then launches my application in a new AppDomain. Pretty easy.
If you want to check for updates while your app is running, you need to write and add a component/class to your project that performs that task, and informs the user (MessageBox or whatever) that an update is available. If they choose to perform the update then you need to launch your bootstrapper (so it can fetch the updates) and kill your current process.
All of this is very possible with a little time and some custom code. It's not as difficult as it sounds. The biggest thing is determining how configurable you want your custom solution to be because that can affect when/where your bootstrapper goes to look for updates (I built mine to look for updates on a network share).
http://autoupdatewpf.codeplex.com/
i found one. This one is quite simple and solve the purpose.
I'm working on an rather small application (C#, winform) that is kind of front-end to MS Access database file stored on shared drive. While it is possible that drive could be down I am checking connection while loading Main Form.
I would like to know your opinions on how to deal with this problem.
I came up with ideas like:
Application shows only MessageBox
with an error message and close
itself (before actually showing up),
as it won't be useful at all.
Application load itself and then
display an error-message to not make
users confused (if they click warning
before reading the explanation).
What are yours best practices?
I think it's rather irrelevant whether the application is shown or not because in the end, you display the message box with the error anyway. The user clicks OK and you close your Application.
However, to me it's a bit nicer without the application showing in background, mainly because it makes no sense to fire it up when the database isn't available. Save yourself (and the pc) the time it takes to show it ;)
I am currently running a SL3 project where we are in a highly iterative development mode with about 25 active test customers. I am making small changes at a clip of about 4 new builds per day. It is important to know this application is mission critical line of business for these 25 people, it is the tool they use all day to do their work so they are using it constantly and often launch their browser and the app in the morning and never close it until the end of the day.
The challenge is that when I make an update to the application I have no clean way to notify the users, in most cases this is ok as it is rare that I introduce a data contract change or something that would be a classic 'breaking' change to the app/service. Users keep plugging along and will get the change next time they refresh.
Right now we have resorted to emailing everyone and telling them to force refresh or close the browser and log back in.
Surely there is a better way...
Right now my train of thought is to have a method on the server that compares client xap versions and determines if the client being used is the most up to date, if so I will notify the user and make them update.
What have you done to solve this problem?
One way of doing it is to use a push mechanism (I used Kaazing Websoocket Gateway but any would do). When a new version of the XAP is released a message (either manually entered into the system by admin or automated triggered by XAP file change event) would be sent to all the clients. In the simplest scenario some notification would be shown to a user (telling him that a new version is released and the application needs to refresh) and then the app would refresh (by simply reloading the page) saving user's state if necessary.
If I would do this I would just keep it simple. A configuration value in web.config and a corresponding service method that simply returns that value (the value itself could be anything, but a counter is probably wise). Then you could have your Silverlight app poll that service method at regular intervals. Whenever the value changes (which you would do manually when you deploy a new version), just pop up a dialog telling the user to refresh the browser or log in/out. This way you don't have to force them to refresh every time. If you go with the idea of comparing xap file versions they will always be required to refresh, even for non-breaking changes.
If you want to take it further you could come up with some sort of mechanism to distinguish between different severity levels. For instance, if the new config value would contain the string "update_forced", you could force the users to reload the app by logging them out automatically (a little harsh, perhaps). If it contains the string "update_recommended", just show a little icon at the top right corner saying that there is a new version and that they should upgrade in their own time.
Granted, this was targeted at Silverlight 3, but with the PollingDuplex client and such in the newer versions of Silverlight, you could publish an "Update Now" bit to the clients, and build a mechanism in the client to alert the user that there is an update that is now out... that they should update it shortly, etc. You may even be able, through serialization and such, to save the state that they are in when they close the app to reload it.
We've done stuff similar with a LOB app that we built, so that as users are changing things, the rest of the userbase sees those changes immediately. Next up will be putting the flags in to change authorization and upgrades "on the fly" if you will.
What are my options for printing in Silverlight 3? Assume I have this awesome Silverlight application/control that creates a graphical display of some data. Now the user wants to print it.
I have considered a few options but I have yet to test any of these. Before I do that I would like to get some feedback on how it can be done.
Use the browser printing capabilites. In my experience this is does not provide a useful print, but perhaps with some interaction between the Silverlight host and the browser it can be done?
Use WriteableBitmap. The image can either be written locally, but this requires interaction from the user, or sent to the server where a suitable file (e.g. PDF file) can be generated and then sent back to the browser. Unfortunately you now get the overhead of sending the image twice across the network and increased complexity on the server side.
Send XAML back to the server that is then rendered in a WPF application running on the server. The result is the sent back to the client. I'm not sure if this is possible at all however, but if it is the network overhead is less than in option 2. Unfortunately, the complexity on the server side is even higher.
Wait for Silverlight 4?
One thing I have considered is that my awesome control probably will have a ScrollViewer at the highest level, but the user will want to print the entire content of the control, not just whatever is visible inside the bounds of the ScrollViewer. How can I handle this added complexity?
In all seriousness, I think your best option is to wait until Silverlight 4 if your client can wait that long. I've seen a good bit of buzz about SL 4 supporting printing on twitter, though it's not official. I'd wait until PDC in a few weeks and see if any Silverlight bits trickle out to support printing.
Take a look at SmartPrint for Silverlight 3: http://www.smartwebcontrols.com/SmartPrintDetails.aspx
TBH I wouldn't use any of those options:-
Printing from the browser. Fine if you are printing say a chart or something else that scales well on a single sheet of paper. Rubbish for anything else especially where you have scrolled content.
WriteableBitmap. I can't see a client-side only solution being acceptable to the user "Please save this and then print it" message. It could be made to work bouncing off the server but would be bad for bandwidth use (bandwidth is import right? because in a well-connect intranet you wouldn't using Silverlight?).
Sending XAML to server for rendering. Really awkward it would be WPF XAML not SL XAML, where and how would you do the binding, why send XAML at all, since the server needs to be pretty much clued in on this so why can't it hold the XAML needed as well. Or were you thinking of sending just pure XAML with all the data needed? Still its a lot of plumbing needed in the SL that isn't actually related to SL.
Use Silverlight 4, its possible that in the not to distant future this would be the correct no-brainer choice (personally I wouldn't hold my breath) but right now SL4 doesn't exist.
A 5th option
Place report generating code on the server and have the Silverlight app inform the server of the data set required (not necessarily posting the data merely the criteria needed to access the correct set). In my experience direct prints of GUIs aren't particularly satisfactory when the user really needs a good printed form of the data.
Its true that at times the user just wants to quickly get some offline access to a grid of data as it looks there and then. In that situation users often find an export to spreadsheet compatible file preferable to printing, which would be possible from SL.
Something akin to number two is pretty much your best bet and is what I've seen done for printing in most Silverlight apps so far.
You can have the app send content for printing back to the web server (i.e. a new handler or query string parameters to a printing page) and pop up another page for the user to print web content from, or you could allow the user to download a file and have them print that.
Sliverlight 3 does not support printing.
If you can wait for silverlight 4, they have given it "high priority"
If not use Writeablebitmap: http://www.andybeaulieu.com/Home/tabid/67/EntryID/161/Default.aspx