Making HeidiSQL multi-threaded

Hi Anse,

Have you considered making HeidiSQL multi-threaded? I accidentally clicked "Show all" the other day on a table with over 200 thousand rows, and because the UI freezes, I couldn't click to cancel it.

Also, when you run updates, for some reason the update dialog shifts position causing the UI to freeze, so you can't view the download progress, etc.

Thanks for the software.

Regards,

Glen.

HeidiSQL's query execution *is* multithreaded. But nothing else yet, for simplicity reasons, and because I decided to minimize the effort in the myriad of GUI elements where someone could expect a threaded execution. It's just too much effort to make everything threaded. Also, and that's more interesting, the connection, or let's say the server, does not allow to fire more than one query at a time. If you do, you get a "Commands out of sync" error. That's why the "Cancel" button on query execution kills the query with the help of a second session. Well, in the end I know at least how to write a multithreaded application, and I know it's sometimes not worth the effort.

Then why is it not possible to cancel the "Show all" execution? And can you fix the update issue?

With "query execution" I meant executing queries from a query tab. Not retrieving data for the data tab. Sorry if I was unclear.

The update issue is not critical in my eyes, more cosmetic. I should not add tons of code lines just to fix that.

And it's difficult to make the data tab operations run on a separate thread?

WRT the update window, do you know what causes it to shift position during an update?

Difficult? No, too much effort for a minor effect.

That shifting is done by Windows, when its logic decides that a window is not responding fast enough.

It's not a minor effect, if the UI is blocked during execution resulting in the cancellation button not being functional, then it's a flaw in the software.

I accidentally clicked "Show all"

I agree, I do oftenly click 'accidentaly' on data tab, and here I'm, the table is 'humonguous' and takes ages ... Actulay it does not, I kill hsql process and restart. Loose any queryis opened, not auto saved as my wish would be (as at firefox browser)

It is a bit of time since I last did multithreaad in delphi, in vb it was super easy:

link

If that works , it should be ewerywhere where cancel button becomes inaccessible and app hangs.

Hey, it's not that I said I don't know how to implement multithreading, did I? Please read the above comments. The point is totally different.

I should not add tons of code lines just to fix that.

I did not say you don't know how to implement multithreading, just implementation could be supoer easy (not tested.)

And, I do remember it takes a master to do multithreading right in delphi.

I was convinced I did it right and all looked OK for a year and then problems arrised (-:


The point of thread is at te top (first post):

...the UI freezes, I couldn't click to cancel it.

I think one should differentiate between real multi-threading and keeping the UI responsive during a long-lasting operation.

BTW: VB's DoEvents has nothing to do with multi-threading. It's just "processing pending window messages", therefore the UI keeps responsive but the execution time of the long-lasting operation gets even longer...

Keeping the UI responsive is not that difficult and can be done in a few lines of code...

- Start a different thread using CreateThread()
- Wait for the thread to be finished (in the UI thread) using a WaitForSingleObject loop with a given timeout of i.e. 250 ms. If return value = WAIT_TIMEOUT, then run the message routines to process pending window messages, i.e. PeekMessage/GetMessage/TranslateMessage/DispatchMessage (= equivalent to VB's DoEvents). This makes it possible to check cancel button clicks etc.
- WaitForSingleObject returns WAIT_OBJECT_0 if the thread finished
- Go on in main thread

Simple as that.

VB's DoEvents function looks like that in C++:

void DoEvents()
{
MSG oMSG;
while(::PeekMessage(&oMSG, NULL, 0, 0, PM_NOREMOVE))
{
if(::GetMessage(&oMSG, NULL, 0, 0))
{
::TranslateMessage(&oMSG);
::DispatchMessage(&oMSG);
}
else
break;
}
}