3.16 GUI version drawing diagonal lines in drive map

[Brooklyn98]

I still see the issue.  I just emailed you a detailed log of this diagonal issue with 3.35e.  Let me know if you need anything more.  I've see these on my systems during my testing but I've ignored them since it was only graphics.

Question on 3.35e:  when jkdefrag finishes what should it be showing?  I've run on a few different machines and some show a black screen when done saying finished and another shows the GUI diskmap with finished up top.  This is nice to show the finished map.

[jeroen]

I still see the issue.

Thanks for testing, I appreciate it! It's a pity that it hasn't fixed the problem.

when jkdefrag finishes what should it be showing?

Normally when JkDefrag finishes it will show "finished" and an empty diskmap. When you run JkDefrag with some explicitly specified disks (for example "jkdefrag C:\") then the program will show the diskmap of the (last) disk it has processed. It cannot redraw the diskmap, because the information has been cleaned up from memory, so if the program receives an instruction from Windows to redraw then the diskmap will turn black.

[elfring]

No, the other problem is not caused by a mutex problem.

I suggest to introduce a third thread for better separation of the tasks "GUI drawing" and "defragmentation API calls".
Another open issue might be relevant here that a few return values are still ignored. Would you like to detect an error code from a function call like "WaitForSingleObject"?

[isgdre]

I suggest to introduce a third thread for better separation of the tasks "GUI drawing" and "defragmentation API calls".

Hummmm... I don't know about that one.  It's been my experiance that when you have a thredding problem adding more threads never fixes the problem.  All you end up with is more threads and more posibilities as to what could be going wrong.   And you still have to fix the original problem.   

True, By chance you could move things around a bit so the problem doesn't manifest it's self that often.  But really that's just putting things off until faster computers, more cores, or OS changes brings the problem back to the for-frount.

I'm not agenst more threads.  Just let's fix the problem before we make it more complicated.

Besides.  I don't mean to say anything bad about the main developer because we are all there in one way of another, none of us can clame to know everyting..  But it seems more of a learning the quirky windows Threading issue then anything else.  More threads will not help that.

Doing process control I end up doing threading all the time.  The main program HUGE and has upwards of 100 threads running.  It's always a pain.  Luckly for me I don't have to deal with the windows GUI.  So I tip my hat to one who gives it a go.

[elfring]

I'm not agenst more threads.  Just let's fix the problem before we make it more complicated.

I suggest more threads as a means to make the involved tasks clearer. A bit refactoring might help to find the error reasons. Are the used software components independent enough to narrow the open issues down?

[elfring]

It means that Windows itself is not thread safe....

Did you find an acknowledgement in the documentation that the Windows GDI API is thread-safe?
I guess that the calls of the functions "PaintScreen" and "DrawCluster" from separate threads are error candidates for drawing synchronisation and reduced responsiveness.

Would you like to reuse any experiences from other information sources?
Examples:

• Article "Designing for Thread Safety" by Bill Venners
• Article "An Alternate Way of Writing a Multithreaded GUI in C#" by Keith Balaam
• Threading and Windows Forms
• Chapter "Writing Responsive User Interfaces with Swing"

[elfring]

No, the other problem is not caused by a mutex problem.

Another idea ...
I am not sure if the source code from the 3.34 release is compatible with your private 3.35f () version for the file "JkDefrag.cpp".

Can it be that the call "WaitForSingleObject(WindowMutex,INFINITE)" is a few lines too late in your callback function "DrawCluster"?
I guess that a safer position would be directly before the use of the global variable "WindowSize". (I would prefer that the global variable "TopHeight" will only be initialised at application startup.)

[jeroen]

Would you like to reuse any experiences from other information sources?

Thanks for all the links.