FYI, this doesn’t actually create the Ruby-side dialog instance (the ::new constructor method does this,) …
… the show method creates the platform C-side window object, that hosts the CEF process.
(1) I do not think it is wise to use the same identifier for the callback and a local instance method.
In the original post, you’re using "receiveCmd" as the identifier for both an action callback and an instance method called from that same callback.
Also camelcase on the Ruby-side is for modules and classes. Methods are all lower case, with words separated by underscores.
(2) Again, you are not following the instructions given above, and still do not understand basic ruby.
If the above snippet, is within a add_action_callback block, that is within the attach_callbacks method in the subclass definition (for the MyToolsDialog subclass,) … then self is implied as the receiver object, not @dlg (which is external to the subclass definition.)
SO , …
# within MyToolsDialog subclass definition ...
def attach_callbacks
add_action_callback('receiveCmd') do |not_used,id,val|
puts("Inside add_action_callback(receiveCmd, directly from MyTools_Jscript.js")
receive_command(id,val)
end
end
def receive_command(id,val)
case val
when "This"
do_this(id,val)
when "That"
do_that(id,val)
when "Close"
puts("Close was sent...")
close() # <<<<----<<<<< self is implied as the receiver object
else
# whatever ...
end
end
NO, it is not.
But if you meant within the MyToolsDialog subclass …
Then do not ever override super class methods without calling super from the subclass override method.
(Refer to the subclass override methods in my example, where I make sure to call the superclass’ method within the subclass override.)
If you wish to mark the current Ruby-side instance of the MyToolsDialog dialog object as ready for garbage collection, then …
externally (from your subclass definition) add a block to the @dlg instance’s set_on_closed callback …
@dlg = MyToolsDialog.new(options)
@dlg.set_on_closed { @dlg = nil }
@dlg.show