Forums Bug Reports $v1 not filled in popups

I was expecting this to work, but $v1 is $null when executing the commands. Why would $v1 be $null here? Seems like a bug to me.

Perhaps because the left side is evaluated when loading (showing) the popup and the right side is evaluated when you actually click on something?

That's for sure Sat , it's similar to others inconsistencies:
$v1 with filter -k and $regml() with filter -kg

The reason it's not working are obvious now, $v1 works outside a scope but it's not working if the call chain is broken (filter breaking the call chain is another topic)

Yet it would make it consistent to re-fill $v1 in those specific situations, it's really about refilling $v1 in a popups menu, after the popups has been displayed and refilling it when filter -k is used (making it consistent by changing $v1 not to work outside statements doesn't make sense and is not an option). This is a logical follow up imo, I would like $v1 to work whenever it can in a logic way, regardless of the technical issue.

It's not something difficult to add, it wouldn't break any script, and as far as filter and $regml are concerned, it would make things working as intended, one typically use filter for the speed, if you use a regular expression and you call an alias (-kg), if you have to remake a $regex call inside the callback alias to fill $regml, it looks wrong..

Really, things are working as they meant to be, they just were meant to be working in a way that can be seen as incorrect, or incomplete, leading to inconsistencies, this is also true for things like $1- being used inside $regsubex, how would one know, how many people have to report the problem so it gets added to the help file? I might be the only one making it a big deal but anyone could face the situation.

A note in the help file "$v1 won't work in some specific situations" wouldn't make much sense, but the actual situation is also a problem, scripters should be able to know about inconsistencies when they exist, even if 99% of scripters has no idea about them.

There is no certainly no bug in there; it's a well understood behavior that the code associated with the menu item only gets evaluated when you click on that item. Because of that, you can think of your code as being placed in virtual aliases that get invoked.



By 'call chain' I assume we mean mIRC is executing the code from it internally from the same root function that executed the original code that created $v1. While that's true in general, it's not really true for /filter since the call chain is not broken. Note that in the menu scenario, it does happen.



No need to quote the rest of the statement however in the case of the menu it's actually not possible to implement it in a sane way, that would require keeping all kind of strange states. Imagine the following code:



If I click 1, will echo print 1 as well? What happens when I click 2? The most logical thing to do is what mIRC currently does - start from blank and execute the code associated with that item. To make it print 1/2/3 for the three menu items respectability requires a hell lot of work with little to no gain and mIRC will now have to keep individual states for each menu item code segment. You have to remember that the code in the item's name gets evaluated first. I.E. $iif(1,1) then $iif(2,2) then $iif(3,3) way before code associated with a specific item gets executed - if it even gets executed.

You missed a bit my point, I only want mIRC to re-fill $v1, after it finished evaluating the content of what will be displayed for the popups, $v1 would be always 3 when clicking on an item in your example

A terrible idea indeed, hixxy

Hey it works! :p

The creation of the popup menu item is completely independent of the command that it calls. There is no way to pass state values (of which there are many - not just $v1) from one identifier evaluation into another separate identifier evaluation. The solution that hixxy provided is the only way to do what you want, as far as I can see.

I know the creation is independent of the command called, but could you please elaborate on why you think there is no way to pass $v1 there (I'm not talking about others states)? The workaround hixxy provided works but it's what it is, a workaround to a problem, not a proper solution I overlooked.

What is your opinion on the $regml issue with /filter? Is the correct usage to make a new $regex call in the callback alias to fill $regml even though the regex match has already been made? Is there no way to change that too? If so, why?

There is no way to pass $v1 across independent calls to the script parser because the script parser was not designed to do that and for good reason. The $v1 value is part of the evaluation of a particular script call. It has no connection to any subsequent calls, so it would make no sense to make it persistent across calls. You will need to do what hixxy has suggested.

If I remember correctly, the /filter and $regml discussion is in a different thread. Please do not mix topics in the same thread, it makes it very difficult to keep track of discussions and bug reports.