Subdialogs and blocks

[agfa]

Perhaps you could help explain something to me since I am very confused.

I have a form which calls two sub-dialogs, one after the other. Both the sub-dialogs have conditions. After each sub-dialog there is a block with some statements and some log lines.
The form concludes by going back to itself, (there are of course, escape routes but I am simply documenting the problem I have).

E.g.
<form id="dictate_mode">
<subdialog name="help" cond="m_userInput == C_HELP_DICTATE" src="help_report.vxml">
<filled>
<!-- The user has decided what to do.. -->
<assign name="m_userInput" expr="help.answer"/>
<log label="Dictate_Mode">Help Input: <value expr="m_userInput"/></log>
</filled>
</subdialog>

<block>
... stuff here...
<log label="Dictate_Mode">I am in the middle block: <value expr="m_userInput"/></log>
</block>

<subdialog name="confirm" cond="m_userInput == C_SAVE_REPORT" src="confirm_report.vxml">
<filled>
... stuff here...
<assign name="m_userInput" expr="C_HELP_DICTATE"/>
</if>
</filled>
</subdialog>

<!-- Have not decided to save yet, go around again.. -->
<block>
... stuff here...
<clear/>
<log label="Dictate_Mode">Go around again: <value expr="m_userInput"/></log>
<goto next="#dictate_mode"/>
</block>
</form>

I have noticed that sometimes, the code in the <block> statements does not execute at all, it is simply bypassed completely. For example, after the second sub-dialog has finished I should clear my form variables and log a line. In the Plum call log I see this:

dtmf input: *
Found grammar match
hypothesis #0: * (1.0000)
VXI::assign_element(name="answer" expr = "confirm"
VXI::assign_element(name="m_userInput" expr = "C_HELP_DICTATE"
VXI::queue_prompts()
DocumentParser::FetchDocument(help_report.vxml)

Notice how Plum is running the "Fetch document help_report.vxml" before it has even reached the end of my form. I should see a log line in there. The disadvantage of this is that I am seeing some very strange behaviour; it's as if the <clear/> isn't being run. Sometimes, the middle block does not execute. I cannot understand why this should be.

[agfa]

I 'think' I have found a Plum problem.

I have created two basic test vxml forms that I would like to send if that is possible; if not let me explain what I think is a bug in Plum.

Create a vxml form that contains two subdialogs (both with conditions) followed by a block, followed by another subdialog. At the end of the form create a last block that simply contains a <clear/> and a goto #formname statement. (I realise this is inifinite loop, but it's just a test). The subdialogs can point to some very basic external file that returns the entered value. Make sure there are log lines at every stage.

E.g.
<form>
<subdialog cond src>
<subdialog cond src>
<block>
<subdialog cond src>
<block> (contains clear)
<form>

If you run this form, the first time around everything runs correctly. After the first loop however, the first <block>is completely ignored.
Could someone in the support team perhaps have a look at this for me?

Regards
Justin

[support]

Hi,

Two things that might work better when writing your IVR code:

- use the 'name' attribute to create names for your blocks, e.g.:
<block name="block1">

- use a namelist attribute within your <clear> tag to explicitly clear the subdialogs and the blocks you named above:
<clear namelist="block1 block2 block3 ..." />


Regards,
Plum Support

[agfa]

Thanks for the reply.

Unfortunately, the suggestions don't seem to work.
Sometimes the blocks do not execute at all, (which includes the clear with a namelist). Also, some of my subdialogs are not entered, (perhaps because the conditions are not clear).

I can repeat the problem easily now, and I have to say, it seems somewhat related to using the '#' key as part of the grammar. E.g. Press 1 to ...
Press * to ...
Press # to ...

If I press other keys, the blocks execute better.
I figure I'll and try and write my vxml in a different way.