Author Topic: Need help with Slick-C Debugger  (Read 2480 times)

outsider

  • Community Member
  • Posts: 64
  • Hero Points: 1
Need help with Slick-C Debugger
« on: July 08, 2011, 05:06:15 pm »
Hi guys,

I'm trying to debug a macro I wrote in the Slick-C debugger. Either I'm being very obtuse or the documentation is not very helpful on how to use the debugger.

Here's what I'm doing;

Start Slick-C Debugger from within my project. So far so good. Debugger session opens up. (Not sure I like this separate environment business as I now need to reconfigure everything and/or copy my files across.)

So I want to debug a macro in vusrmacs.e.
Copied file across to debug config directory and loaded it. Fine.

Set breakpoint in code - fine. Little red icon appears.

Now the embarrassing part (potentially) - how do I actually start the process going? I ran the macro from the debugger command line. The macro executes but without stopping at my breakpoint. What have I done wrong? Can't even step in etc. as all these items are greyed out in the menu.

Pointers would be much appreciated as I would really like to use this functionality rather than relying on writing debug messages all the time.

thanks guys

chrisant

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 130
Re: Need help with Slick-C Debugger
« Reply #1 on: July 08, 2011, 05:09:44 pm »
Copied file across to debug config directory and loaded it. Fine.
I think that's the problem, actually.  The debugger window is debugging macros running in the window that you launched the debugger from.  Load the macro in the original SE instance, not in the debugger instance.

outsider

  • Community Member
  • Posts: 64
  • Hero Points: 1
Re: Need help with Slick-C Debugger
« Reply #2 on: July 08, 2011, 05:48:34 pm »
Thanks Chrisant,

That put me on the right track. You actually have to start the process that needs debugging from the debuggee as well. (Who me, embarrassed?)

For future reference, for others like me;

Start debugger within your project.
Switch to debugger and open the source file you want to debug.
Set your breakpoints.
Switch back to debuggee and run your code. It should now stop execution at your first breakpoint at which stage you need to switch back to the debugger to do whatever it is you now want to do.

Thanks once again!

Graeme

  • Senior Community Member
  • Posts: 1928
  • Hero Points: 222
Re: Need help with Slick-C Debugger
« Reply #3 on: July 09, 2011, 12:05:27 am »
Quote
You actually have to start the process that needs debugging from the debuggee as well. (Who me, embarrassed?)

Well I'm glad to see you had this problem.  I asked the same thing a while ago and felt pretty stupid
http://community.slickedit.com/index.php?topic=3611.0

We must both be stupid :)
I actually never use the debugger nowadays and always use say()

Graeme

chrisant

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 130
Re: Need help with Slick-C Debugger
« Reply #4 on: July 09, 2011, 12:25:27 am »
Once the Slick-C Debugger is started, it's attached to the original SE instance.  So yes, from the moment the debugger starts it's actively debugging the original SE instance.  If you set a breakpoint on some timer proc, the breakpoint will fire as soon as the timer proc executes in the original SE instance.

I think the main reason it's confusing is because of the combination of:
1.  The original SE instance initially appears to be unaffected and separate from the debugger.
2.  The debugger is recognizably another instance of SE.

Look at it this way:

When I use Visual Studio to debug one of my programs, it's obvious which is the debuggee, and which is the debugger.

But imagine life for a developer on the actual Visual Studio team:  Fred would use VS to edit hit VS code, then launch another VS to test his changes.  And use the first VS to debug the second VS.

The same thing is happening any time we use the Slick-C debugger.  Only instead of the original instance turning into the debugger, like in the VS example, it's the second instance that takes over the debugging responsibility.

VS:
Instance #1 -- performs editing and debugging.
Instance #2 -- gets debugged.

SE:
Instance #1 -- performs editing and gets debugged.
Instance #2 -- performs debugging.
« Last Edit: July 09, 2011, 12:28:17 am by chrisant »