1. Haakon Langballe
  2. PowerBuilder
  3. Wednesday, 20 November 2019 10:32 AM UTC

Hi!

Our application crashes when CloseWithReturn is called in the window open() event handler. The error occurs when returning early from the Open() handler when incorrect parameters are passed.

My code:

...

integer retval = CloseWithReturn(this, 0)

---

retval is -1, indicating some error.  The window is not closed so the code execution continues. Apparently the window object is destroyed(partly?) and inevitably the application crashes. I suspect maybe other messages are trying to reach the Open() event for handling but haven't found out how to solve that eventuality

 

- Is it legal (or recommended) to do CloseWithReturn() in Open()

- What would be a better graceful termination of the window in an error situation? 

 

Cheers

Haakon

Accepted Answer
Michael Kramer Accepted Answer Pending Moderation
  1. Wednesday, 20 November 2019 11:10 AM UTC
  2. PowerBuilder
  3. # Permalink

Open event is part of opening sequence that you short circuit by Close/CloseWithReturn.

For safe coding you need to let window complete its opening before you close it.

Example (Open event of some response window)

if this.of_NoGoodToOpen( ) then
   this.Visible = false
   post CloseWithReturn("Ouch!")
end if

Note that code makes sure window never becomes visible but allows Open-process to complete gracefully before closing the window. 

SIDEBAR

It is good practice to check whether opening window is relevant/authorized before trying to open that window. 

HTH /Michael 

Comment
There are no comments made yet.
Haakon Langballe Accepted Answer Pending Moderation
  1. Wednesday, 20 November 2019 12:00 PM UTC
  2. PowerBuilder
  3. # 1

Hi Michael.

Post is working fine.

I totally agree that checking the parameters before opening the window is better, I will refactor the code.

 

Thanks

Haakon

Comment
  1. Michael Kramer
  2. Wednesday, 20 November 2019 12:18 PM UTC
I know that can be really hard when script are looong and code is decades old and refactoring suddenly takes a life of its own. First fix. Then refactor. Refactor amount has limits I understand but I prefer leaving the "campground" cleaner than I found it. Usually gets me finish on or before time more often.
  1. Helpful
There are no comments made yet.
Haakon Langballe Accepted Answer Pending Moderation
  1. Wednesday, 20 November 2019 12:33 PM UTC
  2. PowerBuilder
  3. # 2

Don't fix it if it ain't broken ... 

Refactor what needs fixing is maybe the way to go about it.

 

Comment
  1. Michael Kramer
  2. Wednesday, 20 November 2019 13:45 PM UTC
Yup!

When I approach "paleo programming" (edit code 5000+ days old) I always follow this sequence:

1) Identify code that requires changes

2) Fence in that code fragment (aka. refactor) for dual purposes: -- (a) Reduce this code fix's impact on surrounding code -- and (b) Reduce impact on this code fix from future changes in surrounding code.

3) Develop code fix.

Not too long ago I worked on code where a comment noted "Fix issue introduced by PB 3"
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.