Jump to content
dummzeuch

GExperts supports even more laziness

Recommended Posts

20 hours ago, Mahdi Safsafi said:

@dummzeuch I made some debugging and was able to get much more information about the exception. On the attached file you will find a lot of useful stuff plus some comment for clarification.  

I hope, you will find it useful for GExperts.

This is awesome! I have tried it with Delphi 10.2 so far (no optOSX64 there) and it worked as advertised. Now I need a break, my head is smoking! (had a bad day on top of that)

Share this post


Link to post
On 7/22/2020 at 12:34 AM, Mahdi Safsafi said:

One question:

        { when a system fires a debug event, it blocks all process(process being debugged) threads.
          and only ContinueDebugEvent function resumes the suspended threads.
          However, DoShowException is called from another Delphi IDE thread(not the thread that is debugging)
          meaning, you need to sync access using monitor/ccritical_section.
          moreover, implementing a stack of TDebugEvent in a way you push here and you pop DoShowException so you don't miss any event.
        }
                FDebugEvent := lpDebugEvent^;

I understand why I should protect access to FDebugEvent for multithreading. What I don't get is why a stack should be necessary. Could you please give an example?

Share this post


Link to post
1 hour ago, dummzeuch said:

One question:

I understand why I should protect access to FDebugEvent for multithreading. What I don't get is why a stack should be necessary. Could you please give an example?

WaitForDebugEvent function is called from the debug loop thread but DoShowException function is called from another thread. A fraction of eye before DoShowException is called, WaitForDebugEvent may receive a debug event exception which may override FDebugEvent variable and you may end up processing the new exception and missing the old one. Using a list of FDebugEvent will guarantee that for each exception, you have a valid associated FDebugEvent struct.

I don't know if there is a better way to work around without using a list of FDebugEvent. If you find a better way, please let me know.

 

Apart from that, are you making any progress ? did the non-WaitForDebugEvent-method worked for all new Delphi versions ? 

 

Share this post


Link to post
10 hours ago, Mahdi Safsafi said:

Apart from that, are you making any progress ? did the non-WaitForDebugEvent-method worked for all new Delphi versions ?

I got it to work for Delphi 2005 and later. There was one version which did not support the new methed even though it is not restricted to Win32. I think it was XE2, but I am not sure any more. I made too many changes this weekend. I need to go back to that case and test it again.

I have committed my changes to svn last night, if you want to have a look.

Share this post


Link to post

Currently very much enjoying this feature while running unit tests with a lot of exception checking under the debugger! 👍

  • Like 2

Share this post


Link to post
36 minutes ago, Stefan Glienke said:

Currently very much enjoying this feature while running unit tests with a lot of exception checking under the debugger! 👍

Yes it comes very handy and it would be much more powerful when it supports class inheritance check(ignoring all exceptions that descent from a particular class). 

One thing worth to mention, Thomas told me that he managed to make it works on all Delphi versions >= 2005.

Share this post


Link to post

If remotely possible, make an intermediate build with this feature. I think many would love test drive it (me included, other hand should check out how to build and install myself).

Share this post


Link to post
On 7/6/2020 at 5:24 PM, dummzeuch said:

but supporting Delphi 2007 is still more important to me.

Very good. 🙂

Share this post


Link to post
1 hour ago, Tommi Prami said:

That was way easier than I previously thought. Thanks!

As the page says:

Quote

Prerequisites:

  • A supported Delphi version (why would you want to compile GExperts if you don’t have one?)
  • A SubVersion client. I am using TortoiseSVN but you can basically use any client regardless if GUI or command line
  • An Internet connection
  • 15 Minutes of spare time

😉

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×