How is the OEA Debugger in 11?

What were you missing, in particular, or need to do?

-- peter

The debugger that came with 10.2B is very prone to crashing to the point that it is not usable. There was the thread a while back, and it looks like no one is using the OEA debugger because of it. I'm just wondering if the debugger in 11 in more stable?

Basically, I never even had the chance to see what the debugger offers and doesn't offer.

looks like no one is using the OEA debugger because of it.

That is a bold claim. It has it's fails. But I know many people using it.

Hello,

I believe that you are referring to thread:  http://communities.progress.com/pcom/thread/32733 where there is a  reference to a specific issue OE00198337.

Issue  OE00198337 refers to a crash in the Architect Debugger that was seen  when debugging programs using a REFERENCE-ONLY ProDataSet.

You should have been able to debug other programs just fine.

I checked and found that this issue was fixed in 10.2B06 and 11.0 as issue OE00211449.

I hope this helps.

That's the thread.

The PRODATASET is just one of the problems. My experience was more like the one from Stefan's post.

pjudge schrieb:
What were you missing, in particular, or need to do?
-- peter

I am missing (10.2B) that pressing STOP stops the application but this is not really working.

So i had to write an external tool that is searching for the correct prowin process to kill it.

Peter,

perhaps you can write a few comments to my old things?

- the applications is running different within debugger as without (often GUI problems)

- stopping on any errors seems not to work (no answer from PSC)

- single step debugging ends itself without cause (perhaps this is your noticed bug), most times withing catch blocks

- two debuggers (i like to have one debugger working fine)

- stopping at the beginning of the application by itself - in MS Studio debugger is attached by default without noticable difference.

- how to debug ABL (.NET) application with using external DLL? (within Debugger from MS Studio i can break within the DLL)

Is there something new?

BTW: I am using the debugger, better than nothing.

I did not have many problems using it on UNIX and with AppServer. It's improved.

It still has some bugs in following an process from windows clinet through broker and agent on UNIX automatically.

I did not use it with .net.

marquardt wrote:
Peter,
perhaps you can write a few comments to my old things?
- the applications is running different within debugger as without (often GUI problems)
- stopping on any errors seems not to work (no answer from PSC)
- single step debugging ends itself without cause (perhaps this is your noticed bug), most times withing catch blocks
- two debuggers (i like to have one debugger working fine)
- stopping at the beginning of the application by itself - in MS Studio debugger is attached by default without noticable difference.
- how to debug ABL (.NET) application with using external DLL? (within Debugger from MS Studio i can break within the DLL)
Is there something new?
BTW: I am using the debugger, better than nothing.

In general, if you've logged bugs for the issues, it makes it easier to get visibility into what's happening with the issues.

- two debuggers (i like to have one debugger working fine)

This is a consequence of the fact that the standalone debugger came first. It's my understanding that the standalone and Eclipse debuggers share the same 'engine' and that the UIs differ. I suspect (but don't know) that any new features in the debug engine would only be exposed in the Eclipse debug perspective.

- stopping at the beginning of the application by itself - in MS Studio debugger is attached by default without noticable difference.

This is the new default behaviour in OE11. Some like it, some not.

- stopping on any errors seems not to work (no answer from PSC)

This has worked for me in 11.0. It sounds like you've already reported this.

- how to debug ABL (.NET) application with using external DLL? (within Debugger from MS Studio i can break within the DLL)

I've not heard of this request before; (you know what I'm going to say ) report it to TS.

--  peter

What would be really nice is to have the execution terminate on error and at the line of code that failed while keeping the current context of the application (variable values and etc.).