Zugg Software :: View topic

Posted: Thu Aug 14, 2008 1:25 am

The following code behaves strangely:

Posted: Thu Aug 14, 2008 4:11 am

Definitely something weird going there...

However nothing in the documentation indications you can use multiple commands after the colon in the YESNO, and the examples actually seem to suggest that only one should be used. Having colons ':' in the command line probably isn't helping either. Putting the commands in an alias allows them to execute as expected.

Posted: Thu Aug 14, 2008 4:22 am

I see your point. However the command syntax is this:

Syntax: #YE question {commands} {commands}

So I assumed that one could put multiple commands in the stream.

I will do as you suggest and maybe Zugg will explain further.

EDIT: Your suggestion works great, thanks.

Adept Joined: 27 May 2008 Posts: 299

I would also like confirmation on using multiple commands in #YESNO. Some of my scripts do this and it 'seems' to work but occasionally I have issues with it.

Posted: Thu Aug 14, 2008 4:30 pm

Well, I did find a problem here. There isn't supposed to be any restriction on multiple commands...that wasn't the problem.

The problem was with the %setglobal function call. Remember that strings and variables are expanded within {}? Well, CMUD has two modes for parsing. In one mode, CMUD expands functions and variables as it parses a string and creates the compiled code for it. In your example above, put the code into an alias and then click on the Compiled Code tab for the alias and you will see it adding the function reference for %setglobal.

But this isn't the behavior that you want for #YESNO. You don't want CMUD to expand the variables and functions in all of the #YESNO arguments when the command is first parsed. You only want it to expand the section that gets executed based upon the button clicked by the user. In the CMUD parser, this is called "delayed" expansion. This is the kind of parsing used for commands like #IF, #CASE, #SWITCH, etc, where you don't know which argument to expand until runtime.

I found two commands that didn't have the "delayed expansion" set for them: #YESNO, #PICK. I have fixed both of these commands so that they don't expand their arguments until they are actually selected for execution. This should fix the problem, and I hope it doesn't have any side-effects.

Enchanter Joined: 09 Sep 2007 Posts: 605

Anaristos:

Btw, the "color" mxp tag works well with all #SAY, #PRINT, #ECHO, #SUB and like commands, not only with #MXP

Enchanter Joined: 09 Sep 2007 Posts: 605

Posted: Thu Aug 14, 2008 7:26 pm

Immediate expansion of functions means that the %setglobal function was being executed when the #YESNO command was parsed, even before the dialog was displayed. Normally this wasn't a problem because most functions just return a value and don't have any side effect. But with %setglobal, just executing the function has the side effect of setting your global variable in your INI file. The same problem would occur with any other function that had a side-effect of setting a value in addition to returning a value.

Just look at the compiled code as I mentioned above and you'll be able to understand the low-level details of this a bit more. When you look at the compiled code you'll see that the "Apply:#CALL" was being treated as a string, but then the %setglobal function was executed with the result concated to the #CALL string. This was causing %setglobal to be executed even before the #YESNO command was called.

Using the delayed expansion fixes all of this because then the argument that contains the %setglobal isn't executed unless the user clicks on that particular button.

Posted: Fri Aug 15, 2008 12:21 am