.
I’m using Delphi 11.2. In a simple test project it works. I have tried stepping into the code with no joy it refuses to jump to the code in System.SysUtils for the Abort command. Am using the BeforeAction event In TDBNavigator for the process. It now has two lines of code;
MessageDlgPos(‘About to abort’, mtInformation, [mbOk], 0, X,Y);
Abort;
When running the code, on pressing F7 when on the Abort line, after about a second the above dialog appears and the IDE moves CPU tab. I can continue to run but sometimes it loops on failure messages. If it continues by pressing Run the abort command is ignored as well as the TDBGrid row is deleted or added if I’m using the delete or add key.
In a separate simple test project it works as expected.
I have had the situation where code I have recently written into my app
is not executed.
The way I got around it was to delete all dcus created by the compiler
and rebuild (not recompile).
Does it still happen without the abort command? I haven’t actually seen that used before but others seem to get that error with Delphi and claim its a debugger bug with exception handling which kind of seems like what abort kind of does.
The abort command is often used by developers in this kind of scenario to prevent the regular actions of the DBNavigator or datasource from taking place.
WRG to the fault, I suspect you have some controls linked to your datasource or another datasource linked to it, and the abort is causing an issue there.
If you do delete all your DCUs and rebuild (not compile) do you still get the same behavior? If so, remove all the code from the “beforeaction” event and instead use:
try
OutputDebugString('working');
except
on E: Exception do
OutputDebugString(PChar('Error: "' + E.Message +'"'));
// there are other ways of doing this but this will work in all Delphi versions
end;
Now in the console you should see the error message. You can also use DebugView to see the messages if you’re not running the app within the debugger/IDE
The reason for using OutputDebugString is to avoid problems like control repaints and other visual behavior interfering with the error and generating spurious/looping error messages. It will emit to the console without needing to do any message handling unlike MessageDlgPos which could introduce errors unrelated to the database events.
No but I then can’t stop TDBNavigator from doing a delete or other actions availble in the object. The abort option is particularly important to be able to abort removal of a row in the TDBGrid
Well, after having a long weekend break, the code is working without issue. I haven’t changed anything, all I can think is the PC needed a shutdown reboot rather than a restart. Need to ensure I go that extra step
