I have designed an app in vb.net 2005 that at one point adds and loops over about 500k list in listbox about.
When adding these items to the listbox, the app freezes for about 5-10 minutes, then when looping over the items, processing them, the app also freezes for the same time. Am loading the data from a text file
How can I make my application
responsive during loops?
should I use a queue to process the
list?
what is the messagequeue control
for?
I recommend you to use BackgroundWorker. Store items in array, and bind listbox to it. Working with array will be much faster then with listbox'es collection.
Or you can call BeginUpdate/EndUpdate before/after adding new items.
Related
vb.net
I have a form(called Form1) that is very slow because it contain datagridview how load data from sql server.As a result the form takes a long time to loaded.
So I create a form_Wait and in the load event of Form1 I put
Form_wait.showdialog()
Load_datagridveiw1("Select * from table1")
Form_wait.close()
My problem is the Form_Wait will be appear but the gift inside it (rectangular progress bar) is not showen ?
I used VS 2015
You cannot meaningfully show and animate GIF in a same thread as your UI sits. You would have to use a BackGroundWorker, which is basically a separate thread. Then the animation will work smoothly and the UI thread will run fine too. There are plenty of BackGroundWorker tutorials on the web.
But a huge warning horn rings reading your words. If it is such a huge amount of data causing the slow loading, I would strongly suggest to reconsider how do you fetch the data. Introducing meaningful filters and pagination are basic ways to tackle this.
Hi I'm currently having a datagridview with thousand (about 3000+) rows of record and 9 columns. I was using this method I found to export the datagridview to excel. There was no problem exporting hundred of rows but when it comes to thousand of rows, it hangs and it wouldn't respond to anything.
What problem could it be? and if there's any other way that is faster/better than this?
Thank you!
The code is being executed on the UI thread so of course your application would freeze while it's executing. If you want the UI to remain responsive then you'd have to execute the code on a secondary thread. The issue there is that the data is coming from a control, so that part at least must be executed on the UI thread.
I would suggest that one possibility is to use a BackgroundWorker and do the work in the DoWork event handler. You can set up a loop that calls ReportProgress, which raises the ProgressChanged event on the UI thread and allows you to get the data in pages, then write it out to your spreadsheet on the background thread. I'll follow up with an example.
I am looking for an effective, quick way to show multiple labels in a quick fashion. What's a good way to do this other than replacing all the .text properties of the labels one after another? It is my understanding that whenever you update a .text property the UI has to be repainted which will add to latency if you have 50+ controls to update.
I know threading is an option but when I tried this I didn't see much of a difference as I wasn't able to load 2 labels at once, I still had to wait for the UI thread before the labels would update. What other ways are there to effectively load 50+ labels quickly? The way it is now takes quite awhile(3-4s) and I feel this could be lowered. The information is being taken from a backend system so I don't have the option for datasets/etc.
You have to separate the code that retrieves the data from the database (which you do using a background thread) and the code that updates the UI (which should happen as quickly as possible because you don't want to block the UI for too long).
My suggestion would be to use the BackgroundWorker component to do retrieve the data for all 50 labels. When the BackgroundWorker raises the RunWorkerCompleted event you call the forms' SuspendLayout function, update all the values of the labels and then you call ResumeLayout. SuspendLayout stops a control from redrawing until you call ResumeLayout.
More info: BackgroundWorker, SuspendLayout, ResumeLayout
I have been beating my head against the wall for 2 weeks now, while trying to figure out a way to navigate through the rows of the DataGridView component with threads. I want to do this, because if the gridview is more than 300+ rows long the UI will hang up for about 30-60 seconds.
I am new to multi-threading, but I do know now the importance of thread safe applications and having to make sure that changes to UI components are done on the UI thread.
The steps i want to take are as follows(Unless someone has a better suggestion):
User selects an item in a ListBox
Disable UI interaction from the user
The datagridview is broken up into searchable ranges
search through each range in parallel and hide any rows that match the items that are selected in the listbox.
resume UI interaction to the user
Ultimately I want to beable to select multiple items in the listbox to hide or show them.
What I am looking for is someone to give me some idea as to where to start? Should I go with background worker, Task Parallel Library, custom threads, ect...?
Let's say I have a ListBox:
ListBox myListBox = new ListBox();
myListBox.Items.Add("One");
myListBox.Items.Add("Two");
myListBox.Items.Add("Three");
I need to save these items somewhere in the project so that the only way getting rid of it is to uninstall the app, is it possible?
If you have the items added as you have shown, you would have to first iterate the listbox to get the items in order to persist them. A better option is to have the items stored in an array/object/whatever elsewhere and use that array/object/whatever to both persist the list and to populate the listview.
Then, hook into the application Suspend event. In the event, you can persist the array/object/whatever to local storage or to the cloud, depending on what you want. You would then check on app resume/startup if persisted data was available and restore it if it is.
Some useful links:
Application.Suspending event
Guidelines for app suspend and resume
Part 2: Manage app lifecycle and state