Forums Bug Reports Delimiter parsing in popup definition

As you know, the colon character (":") is used to seperate caption and command in a popup definition, eg:

menu channel {
Open Dialog: dialog -m mydiag mydiag
}

As you'd expect, putting a colon in the caption will cause problems, eg:

menu channel {
Open: Dialog1:dialog-m mydiag mydiag
}

mIRC assumes everything after "Open:" to be the command segment.
You'd also expect that if you used a colon in an identifer, mIRC would realise that it's within parantheses and not parse it, eg:

menu channel {
Open $readini(my.ini,my:section,myvar): dialog -m mydiag mydiag
}

But no!! The colon within the identifier is parsed, and you have to escape it with $chr(58).

Should not the parser recognise that if a colon is not in 'plain text' (ie. not within an identifier) then it should not be parsed as the item delimiter? It'd be nice..

...not sure if it's aactually a bug, but if it's not, then it's an illogical behaviour.

Thankyou

Tom

Why do you want a colon in the caption for?

This isn't really a bug, it's just the way the popup format works.

As in one of my examples, you may have a colon in an ini section name, or anything from a whole host of possibilities. It just seems strange that it would parse even in the middle of an identifier. Shouldn't happen any more than

/myCommand 1 2 $myIdentifier(word1 word2) 4

should count "$myIdentifier(word1 word2)" as $3 and $4 (instead of $3) just because there is a space there. It is in an identifier which 'protects' it from being evaluated by the tokenization. Guess it's because it's already evaluated before it gets to /myCommand ....but the principal's gotta be the same. A delimiter shouldn't count in the middle of an ident.