Forums Bug Reports [BUG]: $did($did) into an empty dialog id text

Hello,

I noticed that when i click in my dialog into an non-id (!$did) and i have an if statement or an variable to save the currently text of the sclick id it returns error instead of $null, here is an short example.

In this example when the $did from the /echo is 0 then i get an error message that i should NOT get it because the $did is 0 so the text will be also 0 ($null) and the variable %text and %text2 should be $null or 0, this error breaks and stops the script progress if not any text exists into the 0 dialog id.

Error Message: * Invalid parameters: $did (line 18, script33.mrc)



- Thanks!

I don't see a bug in mIRC here, only a bug in your implementation.

0 is not a valid dialog ID and therefore, unsurprisingly, cannot be accessed via $did. This behavior itself is not a bug, but it seems like your complaint is specific to the raising of an error vs. quietly returning $null. In this case, raising an error is not very different from returning $null-- it might keep your script from a hard-fail, but more than likely, if you're doing anything substantial with the output from $did(), your script will still break if it gets back a $null. Consider an example where you're looking up the contents of $did($did).text as a hash table key-- that would break.

In general, this should not affect scripts, since most of the time you're targeting specific IDs in your event matcher. If you're matching an ID range of *, it's your script's responsibilty to guard against invalid IDs. It's as easy as doing:



The above code makes the implementation work correctly.

More than likely you'll want to guard against other IDs, since you probably still have a set of "static" elements that should not trigger events (you wouldn't want to look up the $did().text of an arbitrary static label as a hash table key), so this is not even specific to 0. The better way to do this is not to use * unless you're debugging. Target specific actions using individual IDs.

0 as the $did refers to the dialog background (no control specified) and could have a practical use aside from the text property.

I don't see any $did() property that would make sense in the context of the background. It's always enabled, it's always visible, and the rest are mostly just controlling selection and text content/length, none of which is ever meaningful here. That said, that would be a feature suggestion (expose background control properties via $did().prop) rather than a bug report, and in this specific code case, it would still be improper to expect $did(0).text to return a meaningful value.

Lets be more specific and read carefully because you had misunderstand here, my bug report was when the $did(0).text acting to return $null and not an error message in case to not breaking down the hole code now about the other stuff you are talking about i did not understand them, you have to look again my report to understand it.

I'm fairly certain I understood you just fine,



This assertion is incorrect. You should get an error message, because 0 is a reserved value, making $did(0) an invalid ID. The error message is appropriate and is clearly intentional (as evidenced by an explicit error message that says the ID is invalid). It sounds like perhaps you are the one who did not read my explanation fully? I explained why this is a reasonable behavior in my first response.

mIRC returning an error message for a parameter it deems invalid is itself not a bug. If mIRC decided that $did(FOO) (the literal text FOO) should return an error, this too would not be a bug, since it's an intentional choice by design. In this case, mIRC intentionally disallows the use of 0 as a parameter to $did, and it's your script's responsibility not to pass this parameter in using some if-guard.

Incidentally, there is good reason for mIRC to disallow 0 as a parameter that refers to an individual control, since in all other collection based identifiers that take an ordinal parameter, an N=0 input returns the size of the collection. It would be inconsistent for $did(0) to return something other than a count, so it may just be a reserved value for future use-- that would be my guess, anyway.

I did not misunderstood because i read it carefully and you only explain how is working but i know how is working the point here is when the $did is 0 (when i click somewhere that there is not any ID exists) and the $did(0).text is $null to return $null instead of error message that is only my suggestion/bug report in this case and nothing else more, if you look further about it you can understand why to return $null instead of error message, in my first example i use an variable to store the currently $did text but i got error message that it should not get it but only gets back an $null because the most identifiers of the mIRC when there is not any data to return its getting back and $null and not an error message.

As mentioned above, the number 0 is not a valid id, that is why $did(0) is reporting an error. This is intentional and cannot be changed as the dialog code across many routines depends on this value being in a valid range.

I don't thing it would break any code if you change the way to return $null instead of an error message.

The issue, at its heart, is that you should NOT be relying on $did(0) to return anything meaningful to you. As I mentioned in my first post, it is your script's responsibility to guard against using this value:



Changing the behavior to return $null doesn't solve the problem. The 0 value is reserved and could possibly change in the future, at which point your script will begin to break in unintentional ways. Khaled is doing the right thing (in my opinion) by reserving this value via a hard-error and leaving the opportunity to add standard count-based return values in the future (or whatever), if that's the intention.

The parallel here would be if you were using some identifier that returned an index to be used in $nick(#,N), say $nickid:



If $nickid ever could return 0, you would want to make sure you guarded against this, because using it as an index would be invalid:



Furthermore, if you did not guard the value in the above case, you would be returning a collection count instead of the text you wanted, which would be outright incorrect.

The same exact story goes for $did(N), in that $did(0) could eventually start returning a count and would return the wrong result for most script usage blindly using ID input from $did when $did=0. Yours included.

It seems clear to me that this API is intentional, and the "workaround" (it's not actually a workaround, it's a proper guard, but anyway) is extremely simple to add to your script:



You might also want to focus on some of my original suggestions too, namely, that you should probably not be using an ID match of "*" for anything outside of debugging. Your dialog will likely have plenty of controls that don't have text or don't have sensible values for properties $did(N), and blindly returning $null is the wrong way to go about writing a script. The correct approach is simply to scope your events to individual IDs, either by the matcher, or via an if statement guard (similar to the one above):



If this isn't clear I can try and explain better, but you're much better off following these rules than butting your head against intentional design choices. Even if you somehow convinced Khaled to make the above change, you would be waiting until v7.44 (at least) to use this functionality, and your distributed scripts would have a hard requirement on this version when the "workaround" only involves a single line of code. Basically, you could have already solved this problem by now.