Strange buggy in mIRC 6.1 - mIRC Discussion Forums

When I use this:

Code:

on *:DIALOG:apdate:SCLICK:6:{
  set %seeapdate 1
  :loopzer
  if (%seeapdate &gt; $did(4).lines) { halt }
  if (%seeapdate &lt;= $did(4).lines) {
    if (%theapdate == $did(4,%seeapdate).text) {
      if (%apdate [ $+ [ %seeapdate ] ] != $null) &amp;&amp; (%browser == $null) { url -n %apdate [ $+ [ %seeapdate ] ] | ;echo -a hi }
      elseif (%apdate [ $+ [ %seeapdate ] ] != $null) &amp;&amp; (%bdisable == o) { url -n %apdate [ $+ [ %seeapdate ] ] }
      elseif (%apdate [ $+ [ %seeapdate ] ] != $null) &amp;&amp; (%browser != $null) { run " $+ %browser $+ " " $+ %apdate [ $+ [ %seeapdate ] ] $+ " }
      halt
    }
    else {
      inc %seeapdate
      goto loopzer
    }
  }
}

Notice the comments, when I use the comments, it halts the script for some reason after the first %seeapdate is inced... However, when I put the comments on a new line or remove it, it works fine... What's wrong?

Seems to be a buggy with goto loops, with while loops it works fine.

Code:

dialog adc {
  title "New Project"
  size -1 -1 140 45
  option dbu
  button "Button", 1, 20 11 37 12
}

on *:dialog:adc:sclick:1:{
  /*
  set %test1 1
  :l
  if (%test1 &gt; 100) { halt }
  else {
    if (%test1 == 50) { echo -a %test1 | url -n boOboO | ;echo -a ha }
    else { inc %test1 | goto l }
  }
  */
  set %test1 1
  while (%test1 &lt;= 100) {
    if (%test1 == 50) { echo -a %test1 | url -n boOboO | ;echo -a ha | return }
    else { inc %test1 }
  }
}

Comment and uncomment the code you want to test.

btw; using mirc 6.1

Oops I'm sorry, it also happens with while loops.

The problem is solved when you execute a command after using the commented echo, eg /return... Funny stuff isn't it

lol---

; means Comment EVERYTHING after this character

i.e. mirc stops parsing the line. the closing } you have is completly ignored.

Not really; mirc ignores everything after the comment up to the next pipe. You can quickly verify this with:
//echo -a one | ; echo -a two | echo -a three

There is a bug here indeed. When the condition of an /if statement is FALSE and the body consists of multiple commands separated by pipes and there's a comment at the end, the closing } is ignored. Here's a simple alias that demonstrates the problem:

Code:

commentbug {
  if (1 == 1) { echo -a 1st condition is true | ; echo -a 1st comment } 
  echo -a 1st /if finished
  if (2 == 3) { echo -a 2nd condition is true | ; echo -a 2nd comment } 
  echo -a 2nd /if finished
  if (4 == 4) { echo -a 3rd condition is true | ; echo -a 3rd comment }
  echo -a 3rd /if finished
}

The result is this:

Code:

1st condition is true
1st /if finished
[color:blue]-
* /if: close bracket not found (line 15, aliases.ini)
-[/color]

Ie mirc errors when it reaches the 2nd statement and halts the script. If you make the 2nd condition TRUE the script runs normally.

Adding a pipe after the comment (and, optionally, a third command after that) fixes it:

Code:

commentbugfix {
  if (1 == 1) { echo -a 1st condition is true | ; echo -a 1st comment } 
  echo -a 1st /if finished
  if (2 == 3) { echo -a 2nd condition is true | ; echo -a 2nd comment [color:red]|[/color] } 
  echo -a 2nd /if finished
  if (4 == 4) { echo -a 3rd condition is true | ; echo -a 3rd comment }
  echo -a 3rd /if finished
}

hmm ok then, but mirc should be made to NOT ignore the closing bracket, if not its funny for some scripters who do not know about this

its inconsistency.

Inconsistency? Inconsistency is with your cluttered code. I've found that most people produce code that is completely smashed together with multiple functions on piped lines. If you want this to be cleared up, seperate your code up.

For many, it's easier to read, easier to follow brackets, and easier to debug if there are problems.

Though I do have a problem with nesting at times on my code, I'll be working on that.

This is a word of advice from coding wise

Besides, it behaves just as it should. This is not a bug. As was stated earlier, put a | after the commented part. The comment is supposed to be on a line, not within the code itself. That's just really bad layout.