The "hell" of the OEA Debugger ...

Posted by Stefan Marquardt on 04-Apr-2011 04:20

Hello,

actually i can say: (10.2B04), the debugger is not safe! (10.2B03 wasn't better)

It's changing the behaviour of the code like "killing" buffers from one statement to another and shows wrong values!

I attached one screenshot whery everbody can see that this is really wrong.
(look at both fields of ttReceiptRowItem)

My OS: Win7 Enterprise 32bit

Stefan

Debugger.PNG

All Replies

Posted by Peter Judge on 04-Apr-2011 07:30

marquardt wrote:

Hello,

actually i can say: (10.2B04), the debugger is not safe! (10.2B03 wasn't better)

It's changing the behaviour of the code like "killing" buffers from one statement to another and shows wrong values!

I attached one screenshot whery everbody can see that this is really wrong.
(look at both fields of ttReceiptRowItem)

My OS: Win7 Enterprise 32bit

Stefan


Stefan,

Have you logged this issue with tech support yet?

-- peter

Posted by Stefan Marquardt on 04-Apr-2011 08:13

Peter,

yes - i did, W104010072 (i attached many outputs from Win7 psr)

This is again the same problem we have every time: The debugger is changing the code behaviour.

Stefan

Posted by Stefan Marquardt on 15-Apr-2011 08:29

Peter,

have a look to the attached screenshot.

Meanwhile i think that the debugger makes 100% nonsense.

define buffer bttReceiptRow for ttReceiptRow.

define buffer bttReceiptRowItem for ttReceiptRowItem.

define buffer bttReceiptRowFormulaValue for ttReceiptRowFormulaValue.

find last bttReceiptRow no-error.

if not available bttReceiptRow then

   return 0.

if bttReceiptRow.Type <> ReceiptRowTypeEnum:item then

    return 0.

/* Artikeldatensatz */

find bttReceiptRowItem of bttReceiptRow.    /* HERE IS THE BREAKPOINT */

The variables tab shows for bttReceiptRow: ** Unavailable **.

But there is a check with "not avaible bttReceiptRow".

And if i run 100% the same, set the debugger breakpoint to "find last bttReceiptRow" and run single step, the code works like there is really no

bttReceiptRow avail.

So the behaviour of the OOABL Code isnt't safe with attached debugger.

BTW:

If i put this before my breakpoint:

message

available bttReceiptRow

view-as alert-box.

I become "yes" !

Any comments? Nobody is wondering about?

Stefan

Posted by Stefan Marquardt on 19-Apr-2011 07:04

Today i noticed that:

During single step debugging i may not hold the mouse pointer over a table.field text in the code to show the actual value. (ballon)

If i do this the buffer, which was avail, is list and not avail for the folowing code.

The debugger is killing buffers!

This seems not to be happen if i disable "Enable property evaluation".

Enables the evaluation of properties with accessors.

When you disable this preference, the actual value does not appear for the property in the Variables view. Instead, the message "**Property evaluation disabled**" appears.

This preference is disabled by default.

Sorry, my fault? I enable this feature.

Posted by egarcia on 19-Apr-2011 08:17

The "Enable Property Evaluation" option in OpenEdge Architect is related to the -noevalprops parameter that can be specified to the command line of the OpenEdge client.

This is option is disabled by default in Architect because you could see a side effect caused by the execution of the code or by accessing variables before the constructor of the class has been run.

If you are seeing the issue when enabling the evaluation of properties, there must be an accessor that has code which causes the side effect.

You could try to find out what is the accessor that is causing the side effect. Once that you see what the code is doing, it may be clear why the buffer is no longer available.

If it does not make sense, you could report the issue to Customer Support.

An alternative to enabling the property evaluation, is to use "Evaluate Property"  (also available from "Variable Details...").

Also, you could add the property to the Expressions view.

I hope this helps.

This thread is closed