Originally Posted By: Mpdreamz
What starbucks_maffia pointed out quite rightly was that instead of replacing with the contents of %username replace with the string %username
so that
You are $iif([username] == $null, not logged in, logged in as [username]) $+ .
instead of turning into
You are [color:#FF0000]$iif(Mpdreamz == $null, not logged in, logged in as Mpdreamz) $+ .[/color]

becomes $iif([color:#006600]%username == $null, not logged in, logged in as %username) $+ .[/color]

which mIRC will evaluate correctly even if %username is indeed null.


Yeah I see how that would work. My goal was to place no restrictions on the positioning of "[username]" inside the format-string. In other words, I don't want to require it to be delimited by spaces.

For example, to produce the output...
You are logged in as test_username.

I want to be able to use the input...
You are logged in as [username].

I don't want to require the input to be...
You are logged in as [username] $+ .

With that said, it is clear that the $replacex(...) needs to replace [username] with the actual value of %username instead of the string %username.
Code:
$replacex(You are logged in as [username]., [username], %username)

This will always produce the correct output!

---

With that said, another feature I want to implement is the ability for the input string to contain identifiers. This would require the format-string to be evaluated twice. Conclusion: In order to accomodate both this feature and the one previously mentioned, two things need to happen
  1. Evaluate the format-string
  2. Replace occurrances of [username] with the value of %username
Let's see what happens when we do those 2 steps in that order.
Code:
var %format_string = You are logged in as [username], and the current time is $asctime $+ .
var %reply = $replacex($eval(%format_string, 2), [username], %username)

This works!

But wait. Let's try another format-string. Specifically, let's try one that uses the $iif identifier.
Code:
var %format_string = You are $iif([username] == $null, not logged in, logged in as [username]) $+ .
var %reply = $replacex($eval(%format_string, 2), [username], %username)

Since the evaluation of the if statement occurs before the replacement of [username], we get unexpected output. In this case, the script is testing if the string "[username]" is a null string. Obviously it isn't a null string.

From this example, it becomes clear that we need to do the 2 steps in this order
  1. Replace occurrances of [username] with the value of %username
  2. Evaluate the string


Let's try the last example again, but switch the order in which we do things.
Code:
var %format_string = You are $iif([username] == $null, not logged in, logged in as [username]) $+ .
var %reply = $eval($replacex(%format_string, [username], %username), 2)

This looks like it should work as expected, and it does... under one condition: the value of %username is not null.

When the value of %username is null, the script attempts to evaluate this...
You are $iif( == $null, not logged in, logged in as ) $+ .

The problem is that mIRC doesn't know how to handle ( == $null)
Somebody earlier made the point that this is ambiguous and that it could mean several different things. They concluded that mIRC intentionally doesn't handle this conditional expression because it doesn't know what is meant by it.

My point is... I only see one logical way to interpret ( == $null)
And that is ... "Does the thing on the left (a null string) equal the thing on the right (also a null string)?"

And since there is only one way to interpret this conditional expression, in it's next version, mIRC should be able to evaluate the expression as TRUE, rather than give an error.

Last edited by Exlax; 15/02/08 07:15 PM.