It isn't that I wanted that "puts" to run immediately after the dialog is up. I put it after the show_modal to determine whether I reach that statement after the dialog is up or if I reach that statement after the dialog closes. I believe that I determined that I reached there only after the dialog closes. Therefore, an error raised in my callbacks should be caught by my rescue and it is not.

I am currently working on a solution, suggested by you, to "Try putting another begin... rescue inside the callback block itself..." that is likely to solve my problem. I just wanted to understand why this didn't work and I haven't reached this understanding yet.

Edit - that worked fine. My real problem is simply solved. I still don't understand why the original didn't work, but not worth any more of my time or your time. Thanks.

TIG said:
@unknownuser said:

The 'rescue' only kicks in if you have an error.
So you don't have an error ??
The code exits cleanly after the dialog opens...

The statement that appears right after the "show_modal":

puts "dialog is up#{Time.now.inspect}"

has not been executed when the error raise occurs. Suspecting that, as you said, "The code exits cleanly after the dialog opens..." is the reason that I displayed the time in that puts statements at the beginning and end of the main code block. If I wait a full minute before clicking the button that causes the callback where my error raise is placed, then the time between the puts on entry and the puts after the show_modal is around a minute. If execution indeed continued immediately after the dialog is displayed, this time difference should be very short. After the error is raised, I can only get the dialog down by clicking on the "X" button of the window. At that time is when I see the puts after the show_modal displayed.

I would like to have shown the output from the ruby console, but it doesn't let me copy that text. Is there some way to do that if it proves necessary?

I am new to this forum, and I thought I had already done this reply. If it shows up twice - sorry.

TIG said:
@unknownuser said:

Something like:

rescue => error
>   warn error.inspect
>   warn error.backtrace.join("\n")
> 
> 

To see what's up...
I did try this, but as I expected, since it never reaches the rescue, nothing displayed. I should have explicitly stated in my original post that "dialog" is an instance of a class inherited from WebDialog and I should have mentioned that I am on Windows.

@unknownuser said:

Something like:

rescue => error
>   warn error.inspect
>   warn error.backtrace.join("\n")
> 

To see what's up...

I tried it, but as I expected, it still didn't reach the rescue, so nothing was displayed.

On purpose, for testing, I raised a RuntimeError inside one of my callback codes. I never reached the rescue clause. I thought maybe that the call to show_modal is asynchronous, and therefore leaving the begin block before the raise occurred. The times I printed disproved this theory, so I am lost now. Can someone explain why I never reached the resume. BTW, I also did a puts in the ensure block and it didn't reach there either.

def let_user_edit(&success_proc)

	begin
		puts "Enter let_user_edit #{Time.now.inspect}"
		op_name = "Edit #{pretty_name} Commands"
		am = Sketchup.active_model
		am.start_operation(op_name, true)
		dialog = ListEditor.getTheDialog
		dialog.add_action_callback( "callback" ) { |dlg, msg| self.callback_dispatch(dlg,msg) }
		dialog.set_on_close { dialog.closing(&success_proc) }
		dialog.show_modal
		puts "dialog is up#{Time.now.inspect}"
	rescue 
		puts "In rescue"
		self.cancel(dialog)
		puts "Reraising"
		raise
	else
		# Do code here ONLY if NO errors occur.
	ensure
		# ALWAYS do code here errors or not.
	end
end # let_user_edit