Dialog ID's and $(...) - mIRC Discussion Forums

It would be great if mIRC supported $(...) in the dialog ID section of dialog events.

To illustrate what I mean:

Code:

alias -l id_ok { return 1 }

dialog test {
  title ""
  size -1 -1 300 300
  option dbu
  button "ok", $id_ok, 125 125 50 50, ok
}

on *:dialog:test:sclick:$($id_ok):{ ; this doesn't work, would be great if it did. }

on *:dialog:test:sclick:*:{
  if ($did == $id_ok) { ; this does work. }
}

Wow I just asked about this Friday on Freenode. I decided to include the magic number in the event and just comment above it with the id alias so I could find it easily when needing to be changed. Maybe having a wildcard event and calling aliases would be better. Are $dname, $devent, and $did the only identifiers I would need to pass?

I'm not at mirc to test right now but I don't think you'd even need to pass anything, aliases usually inherit the identifiers from the calling event, which is why you can use $nick etc in an alias called from on JOIN. I can't see a reason for the same not to be true for dialogs.

Oh wow I had no idea.

So would you also expect $() to work in the dname part? or event?

Code:

alias -l dname return test
alias -l event return sclick
on *:dialog:$($dname):sclick:1:?
on *:dialog:test:$($event):1:?

Event, no, dialog name, sure why not?

The reason I say no to event is because it makes no sense. When writing a script you would clearly be intending to capture a particular event and the event names are static.

Dialog name would make sense though.

Originally Posted By: hixxy

When writing a script you would clearly be intending to capture a particular event and the event names are static.

Not necessarily... this only matters when two events require different processing, but this is not always the case. For example, sclick and dclick refer to basically the same event but with a slightly different interaction. A scripter might want to simplify an option for users to specify whether their events occur on dclick or sclick and therefore would be stored in some $config.clicktype identifier (which reads from an ini file, perhaps). You could check $devent, but this is just the same exact argument for $did or $dname.

I brought up those two examples because this seems arbitrary to me. Traditionally mIRC has been fairly consistent about only allowing $() in matchtext event parameters. How will users know that did and dname accept $() but event does not? Should mIRC document every place where $() is accepted? If so, why not just accept $() everywhere and be done with it?

I'd be fine with $() being accepted everywhere...can't see any reason not, it's just beyond the scope of my suggestion.

I agree, if anything, it should be extended to any event's parameter

You people realize that you could do

on *:dialog:$($dialog($dname,$did)):$($dialog($dname,$did)):$($dialog($dname,$did)):

What?

Originally Posted By: MeStinkBAD

You people realize that you could do

on *:dialog:$($dialog($dname,$did)):$($dialog($dname,$did)):$($dialog($dname,$did)):

1. $() does nothing in the event header
2. Assuming you meant $did($dname,$did) and are talking about if the suggestion is implemented - not only would it be meaningless - but so what?

You can't do this in the current version of mIRC-- this is the point of the feature suggestion.

As a sidenote, your specific example wouldn't even work if $() was supported.