​LOST DEBUGGER ON EDIT ERROR timeout trigger.

[alogrep 0]

II I have table1.Edit and it stays there indefinitely on one PC, when I do the same (on exactly the same record on another PC, it does not give me any error: it just goes on and I can even POST it.

This happens in the last few hours. Until then It worked fine.

I was trying to see why in the oneditError, although I had Action= dsAbort it still showed a message, although the documentation says and it would not.

In that message window there was a checkbox "Ignore this error in the future" (or something to that effect) that I marked, 

Since then the lock timeout error does not get triggered.

Any help rom anybody, please?

[Olli73 0]

5 hours ago, alogrep said:

II I have table1.Edit and it stays there indefinitely on one PC, when I do the same (on exactly the same record on another PC, it does not give me any error: it just goes on and I can even POST it.

This happens in the last few hours. Until then It worked fine.

I was trying to see why in the oneditError, although I had Action= dsAbort it still showed a message, although the documentation says and it would not.

In that message window there was a checkbox "Ignore this error in the future" (or something to that effect) that I marked, 

Since then the lock timeout error does not get triggered.

Any help rom anybody, please?

 

Which database and components? What are the settings for lockmode, isolation level and so on?

 

In debugger there are shown exceptions by default always. The user (no debugging) will not see it.

 

I think we need more details.

 

 

[PeterBelow 234]

8 hours ago, alogrep said:

II I have table1.Edit and it stays there indefinitely on one PC, when I do the same (on exactly the same record on another PC, it does not give me any error: it just goes on and I can even POST it.

This happens in the last few hours. Until then It worked fine.

I was trying to see why in the oneditError, although I had Action= dsAbort it still showed a message, although the documentation says and it would not.

In that message window there was a checkbox "Ignore this error in the future" (or something to that effect) that I marked, 

Since then the lock timeout error does not get triggered.

Any help rom anybody, please?

The debugger will show exceptions before they are trapped in try except blocks in the code. The dialog you got allows you to tell it to not show this particular exception type in the future. To re-enable it you have to go into the IDE options dialog (Tools -> Options). Under the "Debugger" node you find (under "Embarcadero Debuggers") two lists with the exception classes to ignore. Just uncheck the one you blocked. Note that the dialog may look a little different if you use a Delphi version older than 12.

Edited Sunday at 11:26 AM by PeterBelow

[alogrep 0]

Thanks Peter. 

I find it strange that a question answered at runtime makes a persistent change in the IDE options.

 Anyway I went further and found out the method of setting those options on the breakpoints-> Advanced.

To me it sounds obvious that the debugger intercept the exception before the try/except block. It does not seem so obvious to me that there is ONLY an option to ignore the exception (then it does not even trigger the OnEditError, for example). I would have expected a sub-option: catch it but do not show notification to the end-user. ..

[Lajos Juhász 287]

9 hours ago, alogrep said:

It does not seem so obvious to me that there is ONLY an option to ignore the exception (then it does not even trigger the OnEditError, for example). I would have expected a sub-option: catch it but do not show notification to the end-user. ..

 

This option is exactly do not show the error in the IDE. The exception is going to work as expected only you do not get the dialog while debugging.

[Brandon Staggs 243]

22 hours ago, alogrep said:

I find it strange that a question answered at runtime makes a persistent change in the IDE options.

It only happens if you are running it in the debugger. In such a case, the IDE is very much active and being interacted with; it is not like the program you are running reaches into the IDE and changes something: the IDE is offering to change a setting easily in first-chance exception handling. And this particular feature makes perfect sense and is very much appreciated by me.

[Brandon Staggs 243]

22 hours ago, alogrep said:

I find it strange that a question answered at runtime makes a persistent change in the IDE options.

It only happens if you are running it in the debugger. In such a case, the IDE is very much active and being interacted with; it is not like the program you are running reaches into the IDE and changes something: the IDE is offering to change a setting easily in first-chance exception handling. And this particular feature makes perfect sense and is very much appreciated by me.

 

22 hours ago, alogrep said:

To me it sounds obvious that the debugger intercept the exception before the try/except block. It does not seem so obvious to me that there is ONLY an option to ignore the exception (then it does not even trigger the OnEditError, for example). I would have expected a sub-option: catch it but do not show notification to the end-user.

I'm sorry but so much of this just doesn't make sense. The option in the IDE does nothing except prevent the IDE from giving you a first-chance interruption during debugging. It doesn't change how your program handles the exception.