Returning a procedure after open window

questions
1

Hi there…

inside a procedure I am opening a window and doing a return before the accept-loop starts or doing a return inside the accept-loop crashes the program.
If I doing Post(EVENT:CloseWindow) instead everything is fine…this behaviour isn’t documented, is it?

EDIT: I am using Clarion 10 with legacy templates and it is a MDI program

exemplary code:

f1 procedure()
window 	window...
		...
		end

 code

 open(window)

 ! first case
 do doReturn

 accept
  !second case
  case field()
  of somefield
    case event()
	of event:accepted
	  do doReturn
	end
  end
 end

 do doReturn

doReturn routine
 ! closing window if opened...
 return
2

I’m guessing that behavior is a red herring to some other problem.

3

What other problem do you think?
Inside Clarion or inside my program?

4

After re-looking, I don’t recall that I’ve closed a WINDOW inside the ACCEPT loop before. Perhaps trying a BREAK there instead of directly calling your ROUTINE would be easy enough to test, but I usually use POST(Event:CloseWindow) inside the ACCEPT loop.

Keeping in mind that this is just example code, the code before the ACCEPT loop looks like it should not crash.

Have you checked if there exists some kind of mandatory cleanup code inside EVENT:CloseWindow?

What are the error messages?

5

Yes, an Accept loop is not an ordinary loop. However, if you want to leave the window open for another procedure or to hijack an existing accept loop temporarily, then you can use a BREAK to get out.

HTH :sunglasses:

1 Like
6

Yep, I know it isn’t an ordinary loop.
But I’ve expected that closing the window and doing a return cancels immediatly the message loop.
Normally I do POST(EVENT:CloseWindow) but one time I did a ProcedureReturn instead.

7

@jslarve
The error is “just” an access violation.
Yes, there is some code at CloseWindow, but no access to fields on the window just some checks on some variables.

8

There is code in the runtime library for exiting the Accept loop. Calling Return within the Accept loop can GPF, calling Break works ok. I am using Break in a “wait” procedure that momentarily hijacks the current window, delays for a timeout, and then returns control to the current window (without closing the window).

It would be nice if Return did an automatic Break, but like some other languages it does not. By the way, the Post(Event:CloseWindow) does not close the window, it just asks for the window to be closed later. That makes a difference here.