Virtual Breakpoint

[abarchman]

What would cause execution of a program to pause in the IDE as if there were a breakpoint set.  I am using the laz graphics unit in a port from delphi.  Here is the code part from "custombitmap.inc":

function TCustomBitmap.GetMaskHandle: HBITMAP;
begin
  MaskHandleNeeded;
  Result := FMaskHandle;
end;

When executing the code, execution stopped on the "Mask..." line.   So I commented it out.  Now it stops on the next line.  Then uncommented, it still stops on the "Result:=" line (same next line).  Now when it does stop, one can resume execution by pressing F9, or by using single stepping.  Yet there is NO breakpoint set in this function.  Is it possible that there is a BP set elsewhere and the system is being fooled?

The actual user source is stored on a SD card, with laz & FPC on the main SSD drive as well as all the "built-in" units.

To me this is strange behavior and I cannot explain it.

[taazz]

2 things mainly
1) break points that are not shown but active open view\debug windows\BreakPoints(Ctrl+Alt+B) and remove all breakpoints there.
2) there is an int(3) call somewhere in the chain of execution that force the debugger to stop in the specified spot(less likely).

[Thaddy]

2) there is an int(3) call somewhere in the chain of execution that force the debugger to stop in the specified spot(less likely).

That is Intel only.

[abarchman]

Thank you for pointing out the breakpoint screen.  It was an active BP that was not shown.  Now it gives the error message of:

TCustomImageList.AddImages not implemented yet for other Width/Height.

Press OK to ignore and risk data corruption.
Press Cancel to kill the program.

Probably because being a delphi import referencing one if those unfinished properties.

[taazz]

Thank you for pointing out the breakpoint screen.  It was an active BP that was not shown.  Now it gives the error message of:

TCustomImageList.AddImages not implemented yet for other Width/Height.

Press OK to ignore and risk data corruption.
Press Cancel to kill the program.

Probably because being a delphi import referencing one if those unfinished properties.

that looks like a runtime error not a compile time one, which makes it easy to pin point, just find the raise exception call in the specified method to see what goes wrong or attach a sample application that shows the problem for us to take a look.

[abarchman]

Yes it is a runtime error generated by a raise statement.  The original program (written by me in Delphi6) was originally using a component called DLBitmap, but seemed to lack some properties, thus I thought it might be easier to use the laz form of bitmap fixing any problem with properties.  The breakpoint was not allowing me to get to the real problems.  I will ask further questions if I get stuck again.