Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Submitted By: Thomas Gelf (thomas_gelf)
Assigned to: Nobody/Anonymous (nobody)
Summary: engage_media_proxy failes if called after create_dialog
If I correctly understood mediaproxy.c it installs a callback handler __dialog_created, responsible for setting up the other handlers for this dialog (using dlg_api.register_dlgcb).
However, if you called create_dialog() before, "dialog_created" will not be fired again if you are using engage_media_proxy().
Proposed solution: either add a note to current documentation ("...do NOT use create_dialog when using engage_media_proxy...") or find a way to catch this situation in EngageMediaProxy (maybe: if dlg started, immediately register dialog callbacks).
>Comment By: Dan (dan_pascu)
Date: 2009-03-02 11:14
Of course engage_media_proxy expects the dialog to be created later. This
is how it worked until create_dialog() was added. All engage_media_proxy
does is to set the dialog flag and some internal flag that will be used
when the dialog is created. But since the dialog was already created in
this case, the create dialog callback will do nothing since the flags are
not set at that point.
Note: my first comment was wrong. the create_dialog call does indeed
trigger the create callbacks, but they do not good since they do not see
the FL_USE_MEDIA_PROXY at that point.
But when calling the create_dialog() function, the dialog module is
automatically triggering the dialog_created callback.
Internally there is the same function tiggered by flag setting or by the
Maybe the engage_media_proxy() is expecting to have the dialog created
later and it is doing some other stuff before.
Comment By: Dan (dan_pascu)
Date: 2009-02-27 12:48
I think that the dialog module should immediately trigger the registered
callback for create dialog, if the dialog was created before that point.
This is the most obvious thing to do, as the code using the dialog module
will not have to be aware of the internal details of the dialog module and
its state, nor will it need to inspect the dialog module to figure out what
to do next.