xsharp.eu • Despite DebuggerHidden/DebuggerStepThrough debug still stops there
Page 1 of 1

Despite DebuggerHidden/DebuggerStepThrough debug still stops there

Posted: Wed Mar 15, 2023 1:19 pm
by ic2
Following this subject: https://www.xsharp.eu/forum/public-prod ... ough#23218

I added the following:

Code: Select all

[System.Diagnostics.DebuggerHidden()];
Function ReturnVar (etc)
(I also tried [DebuggerStepThrough]; instead)

Nevertheless, when I debug in VS, using Step, the debugger lands in the following line, about halfway the code in that function:

Code: Select all

	nRes := AScan(aLocalSysVars, {|aVal| Upper(aVal[1]) == cSearch})
I have to pres F11 many times (really no idea what it is doing) before I finally return to where I wanted to go directly in the first place. In fact, I am worse off without that Debugger statement because then I can use Step Out and here it doesn't work.

I have added #using System.Diagnostics on the top of the program where the function can be found.

What could be the cause?

Dick

Despite DebuggerHidden/DebuggerStepThrough debug still stops there

Posted: Wed Mar 15, 2023 1:26 pm
by robert
Dick,
I am not 100% sure, but I suspect that the following is happening:
- the codeblock code gets converted to a compiler generated class
- the body of the block becomes the body of the EvalBlock() method of that class
- we did not add the attributes from the function where the block was declared to that method

I will see if we can "teach" the compiler to apply these attributes to the compile time codeblocks that are declared inside a method too.

Robert

Despite DebuggerHidden/DebuggerStepThrough debug still stops there

Posted: Thu Mar 16, 2023 9:37 am
by ic2
Hello Robert,

Thanks. It seems I once again added something to the endless X# ToDO list.

I have removed the DebuggerHidden statement.

Once again I must conclude that CA had a great design wit h the entity based VO repository where any debug setting (entity but also MEF, AEF) is arranged in seconds and also works. I guess it was also easier for the developers to get it working than for you in VS.

Dick

Despite DebuggerHidden/DebuggerStepThrough debug still stops there

Posted: Thu Jun 29, 2023 10:59 pm
by ic2
I noticed that System.Diagnostics.DebuggerHidden still isn't working in 2.16. Even step out won't work.

Debugging X# programs takes literally many tomes more time than debugging VO programs.

Any idea if this issue will be fixed?

Dick

Despite DebuggerHidden/DebuggerStepThrough debug still stops there

Posted: Fri Jun 30, 2023 5:47 am
by robert
Dick,
DebuggerHidden works. What you asked for is that we would also apply that to body of codeblocks defined in a method with that attribute. And that is still on our todo list.

But short after you asked for this new feature, you decided not to renew your subscription.
Now I am asking you: what kind of signal do you think that gives?
Do you really expect that your issues get a higher priotity by stopping your subscription?

Robert

Despite DebuggerHidden/DebuggerStepThrough debug still stops there

Posted: Fri Jun 30, 2023 9:56 am
by ic2
Robert,
robert post=26751 userid=253 wrote:Dick,
DebuggerHidden works. What you asked for is that we would also apply that to body of codeblocks defined in a method with that attribute. And that is still on our todo list.

But short after you asked for this new feature, you decided not to renew your subscription.
Now I am asking you: what kind of signal do you think that gives?
Do you really expect that your issues get a higher priotity by stopping your subscription?
I won't call this a 'new feature' but rather a bug fix. When there is a codeblock in a method or function, you can't skip the whole method during debugging. I don't need to debug the code block, I just want skipping a method with DebuggerHidden above it to work all the time. In VO, skipping an entity during debugging was set in seconds and always worked.

You have chosen to offer a free version of X# and a subscription model to finance this which, I assume, only a minority of the users have taken. I completely understand that you give priority to your Fox members requests. In the meantime, non Fox members will post issues too and it's up to you to fix them or not. I guess Fox members want roughly the same features and bug fixes as non Fox members.

Finally I would like to remind you again that public forums are not the best way to discuss your (business) concerns. You know my e-mail address after all and if you want to be reminded of the reason why I didn't renew our Fox subscriptions or even to convince to reconsider that, a mail or phone call works a lot better than e.g. asking here in this forum which signals I am giving.

Dick