It's a pity the id can be only the a number.
A string would have some benefits:
- it could have a name indicating what it is for, which would make it much easier to remember, it's much harder to remember numbers than to remember names.
- it allows to have shorter id's because a range A-Z 0-9 (etc?) allows for much more combinations for the same length.
Of course, using complete descriptive names like 'funtools.list.addnew' would seriously limit the amount simultaneous affected ids for a /did command, but, that would be entirely up to the scripter. It gives the free choice.
If he decides its more important to have easier to remember names than the drawback of needing more /did commands, then he choses the first, or in the other case, the latter.
And ranges would be still possible, alike /did -c funtools.checks.* or /did -c funtools.checks.1-funtools.checks.4, so some reserved chars like * and - would be needed then.
Personally, I would like it especially for being able to have controls named like FT1 FT2 FT3, whereas the FT stands for 'funtools' (just an imaginary example) so any controls with names matching FT* would belong to that same script part.
It would make it hell a lot easier to create and maintain a script. Now the only thing you can use in a search in the script editor is a number, so it can have alot false positives, especially with the lower numeric ranges, and for ex id 10 is inside 110 so also a false positive, and that's becoming a real pain when dealing with larger dialogs.
I know you can use a hashtable etc to couple id numbers to names, but thats a big messy overhead and bloat since it requires to use an in between command/identifier referencing all over the place, alike having to do var %h = Hconfig | did -c funtools $hget(%h,FT1,FT2,FT3), the lesser the amount of affected controls, the bigger the overhead counts.
