Showing 6 results.
Items per Page 50
of 1
First Previous Next Last

CVP Forum

« Back to General Discussion

Work-arounds for variable size menus

Combination View Flat View Tree View
Threads [ Previous | Next ]
Work-arounds for variable size menus
Answer
4/10/03 8:22 AM
Here is how things appear to me.
Menus have to be a specific size. If you want to add an option or remove one, you have to create a new element and copy all the settings across, one by one, then delete the old one. Then if you want to change it back, you have to do the same again. Any tips or work-arounds here?

I tried using a big menu and setting unused options to have no voice option and a DTMF option of DTMF A, B, C, D (which can't be generated on most keypads) for unused menu slots, but it wonâ¿¿t let you mix DTMF only with DTMF + voice options, so that didn't work.

Maybe the quick work-around is to copy and edit the xml directly?
Flag

RE: Work-arounds for variable size menus
Answer
4/10/03 11:57 PM as a reply to Anonymous.
Hello,

If you know that your menus will be frequently changing or you have very large menus, you may want to consider using a Form element immediately followed by a Decision. This way, the number of exit states for the input element (Form) does not change as you add/subtract menu options. Then, you can have a decision element that uses an xml rule which analyzes the result from the Form and goes to the appropriate exit state. You can add and remove exit states of a decision without deleting and rewriting the rule. You would only have to configure any new exit states added and modify the rule xml file to handle your new menu option.

Regards,

Joe
Flag

RE: Work-arounds for variable size menus
Answer
4/14/03 6:15 PM as a reply to Anonymous.
Another approach you can try (though it is a bit of a hack), is to figure out the largest number of options your menu can have and make a menu with that number of options. Then, you take each exit state and go to a decision which essentially says "is this option valid?". If it is not, you go to an Audio element which says the nomatch message and then goes back to the menu. It is sort of like handling the nomatch events yourself (what is normally done within the element).

The disadvantage of this is that it adds a lot of callflow to your application. This is why we recommend using the Form element. You don't even need to use an external grammar with the Form element, all the options can be defined within the element settings.
Flag