Hi Kelly et Al;

   FWIW: There are many instances where the IDE Debugger and/or adding various message boxes can destabilize your PB App when testing sensitive code or events. Especially, where low level API's are being used or interrupting one event can cause a bad "cascade" action in other events or not allow an event to complete before a dependent event fires.

   In the development of my STD Frameworks and related test example Apps, I have often needed to debug sensitive areas where I need to monitor the PB App EXE or where setting Debug Break point / stepping through a code segment was leading to App / IDE / both crashing. I used to demonstrate this easily when teaching PB by adding some seemingly harmless code to an OTHER event that would cause a App to crash all the time in the debugger.

  The solution I came up with (a few decades ago .. LOL) was to use the MS-Windows "Debug Queue" and the MS-Window's Debug Viewer to monitor these code segments in real time! This is now super easy on my dual monitor PC's as each can be on their own monitor. To use the Windows Debug Queue, have a look at the STD Framework's "of_write_debug" method located in the "nc_app_controller_master" object class in the STD_FC_PB_Base.pbl library.

  For the App to view the PB App's debug queue, have a look at the Microsoft SYSInternal's Debug Viewer ...

http://docs.microsoft.com/en-us/sysinternals/downloads/debugview

  For a look at the STD Framework code, you can download it from here and check out the latest features ....

http://chrispollach.blogspot.com/2021/01/2020r2.html

HTH
Regards ... Chris

Hi Kelly,

do you have anything on "Watch" while debugging? In my experience, most random debugger crashes are caused by having complex objects in the watch tab that go out of scope. If so, try clearing them all and retry the debug run.

1. Replace the code in the box as follows and RUN it.
If that works then try DEBUG.

MessageBox ("prior to check #1...")
IF (IsNull (awo_control)) THEN
   MessageBox ("awo_control is NULL", "")
ELSE
   MessageBox ("awo_control is NOT NULL", "")
END IF

MessageBox ("prior to check #2...")
IF (IsNull (as_method)) THEN
   MessageBox ("as_method is NULL", "")
ELSE
   MessageBox ("as_method is NOT NULL", "")
END IF

MessageBox ("prior to check #3...")
IF (NOT( IsValid (awo_control)   )) THEN
   MessageBox ("awo_control is NOT valid", "")
ELSE
   MessageBox ("awo_control IS valid", "")
END IF

MessageBox ("after check #3...")

Good Luck,

Olan

Just a tip:

If your application is crashing while debugging, to avoid having to put your debug stops back in every time. Do this.

- Place your debug stops

- Close powerbuilder (now your stops have been saved)

- Open powerbuilder again and debug. At least the stops will be preserved.

regards

I am having similar problem using Powerbuilder 2017 R3. The code keeps crashing out at certain points when I do a debug run of it. But if I just run it there is no error.

I have done a full build of the code but still the issue persists. Could anyone please suggest what could be done to get around this.

I need to do the debug to understand the flow so I just cant skip these points.

Thanks in advance for any suggestions.

Like Chris said: you seem to be using pfc's. Exactly "where" are you calling these "of_register()" functions?

Hi,

Break up your check on isvalid() isnull() in more than one statement like this:

if not isvalid(awo_control) then

   return -1

end if

if isnull(awo_control) then

  return -1

end if

if isnull(as_method) then

  return -1

end if

That way, at least you can find out on which of the checks it's blowing up. The reason why I'm telling you, is that I don't think you can do a "isnull()" on an object that not "IsValid()".

Since you have both in a single if-statement, that might cause a problem.

Also, powerbuilder behaves a bit bunny when comparing null values in an if statement: If anything in the "if" evaluates to "null", pb will always execute the "else" statement (if that's present).

In addition to what you've said about "I have to restart and insert my breakpoints again. ... ".

This is "normal" in PB:

- if you set a breakpoint and the app blows up. that breakpoint is not saved.

- to make sure your breakpoint is at least there every time you run debug, just once: set the breakpoint, run you application and immediately exit your application (without having tested the "blow-up-part").

- now your breakpoint would have been saved and will still be there when you test the "blow-up-part".

regards,

MiguelL

Hi Kelly;

I see that your application is using the PFC framework. When you migrated from PB 8.x, did you replace the PB 8 PFC libraries with the newer PFC's that match PB2019 or just migrate the old PFC's forward "as is"?

Regards ... Chris

Hi, Kelly -

I suggest making a backup copy of all PBL's, including the PFC libraries, then performing a full build so that all objects are regenerated. Once you have a clean build, exit the PB IDE and restart it, then try setting the Debug Break point and Debug. This has helped me in similar situations in the past.

Although not related to your question, I'm simply curious why you are setting a break point and debugging the PFC's Resize service (it appears to be object pfc_n_cst_resize?) to track a query. ???

Also, are you using the most recent version of the PFC libraries (they were released for PB 2017, I believe)? If not, what version of the PFC are you using? What Release/Build of PB 2019 are you using?

Regards, John