I'm not posting any code here, because the question is more general. So I need to populate datagrid with values by calling table adapter's methods (2 tier app). Usually I do that in form load event. Since recently though, database server becomes unavailable which results in a hanging form. That's nasty.
Could you share some common scenarios you use to avoid that?
May be I should rather do that in Shown event? And yet better do it asynchronously, say with a backgroundworker?
I do in this way:
- I disable datagrids and show some message in a StatusBar
- In Shown event I start a BackgroundWorker that loads from db and fills datasets
- When worker completes its job I enable datagrids...
In this way your form can handle user inputs without hanging or having refresh problems...
Related
I’m working on a multi-user winforms application (MDI). Our application uses NHibernate and one session per instance.
The problem is if an user makes modification, for example a user adds an item to a list, another user doesn’t see this modification immediately. How do I get around this, what is the recommended approach? Should I be using One-session-per-form or something else?
Every application needs to define it's own unit of work. For your use case, if you are wanting the database to update every time a user adds an item to a list, then that should be your unit of work.
So to answer your question for your unique use case, I would create a new NHibernate session, persist the users changes, and dispose of the session every time a user adds an item to the list.
FYI: You should not feel that there is anything wrong with creating a session per user action if that is indeed the behavior your application desires. Typically in a WinForms application, most people do use a Session-per-Form pattern but then again, that is because most WinForms applications fall into the model of having a form that the user needs to complete before proceeding to the next form. In those cases, you would only want to persist/save the user's changes when they submit the form. But if you application does not fall into that model, then your definition of a unit of work ( session life-cycle ) could be completely different.
I'm using Siaqodb for my client side database engine in a Sync Framework silverlight project. I've switched to siaqodb because microsofts client side solution loads the entire database into memory at once and, as such, has a hard time handling large data.
I've bound a list of SiaqodbOfflineEntity objects to a silverlight datagrid in order to create an editable datagrid. Unlike microsofts solution, you can't bind the database entries directly to the datagrid. You have to query the database and bind a list of in memory objects to the datagrid. This causes a problem in that the database isn't immediatly updated when the datagrid cell is changed. I'm trying to find the best way to handle updates to the database after a change in the cell. I can't just update each item to the database because the siaqodb engine will mark the item as dirty even if no change was made to the object. This will cause conflicts when trying to sync. holding a cached version of the original list and then comparing each property of each object to find which ones have changed seems like it would work, but seems to be a bit cumbersome. I've also tried looking at some of the datagrids events but RowEditEnded doesn't appear to fire when a cell is edited and CurrentCellChanged seems to fire whenever I switch rows (odd).
There's got to be a better solution to this. Anyone have any ideas?
So I've gotten this to work by changing my offline entity classes to implement iNotifyPropertyChange and I think this is a reasonable solution. I set the PropertyChanged event to a function that saves the object to the database. There is a VS package called notifypropertyweaver that will inject this code at compile time, reducing the amount of work needed to be done on auto-generated entity code.
We have a windows program written in vbasic(i think) and we are re-writing the same program in c#. In the old program there is a grid. When we click any cell and as soon as edit the cell content the data in database is changing. In our new program we couldn't find the way of doing that. So we added some buttons for database actions like update selected cell.
What is the best way to do that?
You can do this in c# too.Use a datagridview and to bind with the database so that change in the grid effect database see here
Out of seeing dozens of legacy ODBC frontends put together in Access I would strongly advice not to commit changes in the database at real time. Instead try to create a lightweight process that helps the users to keep their data's quality high.
If you want this kind of functionality you could have the real time changes saved in a different schema, a set of different tables or with a flag that tells that these rows are unverified edits by the user X.
Rasel already gave you a pointer how to do the functionality in C#.
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..?
I'm building a single window WPF application
In the window is a list items (which are persisted in a database of course)
Periodically I need to start a background task that updates the database from an Atom feed. As each new item is added to the database, the list in the UI must also update to reflect this. I don't want this background task to slow down the UI but at the same time it needs to interact with the UI.
Having read loads of articles and seen lots of simple examples, I am still unsure of the best way to implement this.
What I think maybe I could do is:
On the Window_Loaded event, create a DispatchTimer.
When the Tick event fires, call UpdateDb() method.
UpdateDB() will get the items from the Atom feed and add to the database. As I iterate through each item I will call another method to rebind the list to the database so that it "refreshes".
When all the tasks are finished reset the DispatchTimer ??? (not sure if this can / needs to be / done).
Remember, this is background task so a user could be using the UI at the same time.
How does this sound?
Thanks.
This sounds suboptimal because you're doing database connectivity on the UI thread. When the Tick event fires on the DispatcherTimer, handlers will execute on the UI thread. You need to minimize the amount of work you do on this thread to keep the UI responsive, and you definitely shouldn't be doing IO-bound work on this thread.
I would probably have a data service whose responsibility is to update the database and raise events as changes are made. Your UI layer can attach to these events and marshal to the UI thread to apply changes. To marshal to the UI thread, you just need to call Dispatcher.Invoke.
Regardless of your specific approach, the key is to do as much as you can (including any database access) on a separate thread. Marshal back to the UI thread as late as possible and do as little work as possible on the UI thread.
One other thing to note is that WPF automatically marshals changes to scalar values for you. You only need to marshal changes to collections (adding/removing/replacing items).
Your approach would work.
You'd start the timer when the app loads. For each tick of the timer, you start a thread to update the database. Once the database update has happened, you can call .BeginInvoke() on your UI objects to update the UI on the presentation thread (that will be the only time your UI should be affected).
I'd use a System.Threading.Timer, which will call a specified method at a specified interval on a threadpool thread, so no need to create an additional thread, do your db work with that and marshal back to the ui thread as needed.
WPF Multithreading with BackgroundWorker by Pavan Podila:
The good news is that you really don’t have to write such a component since one is available already: the BackgroundWorker class introduced in .Net Framework 2.0. Programmers who are familiar with WinForms 2.0 may have already used this component. But BackgroundWorker works equally well with WPF because it is completely agnostic to the threading model.