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.
Making HeidiSQL multi-threaded
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.
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.
link
If that works , it should be ewerywhere where cancel button becomes inaccessible and app hangs.
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++:
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;
}
}
Please login to leave a reply, or register at first.