bvar scoping for signals - mIRC Discussion Forums

When using /signal -n bvars present in the caller's scope can be manipulated within the signal event. The changes made within the signal event alter the bvar present in the outer scope. But the reverse is NOT true. BVars created within a signal event do no propagate into the caller's scope. This is, at the least, unexpected as bvars are considered globally scoped.

Example code:

Code:

alias example {

  ; bvar not created prior to signal call;
  ; Should result in the bvar being set to xyz
  signal -n example
  echo -a Post-Signal: $bvar(&example, 0)

  ; bvar created prior to signal call
  bset -t &example 1 abc
  signal -n example
  echo -a Post-Signal: $bvar(&example, 0)
}

on *:SIGNAL:example:{
  bset -t &example -1 xyz
  echo -s In Signal: $bvar(&example, 1-).text
}

I stumbled upon this working on an HTTP client what allows for custom headers to be specified from signal events. Figured I could store the headers in a bvar, and then access that bvar after the signal event to add headers had finished:

Code:

.signal -n AddHeaders!Example
if ($bvar(&customheaders)) {
  ; append to HTTP request
}

Instead I have to create the bvar with arbitary data first, then remove that data after the call:

Code:

bset &customheaders 1 0
if ($bvar(&customheaders, 0) > 1) {
  bcopy -c &customheaders 1 &customheaders 2 -1
  ; append to HTTP request
}

I believe this is a case of the bvars being unset prematurely after the /signal has finished but before execution is returned to the caller.

--

After further testing, I'm positive it is 'execution cleanup' after the signal events finish but before execution is returned to the caller, as variables exhibit the same behavior:

Code:

alias example {
  
  ; %example is $null after the signal
  signal -n example
  echo -s > %example

  ; %example is 'value' after the signal
  set -u0 %example value
  signal -n example
  echo -s > %example
}
on *:SIGNAL:example:{
  set -ku0 %example value
}

In the last example(variables) to clarify the code:

Code:

alias example {
  
  ; %example is $null after the signal
  signal -n example
  echo -s > %example

  ; %example is 'signal value' after the signal
  set -u0 %example value
  signal -n example
  echo -s > %example
}
on *:SIGNAL:example:{
  set -ku0 %example signal value
}

Thanks for your bug report. This is intentional. Just because /signal -n forces an event to be triggered, that does not mean it is in the same scope. The scope is unique to that event, in the same way that all events have their own unique scope. Since binary variables are cleaned up on exit of a scope, your workaround is the only way to achieve what you want.