Forums Bug Reports weird unset bug

I have this var which I set with the path of a jpg:
%id.about.di_ico = $+(",$scriptdirdem_inf.JPG,")
Then I use this var in a dialog:
icon 5, 159 7 194 142, %id.about.di_ico
Then on the init event I unset the var:
on *:dialog:id.di_about:init:0:{
unset %id.di_ico %id.about.di_ico
did -ar $dname 4 1.0
}
I know this works because the id 4 has it´s text changed and the var %id.di_ico is unset, the weird thing is that the %id.about.di_ico is not unset, it somehow gains a 0. This is what is in the vars file:
%id.about.di_ico 0 C:\mIRC_6.14\dem_inf.JPG

Where the hell did that 0 come from?
Those 2 vars in front of the unset should be cleared, but they are not. I tried just doing:
unset %id.about.di_ico
But it did nothing.

So is this a bug or is there something going on here that I am not aware of ?

In mirc you type /help dialogs and find the following paragraph:

I have the same problem, though I believe it is a bug.

First, what purpose does it server to assign a variable to the pathname of an icon or the caption on a button, especially if the variable was supplied as an index? If anything, the variable should be assigned the index seeing as it was specified as the index. Also, these variables are set even when the dialog is cancelled, not just when it is closed. Cancelling means nothing that was changed should be recorded. Thus, setting a variable on a cancel is totally innapropriate.


sets %auto.colors.back to the index it already held AND the full path name as desrcibed by Infernal Demon above regardless of how the dialog box is closed.

I have a cancel button and this is how I cancel the dialog.

Therefore, I believe this IS a bug because it happens when a cancel button is clicked. On a normal close, it is understandable that the data be saved, but not on a cancel.

The help file uses an edit as an example. I can specify an edit as such and %auto.base is NOT altered when the dialog is closed.

If I add a variable to the end %temp.var IS set to the alterred contents when the dialog is closed, but again, this is done EVEN when the dialog was cancelled.

I can understand why he would add this feature, it makes it easy to assign variables to input from the user, however, a user cannot change the caption on a button or the pathname of an icon file, therefore, it doesn't make sense that these elements would return values.

The method is also inconsistent. A variable can be supplied as a value to an edit element without it being assigned a new value (as seen above), however, when supplied to an icon as a value, it is altered anyway. I believe that variables only at the end of the element definition (as in the example in the help file) should be altered. Any variables taken in as values should not be altered. If a programmer passes a value and wants that variable changed at the end, the programmer could simply place the variable name again at the end of the definition.

Also, cancel should never alter anything implicitly. The user should decide what gets altered on a cancel, but mIRC should never change anything. Cancel's are used to close a dialog without making any alterations (just like a Windows' dialog).

If the helpfile specifically explains what it does and why it does, then it is not a bug.

No it doesn't say why it does it, or even how it does it (how does it choose which variable to use?).

It's a nice "feature" but it definately has some bugs.