There is some way for reset wpf application fully? I mean not application restart
Process.Start(Application.ResourceAssembly.Location);
Application.Current.Shutdown();
Above code shutdowns current window and opens new.
I ask, if there is a way, for fully reset all happened events and set starting values for variables, XAML objects and etc. without window closing?
Of course, this may make step by step for every variables and objects, but may be exists some short method?
No, there is no fast method. The best bet is to use an architecture that separates Model/state from View and then create a new instance of your model. MVVM is a good architecture for WPF and will do just fine.
Related
I have a C#/WPF/.NET 4.5 app that users will use to open certain files. The app will then go through a lot of motions - read the file, pass it trough a number of plugins and parsers. The files are potentially fairly big (>100MB) so this could take a while. I want to keep the user informed about what is going on in the UI, so in my viewmodel I have some stuff for showing current status and a progress bar.
Now I want to be cool and modern and do this using ReactiveUIs Async command support, which is completely new to me.
For the feedback messages from the load/parse process, what is the best approach? The status message and progress bar val/max values need to be set on the UI thread, pretty basic stuff. Should I implement my data loader as an IObservable, or is it somehow better to do this using for instance the MessageBus component?
Keep in mind that a user might be loading several of these huge files into the app at once, and I want the UI to remain as responsive as possible while the loading is going on.
Examples of how to go about implementing this properly would be hugely appreciated!
I checked this with The Master himself (Paul C. Betts) elsewhere, and he told me that the way to handle this would be for the app that displays the progress information to create a Subject<SomeProgressInfo> and pass this to the guys doing the actual loading/parsing. These can then push new information to the host using .OnNext().
This also helps with unit testing, where one can just provide a dummy Subject<T> that won't be subscribed to.
I was considering using a Singleton pattern in a winforms application that I am working on, but a lot of people seem to think that singletons are evil. I was planning on making a "Main Menu" form which is a singleton. I can't think of any reason that I would want multiple instances of my Main Menu, and it is always going to be the first form that comes up, so I am not concerned with wasting resources if it gets instantiated unnecessarily.
Also, I could see issues arising if there are multiple instances of the Main Menu. For example, if another form has a "Main Menu" button and there are multiple instances of the Main Menu, then the decision of which instance to show seems ambiguous.
Also, if I have another winform which has to look at the state of the program to determine whether there is already an instance of the main menu, then I feel like I am breaking modularity, though I might be wrong.
Should I be avoiding the use of a singleton in this case or would it be better to make the Main Menu static?
I just started using c# a couple days ago, and I haven't really done much with OOP in the last few years, so I apologize if this is a stupid question.
Thanks
Is MainMenu shown all the time? If not, it would make sense to release the old instance when it's closed and create a new one every time you need to open it. This way other modules won't need to know of its instances, they'll just create one when they need to open it.
People like global state. It is apparently easy to understand, and makes sense to us. You don't have to worry about which version you are using because they are all the same.
However global state introduces all kinds of odd errors, so is generally discouraged. C# made many design decisions to make global state harder to miss use. For instance you are allowed static variables only attached to a class that must manage them.
Singletons are another way to get this global state, however they are similar in that they can cause issues. What if one of your screens sets a part of the main menu then transitions to it, not realizing that a background process undid the change, resulting in an odd main menu being displayed?
The other alternative to singletons is to ensure that the variables reach where they are needed. One way of doing that is to keep track of a stack of menus, in fact Android works like this underneath. Every UI gets a set of parents that are above it, that it can switch to if it wants to go back. By ensuring that only your initial boot up process creates the initial main menu screen, you can guarantee only one is created, however all screens can still access it by checking the hierarchy.
Additionally if you are talking about winforms, they already have a hierarchy system built in that you can use to provide this functionality.
You can abuse almost everything.
A singleton is a way to guarantee that there is only one instance of an object active at any time, and you can synchronize access to it. With a static class you lose that, since the static class can be accessed by anyone at any time, you need to make sure your methods don't do nothing that can be affected by concurrency.
Beyond that, if i'm reading you right, you want a form that would be the parent form to have the only instance of your menu and all other form would be childs of this one. If this is the case then you should check MDI (Multiple Document Interface) in Winforms since this will cover your scenario just right.
Otherwise, what i would do, is simply to define a class for my parent form (the one with the main menu) and have a singleton expose accest to it, and use another base class for all the child forms.
i have a c# application and there are a lot of forms with controls.
And every time when i run my application, forms which have many controls open slow.
So is there any way to make it open faster?
As you can see from the comments, there isn't one universal "make things faster" technique. You need to find the bottleneck and fix it. Here are some pointers:
Are all your controls on all your forms added statically in the designer, or added dynamically at runtime based on environment/user details/loaded dynamically via reflection? These can significantly slow down UI load time.
Do you have hundreds of controls on a single form? If so, consider splitting your forms to smaller chunks.
Do you have complex logic or data access during your Form_Load events? This can also slow down UI responsiveness. Consider starting the application "clean", and then loading the data asynchronously.
Use a profiler! Find a good, simple profiler to see where, exactly, you're spending your time. You'll often be surprised at what actually takes time. Use a trial version of a good, established profiler like dotTrace or Ants, and consider buying it for the future.
Instead of making it load faster, I would recommend you to give better user experience to your user.
First, load a Splash View (with loading progress) first. On next thread running in background, load your View with a lot of controls. When your view loaded completely, hide the Splash View and show your View.
In case you do something timeconsuming code with the controls in form constructor or while loading form you can write this.SuspendLayout(); before that code and this.ResumeLayout(); after that code. That prevents several time-killing layout operations.
Considering the information in question provided I wolud say:
Devide controls in possible groups (It's practically impossible that user needs all controls at the same time) and put them on separate Tabs of tab control.
Automatically (statially) load only controls on fisrt Tab, for others load them dinamically.
In this case, if the user doesn't need certain functonality will never switch to the Tab that contains it, so the controls of that functionality that user doesn't need will not be loaded, which will provided overall faster load time.
If there is a data that should be pushed on the controls, load it in async way where it's possible,
Hope this helps.
I have had a similar problem, but with many more controls than yours.
Considering that you have a relatively small set of controls, I think the culprit is the data access layer slowing down everything. (The loading of that grids and combos for example)
A simple action that can tell you many things is to move your data access to the form_shown event.
In Visual Studios (under the Solution Explorer), you can right click your solution/solution name and select properties at the bottom of the list. If you select "Configuration Properties," then go under configuration, you can select "Release" instead of "Debug." This will shave time off loading significantly.
Also, it is wise to avoid using "Thread.Sleep" in your code. This method is often used and mostly for poor code writers. About 10% of it is viable for particular circumstances, but I would avoid it at all cost.
Best way is to separate your solution to many layers
YourAppUI contains forms
YourApp.Controls contains controls
YourApp.BLL contains business logic
YourApp.DAL contains data access layer
Is it possible to update an application to a new version without closing it?
Or is there a good way to do that without user noticing it was closed?
Typically applications notice on startup that an update is available, then ask the user whether it's okay to update. They then start the update process and exit. The update process replaces the files, then launches the new version.
In some cases you may be able to get away with updating some pieces of an application without a restart - but the added complexity is significant, and frankly it's better not to try in 99% of cases, IMO.
Of course, you haven't said what kind of app you're writing - if you could give more information, that would help.
The application needs to be closed before updating it, because updating an application generally means replacing the executable files (.exe, .dlls, etc.) with their newer versions, and this can't be done without closing the application.
As Jon said, in some cases, you can upgrade the application without closing it. But, this is not advisable, as it might cause failure in the updater, and the whole update might rollback.
Updater can be another executable which will first close the main application, then download the updates, apply them, start the main application, and exit (An example of this is Skype, FireFox, etc.)
You could separate the backend into a separate process/module and update the the backend by restarting it without the user realizing it.
Updating the front end will be a bit trickier, but could be avoided or delayed, if necessary.
A nice and clean way to achieve this would be using dynamic plugins.
You can code your application heavily plugin-based. When an update is needed, unload the plugin that needs to be updated, update the .dll file and load it back into the application.
However, making this invisible to the user may be a tough job, therefore it depends heavily on your design and coding.
I remember InTime having the ability to swap exe's live, however that had to be carefully coded. I know it's possible but as Jon Skeet said, you're likely better off not trying.
Unless you're doing some kind of automation or something very serious... even then, you should consider a failover so you can shut one down / restart if needed.
If you has some some sort of skeletal framework which launched your application and dlls, you could look at CreateDomain. It will take serious design efforts on your part though. Good luck!
I need to make an application in .NET CF with different/single forms with a lot of drawing/animation on each forms.I would prefer to have a single update[my own for state management and so on] function so that i can manage the different states, so that my [J2ME Gaming Code] will work without much changes.I have came to some possible scenarios. Which of the one will be perfect?
Have a single form and add/delete the controls manually , then use any of the gamelooping tricks.
Create different forms with controls and call update and application.doEvents() in the main thread.[ while(isAppRunning){ UPDATE() Application.DoEvents() }
Create a update - paint loop on each of the form as required.
Any other ideas.
Please give me suggestion regarding this
If its a game then i'd drop most of the forms and work with the bare essentials, work off a bitmap if possible and render that by either overriding the main form's paint method or a control that resides within it (perhaps a panel). That will give you better performance.
The main issue is that the compact framework isn't really designed for a lot of UI fun you don't get double-buffering for free like in full framework, proper transparency is a bitch to do with WinForm controls and if you hold onto to the UI thread for a little too long you'll get serious rendering glitches. Hell you might even get those if you do too much on background threads! :O
You're never going to get optimal performance from explicitly calling Application.DoEvents, my rule of thumb is to only use that when trouble-shooting or writing little hacks in the UI.
It might be worth sticking the game on a background thread and then calling .Invoke on the control to marshal back to the main UI thread to update your display leaving the UI with plenty of time to respond while also handling user input.
User input is another reason I avoid normal winform controls, as mobile devices generally don't have many keys it's very useful to be able to remap them so I generally avoid things like TextBoxes that have preset key events/responses.
I'd also avoid using different forms as showing a new form can provide a subtle pause, I generally swap out controls to a main form to avoid this issue when writing business software.
At the end of the day it's probably worth experimenting with various techniques to see what works out for the best. Also see if you can get any tips from people who develop games on CF as I generally only do business software.
HTH!