Try using a different thread to go through the list of packages to add packages to the DataGridView so we don't have to lock up the UI, and use events from that thread to update the progress bar.

[DrewNaylor]

May help a little, at least. Maybe we can also use separate threads to help with getting package descriptions into the main DataTable.

[DrewNaylor]

I'd have to use delegates for this so that it doesn't complain about cross-thread stuff. Maybe a thread-locking thing, too. Would need to do the same for #170 somehow, too. Definitely would need to ensure we don't mess up the progress bar.

Edit: wait, that's a little different there, I got confused.

[DrewNaylor]

Also, could we use more than one extra thread (in addition to the form thread) to handle all these packages and just sync when we're ready to add one to the list? I think a user-configurable max would be necessary to implement, so we don't spiral out of control when creating new threads, but default to the maximum number of threads in a system with a checkbox to manually set the number of threads to use? This way a user with 4 cores and 8 threads could say to just use 8 threads, or someone with 2 threads could just say to use 1 thread (in which case hopefully Windows Forms/.NET can handle threads that don't really exist but actually that should be fine if they have 2 threads and is only a concern if their system is single-threaded but what is nowadays?).

So we'll spawn a new thread when we're ready to get the info loaded into the DataTable and later DataGridView as long as we haven't reached the max by the time we get back to the code, in which case we should wait until a thread is ready? I don't know.

[DrewNaylor]

I think a thread pool would allow it to manage the threads automatically so I don't have to worry about running out of threads.