I'm working on a C# WinForms app and I would like to know how can I make a "save state" button. I've heard about serialization, but I want the form to be restarted every run, but allow the user to reload the saved state.
For example, in games you can save your progress and then when you run the game you can either start a new game, or load the save (in either way, when you run the game you always get to the main menu, whether you want to start a new game or load the saved game), that's what I'm looking for.
I hope I've made myself clear.
you have to use the Isolated Storage in .NET to store application data clickhere
Many ways to do it however depending on the size and security specification of the information which needs to be loaded you could take different approaches.
One approach is surly what Dhaval Patel mentioned earlier [Isolated Storage in .NET]. If this information of yours is part of a wizard or something similar I would personally store them in a database table. This way your data will be quite accessible[Query-able] and you could enforce your security constraint much easier and you will have lots of room for maneuver in terms of future improvements.
Another advice[Only my personal opinion] : Don't pollute your config file with those settings in case you had that in your mind.
Related
I'm building a User Control using C#/Winforms and have struck a bit of an issue with localization.
I have added a number of strings to the resource file "inside" the user control, using the UserControl.resx file created automatically by Visual Studio. For the immediate term, these strings provide the Text values for the various buttons in the user control. I have tested this with location specific suffixes (ie, UserControl.zh-HK.resx), and all appears to work perfectly.
What I have found, though, is that the UserControl.resx file I am using gets wiped out, or cleared, at irregular intervals (I haven't nailed down exactly when it does and does not get cleared).
A big clue is that the IDE throws a message box when I attempt to edit this file. It says, in essence, that my changes may be lost. Experience has taught me that this is certainly the case.
For various reasons, the idea of having the resource file tightly coupled to the user control seems attractive. There are several of us, all developing user controls that are destined for the same product.
Is there any way to stop VS from smashing my string resources? Is there a better way, allowing for the fact that we want a separate set of resource files for each user control?
Thanks.
Long story short, everything I was doing was wrong.
In the end, what I have done is create a Resources folder in my project, with a separate set of resource files for each discrete component (form, user control, etc). Then in each component I retrieve the strings like buttonFoo.Text = Resources.UserControl.buttonFoo_Text.
This method seems to be working well enough for now and provides the separation of resource files that I wanted, while making the integration of the code from multiple sources semi-painless.
I'm making my first program in C# which is just going to be a simple note making program. I currently have ten tabs, each with a text box for a title and a description. However the program isn't too useful without having a way to save the content in each text box automatically either before shutdown or after editing the content, and then open them up again the next time the application is loaded, so that a potential user could just carry on with their previous notes etc. the next time they want to use the program. It isn't too good having notes deleted every time you close the app. Also, another option might be saving the state of the whole application as a cache or something, which would be easier than saving twenty text files (two per tab) if its even possible. I havent a clue how to do this anyway, and there is nothing too specific on here or any tutorials that I can find on google.
Thanks for the help anyway, I'd just like ideas and examples if you can!
Bye!
When researching the subject use the keyword persistence:
In computer science, persistence refers to the characteristic of state
that outlives the process that created it.
So persistence has many forms: text files, XML, databases, shoot even memory outside the application fits this definition (its a little silly to store things in memory because a restart would destroy everything).
Assuming this is a winforms application then we are talking about driving the application with events. You can have a submit button which somebody clicks to perform a Save to the "persistence" thing you chose (usually a database).
private void Save(object sender, EventArgs args)
{
//Gather text info e.g.: var myText1 = myTextBox1.Text;
//Save to the database or wherever using Stream
//or SqlConnection or something else. See below
}
You could choose to save to the database with a SqlConnection or to a file with StreamWriter.
I'm planning to develop an application that will read a log file and display statistics.
The first question, I guess, is to know if I need a database or not?
Will it be quicker to run queries against the database ; or read the file each time a user wants to see the statistics?
If I choose the database method, I will have to read the log file and update the database on a regular basis (between 1 and 10 minutes).
Is this article still good do you think (as it's from 2005): http://www.codeproject.com/KB/aspnet/ASPNETService.aspx
Or is it better to develop a Windows service? In that case, can I add the Windows Serice in my ASP.NET project in Visual Studio, or does it need to be
You mentioned ASP.NET so I believe it is a web application. In such case I would suggest to use Data Base, this is more robust, flexible and distributed solution.
Any way consider using log4net and then you can easily switch on file/DB ouput in any time by simply adding an other one appender section into the configuration file.
If I choose the database method, I will have to read the log file and
update the database on a regular basis (between 1 and 10 minutes)
Exactly, you're going to have to do it anyway. The Database basically just becomes another bottleneck at that point. For this type of app, there's no need to do anything other than read the file when the user requests to see it, and display them the results on the fly.
No need to have a windows service either. I mean, I don't know all your details, but I'm assuming the log file is in a directory on your machine, so just access it, open it, parse it, and display it to the user when they choose to see it on the front end.
If the only data you going to work is LOG files, you don't need any database.
But I assume that your application would do parse logs files, create some statistics and STORE it somewhere, to make possible to users to get back and see statistics for some period of time. It is not cool if any time you will be "re-calculating" that statistics again (further more, you might loose original log files till that time).
Even if you could store it to some files also, I do not recommed that at all. Don't be afraid of using Database, don't be concered on application performace on such early stage. Do the most that helps you to solve the problem.. and as for me using Database will solve your problem;
I need to create a patching routine for my application,
it's really small but I need to update it daily or weekly
how does the xdelta and the others work?
i've read around about those but I didn't understand much of it
the user shouldn't be prompted at all
Ok this post got flagged on meta for the answers given, so I'm going to weigh in on this.
xdelta is a binary difference program that, rather than providing you with a full image, only gives you what has changed and where. An example of a text diff will have + and - signs before lines of text showing you that these have been added or removed in the new version.
There are two ways to update a binary image: replace it using your own program or replace it using some form of package management. For example, Linux Systems use rpm etc to push out updates to packages. In a windows environment your options are limited by what is installed if you're not on a corporate network. If you are, try WSUS and MSI packaging. That'll give you an easier life, or ClickOnce as someone has mentioned.
If you're not however, you will need to bear in mind the following:
You need to be an administrator to update anything in certain folders as others have said. I would strongly encourage you to accept this behaviour.
If the user is an administrator, you can offer to check for updates. Then, you can do one of two things. You can download a whole new version of your application and write it over the image on the hard disk (i.e. the file - remember images are loaded into memory so you can re-write your own program file). You then need to tell the user the update has succeeded and reload the program as the new image will be different.
Or, you can apply a diff if bandwidth is a concern. Probably not in your case but you will need to know from the client program the two versions to diff between so that the update server gives you the correct patch. Otherwise, the diff might not succeed.
I don't think for your purposes xdelta is going to give you much gain anyway. Just replace the entire image.
Edit if the user must not be prompted at all, just reload the app. However, I would strongly encourage informing the user you are talking on their network and ask permission to do so / enable a manual update mode, otherwise people like me will block it.
What kind of application is this ? Perhaps you could use clickonce to deploy your application. Clickonce very easily allows you to push updates to your users.
The short story is, Clickonce creates an installation that allows your users to install the application from a web server or a file share, you enable automatic updates, and whenever you place a new version of the app on the server the app will automatically(or ask the user wether to) update the app. The clickonce framework takes care of the rest - fetching the update , figure out which files have changed and need to be downloaded again and performs the update. You can also check/perform the update programatically.
That said, clickonce leaves you with little control over the actual installation procedure, and you have nowhere close to the freedom of building your own .msi.
I wouldn't go with a patching solution, since it really complicates things when you have a lot of revisions. How will the patching solution handle different versions asking to be updated? What if user A is 10 revisions behind the current revision? Or 100 revisions, etc? It would probably be best to just download the latest exe(s) and dll(s) and replace them.
That said, I think this SO question on silent updates might help you.
There is a solution for efficient patching - it works on all platforms and can run in completely silent mode, without the user noticing anything. On .NET, it provides seamless integration of the update process using a custom UserControl declaratively bound to events from your own UI.
It's called wyUpdate.
While the updating client (wyUpdate) is open source, a paid for wybuild tool is used to build and publish the patches.
Depending on the size of your application, you'd probably have it split up into several dll's, an exe, and other files.
What you could do is have the main program check for updates. If updates are available, the main program would close and the update program would take over - updating old files, creating new ones, and deleting current files as specified by the instructions sent along with a patch file (probably a compressed format such as .zip) downloaded by the updater.
If your application is small (say, a single exe) it would suffice to simply have the updater replace that one exe.
Edit:
Another way to do this would be to (upon compilation of the new exe), compare the new one to the old one, and just send the differences over to the updater. It would then make the appropriate adjustments.
You can make your function reside in a separate DLL. So you can just replace the DLL instead of patching the whole program. (Assuming Windows as the target platform for a C# program.)
I'm writing a program that deals with the logs generated by the clients server. How can I detect where the user is storing them? It feels invasive to search all files, but what if they're being stored outside of the root. Is this acceptable, what if I make the user click "detect" first? Regardless, what if they've been renamed and reformatted? Is it possible to read the server settings themselves from my external program? I want this to work on linux and windows servers. I need WC3 Extended format w/ several fields enabled that are not naturally. I also don't want it to return null if it's enabled but no log has been yet created. I don't want to force the user (assumed dumb) to play with settings.
Any ideas?
Hardcode where you expect them to be in the common case, and if they're not there, ask the user about it. Doing more "magic" than that seems like a recipe for over-complexity and mistakes.
If the user is specifying the location of the log file, then either you should have the user locate the file(s) themselves or keep track of these locations somewhere else when they are saved. You don't need to be doing a full (or large partial) drive search.