Is there any sane way to use vars with popup?
I tried to use something like:

*Popup "Mail" $Email$
*Popup "WWW" $Browser$

whith

Email "C:\Programs\Netscape\Communicator\Program\netscape.exe -mail"
Browser "C:\Programs\Internet Explorer\iexplore.exe"

But it does not work like expected!
(Broser will not be opened)

This works:

*Popup "Mail" $Email$
*Popup "WWW" "$Browser$"

But only as long Email has *no* space in the programs path or Browser uses has no arguments.
Thats no good for a general theme :-(

Well that is a problem that can't really be solved in any easy way.

One could make a program that can tell the difference by testing for filenames. That is, it first checks whether "C:\Programs\Internet" is the name of a file and then when that fails move over to "C:\Programs\Internet Explorer\iexplore.exe". I don't think that that is a good idea.

I guess we have to assume that the whole thing is the name of a file and let users put any program that takes extra options in a shortcut (i.e. a windows shortcut).

do *Popup "Mail" "$Email$" and you should be good

you can always create a shortcut (i mean real windows shortcut) and point your evar to that ;)

@egonz: right, this should work anyway but I wondered about a way to do a "general" theme (that other people could use someday)
@DeViLbOi: in fact it does not work, because the file "netscape -mail" does not exist

btw. I tested *Shorcut, it won't work either

Have you tried both single and double quotes? (and no quotes around "$Email$")

Email "'$programfiles$netscape.exe' -mail"

(assuming you already made sure the path is right, it's usually Program Files...)

I wonder if the devteam would consider replacing $vars$ with the entire line if there's more than one token...

The single/double qoutes mixture works perfect if one uses
*Popup "Name" $yourvar$

Thanks a lot.

RabidCow: I have run into numerous problems if $vars$ are not tokenized, at least with current themes. If at one point backwards compatibility was broken and all step.rcs would have to be rewritten this could be changed since we could then enforce a new syntax, but currently this is not possible.

Ah, ok. Thanks for trying it anyway :)

What I don't understand is that if I need quotes around an evar to set it, why are they not assumed when the eVar is referenced. Its not like it could break anything.

This right here is an example of something it would break.

I don't understand how it would.

if $email$ looks like C:\Program Files\Outlook Express\msimn.exe or whatever assuming "C:\Program Files\Outlook Express\msimn.exe" shouldn't break anything.

DeViLbOi: it would break. Look at this:

a)
shortcut2 would see this:
When $evars$ are expanded only the first token of the definition is used. The line above obviously won't work. Conclusion: You must use "" in the evar definition.

b)
(same thing as a, but quotes around the Email definition)
this is what it looks like to shortcut2:
This looks a lot better but still won't work. The first "level" of quote characters is stripped when $email$ is expanded. Shortcut2 will tokenize the *shortcut line and it will try to find an executable/!bang string and a parameter string. In the example above it would assume that c:\program was the executable and that Files\Outlook.exe was the parameter string. Conclusion: You must either use quotes around $email$ in the *shortcut line OR use both single and double quotes in the $email$ definition.

c)
(quotes around everything)
the result is:
This will work perfectly (without parameters in the $email$ definition). The entire C:\Program Files\Outlook.exe string is intepreted as the executable name. The quotes from the Email definition are stripped but the quotes around "$email$" in the shortcut line still exist. Note however that any parameter like -mail given in the Email definition line would look like it was part of the executable's name.

d)
(now there's a parameter in the Email definition line)
the result is:
Single quotes work just as well as double quotes with the current lsapi. This will correctly intepret C:\Program Files\netscape.exe as the executable's name and use -mail as the parameter.

However, you should NOT assume that it is always best to use variant d). It can have sideeffects and will cause confusion, hence you should only use it locally and probably not distribute themes using d). At the moment most themes, users, and possibly even modules will assume that variant c) is used. IMO it is easier to read c) anyway.
There might be a solution for this dilemma. I can't test this right now but I think that c) would work even with parameters if LSExecute was modified to use CreateProcess instead of ShellExecute. CreateProcess reinterprets the command line it is given and can separate the arguments from the executable's name itself. !bangs with parameters would NOT work that way, but ParseBangCommand could possibly be modified as well to make even that work. The only disadvantage would be that we can't have !bangs with a space in their name. :p
I hope that made any sense. =)

oh my god :O
it's amazing how much one can learn with reading just one post.
thanks, ilmcuts ;)

Im sorry ilmcuts...I still don't see how what I was talking about would break things. How can automatically putting double quotes around the output of an evar when it is used breaks things.

D) Should not work because -mail would be a param. to *Shortcut and not the path because it is not within double quotes.