mIRC Home    About    Download    Register    News    Help

Print Thread
#56580 21/10/03 02:39 PM
Joined: Feb 2003
Posts: 810
C
cold Offline OP
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
(After an extensive search, I'm almost sure there is no topic here suggesting this.. sorry if I'm wrong, though.)

One thing that bothers me when dealing with dialogs is the fact that I can only use numbers to reference a dialog control. They're so poorly descriptive, so similar to each other and so limited. I actually use some distinct numbers, anyway (i.e. 1000 is reserved to OK buttons, 1001=Cancel etc.), but I still find this method so poorly descriptive (currently, IDs are also limited to a number I can't remember right now, 4000 or so). Don't you think?
I'm always having the need to go back to the dialog table to see which numbers I should use here and there, and the situation gets worse as the dialog gets filled with more and more controls.

One dirty thing that I do (sometimes) to ease this boring issue is to make identifiers (or vars) referencing all the IDs, but if you think of it, I'm doing the same thing twice (assigning IDs to dialog controls - firstly numbers, lastly names), which simply wastes my time and also slows things a bit (although speed isn't really the point here). Of course I'm more comfortable after doing this, because now I have names that won't be easily forgotten, so I'd rarely need to go back to remember IDs.

I could drop the identifier idea and simply write a txt or the like with an ID index, ok. This probably could be a better solution for many. However, I'd still do the same thing twice, no matter how I do it.

So I propose, why not support named dialog IDs?
This could also lead to wildcard matching support by the related commands and events (kinda like they support N1,N2,N3,...,NX ID lists), which is the other reason for supporting it, IMHO. I'd really, *really* like to use my combo list knowing it's called "servers", not "150". I'd like to disable some related controls using "/did -b $dname servers.*", not "/did -b $dname 150,151,152,155,156". These are the simplest examples, anyway. Think of a huge, complex dialog. Wouldn't the dialog scripting process be faster then? Well, to me it'd be much faster with unique names than with unique numbers, for sure.

By the way, the suggestion is to *add* this support, so using numbers and lists of numbers should still work their current way.. otherwise people would kill Khaled for their broken dialogs. :tongue:

I currently don't see any disadvantage for the whole idea, but I may be wrong, so it's open for discussion (of course, that's why I'm here). The only issue I could think of would be that the dialog system is too limited to support this (since it already limits its ID numbers), but I couldn't be sure of any issue like this, which is also why I'm here.


Oh and please, don't flame the idea whether you don't agree with it, or find it ridiculous, or think I'm too lazy or anything else. Please don't question the way I manage dialogs. No need for such personal points when I'm not *demanding* anything, since I'm always open to consider it as a bad idea - as long as you come with fine, descriptive arguments about the idea itself. This is a suggestions board, nothing else. smile


* cold edits his posts 24/7
#56581 21/10/03 05:23 PM
Joined: Jan 2003
Posts: 119
A
AKO Offline
Vogon poet
Offline
Vogon poet
A
Joined: Jan 2003
Posts: 119
Dialog naming just makes sense, but I sould prefer to use the following syntax:

dialog_table.<tab ID>.item_name

example would be:

away.tab1.edit1

or

away.edit1 in the case of no tabs.

#56582 21/10/03 05:36 PM
Joined: Feb 2003
Posts: 810
C
cold Offline OP
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
Well, this syntax would require such a huge change, don't you think? I don't know if it would be considered, given the current syntax predomination, but it'd certainly have the advantage of not limiting IDs to numbers only, which is the way to go, IMO :tongue:

Last edited by cold; 21/10/03 05:41 PM.

* cold edits his posts 24/7
#56583 21/10/03 06:55 PM
Joined: Dec 2002
Posts: 230
G
Fjord artisan
Offline
Fjord artisan
G
Joined: Dec 2002
Posts: 230
I fully agree. Named dialog IDs would make creating and maintaining dialogs MUCH easier, plus it wouldn't break older scripts.

#56584 22/10/03 01:09 AM
Joined: Apr 2003
Posts: 426
Fjord artisan
Offline
Fjord artisan
Joined: Apr 2003
Posts: 426
Yes, dialog id naming makes sense, but your method doesn't really.

All we need is to be able to call a dialog id like this:

Alternative 1:
$did($dname,$idname).property

Alternative 2:
$did($dname,$idnumber).property


Where $dname is the name of the dialog, and $idname and $idnumber are the name/number of a dialog item respectively.
.property is the property you want to call. Etc.

This (at least in my opinion), would make a lot more sense than your suggestion.

There is also no real need to call the tab ID because each item on a dialog table should be given its own unuiqe ID.
Besides, one can't have dID's with the same number, the same should be applicable to the ID name.


--------
mIRC - fun for all the family (except grandma and grandpa)
#56585 22/10/03 07:04 AM
Joined: Jun 2003
Posts: 195
N
Vogon poet
Offline
Vogon poet
N
Joined: Jun 2003
Posts: 195
the main reason this isnt the case is because windows itself uses a numeric identifier for child windows (dialog controls are child windows). It would be possible to do but it would greatly increase the time it takes to refer to a control using /did and $did. mirc would have to store a list of name vs. id values then use a lookup method to determine wich control has wich name. this would have to be done with every /did or $did call and in some scripts this could greatly decrease performance.

an example would be if a dialog had 20 controls to refer to the last control mirc would have to scan the list going through all 20 to find the id. if you made 5 /did calls to that control thats 5x20 or 100 cycles. the same would have to be true for events. on *:dialog:name:event:control_name:{} mirc would also have to perform a lookup for these as well. for very large dialogs the time to find the name would be unacceptable


Have Fun smile
#56586 22/10/03 08:34 AM
Joined: Feb 2003
Posts: 309
C
Fjord artisan
Offline
Fjord artisan
C
Joined: Feb 2003
Posts: 309
I'm half for this half against, becauwse i like doing a simple save feature that simply traverses all did's and writes the values to a text file.

Sytill it would be useful.

#56587 22/10/03 09:49 AM
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
I don't think it would affect perfomance noticeably. The control name lookup can be made very fast by storing names in a hash table. Besides, any internal search/lookup method in mirc is much faster compared to scripting. For example, I would expect that the mere evaluation of $dname in something like /did $dname blah blah is slower than looking up the ID for the "blah" control internally. In any case, if one noticed a decrease in perfomance, they can always switch to the old method with numbers.

Named controls would be handy for a lot of people, including myself.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
#56588 22/10/03 09:52 AM
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
You have a point. Sometimes I name ID's of a group of controls sequentially, so I can loop through them later. But having the ability to use named controls won't stop you from using the old method with numbers if you want so.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
#56589 22/10/03 04:26 PM
Joined: Feb 2003
Posts: 810
C
cold Offline OP
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
Well I don't have enough knowledge on this part, but if the speed is still reasonable when I use scripted identifiers already to refer to IDs, shouldn't it be when it's built-in? I'm just guessing here, but I believed it wouldn't decrease the speed so much..


* cold edits his posts 24/7
#56590 22/10/03 04:29 PM
Joined: Feb 2003
Posts: 810
C
cold Offline OP
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
Like qwerty said, you'd still have the possibility to use this method. smile On the other hand, you could even use an wildcard match to do so, if Khaled made it possible.
Plus, supposing this ability was lost by any reason, you could use $did().next/$did().prev (maybe slower, but still possible).

Last edited by cold; 22/10/03 04:36 PM.

* cold edits his posts 24/7
#56591 22/10/03 11:34 PM
Joined: Jun 2003
Posts: 195
N
Vogon poet
Offline
Vogon poet
N
Joined: Jun 2003
Posts: 195
you are right C would be much faster than scripting but even using asm in large data lookups can be noticeable. As a somewhat small test try this create the hashtable fill it with 50 or items name My_dialog_control_id_name_1 etc... then perform a lookup for the last item do this in a while loop 20-50 cycles. C of course will be faster than this but not by much.

Now you have to remember not everyone writes clean code. And again this lookup would have to be performed for _every_ /did $did on *:dialog: for example if you used $did on an editbox to get its text then /did to set it to something else mirc would fire the edit dialog event. thats 3 lookups. now imagine multiple controls names on a command such as

/did my_id_1,my_id_2, yadday yadda ...

this has 4 lookups right off the bat 2 for the command and 2 for the event. imagine this in a loop.

or worste still imagine an event wich makes calls and alters other controls first you perform a lookup on control_1 fire the event for control_1 yet another lookup this event alters controls_2 another lookup and of course it must fire an event yet one more lookup.

the reason you cant simply cache the id's is because events and commands work in different areas. when you /did -r on an edit box mirc simply uses SetWindowText(editWnd,""); of course the edit window calls the WndProc of its parent window letting it know its text has changed. at this stage mirc would fire its event (the edit dialog event) but it is not aware of the fact that you just /did -r 'ed a control so yet another lookup.

There are a few ways you can work around the speed issue im working on a few for a TI project im writing. However its a bit of development for something that seems a bit small to me. I think khaleds time would be better spent on other aspects. (not that i dont like this idea)


Have Fun smile
#56592 24/10/03 12:14 AM
Joined: Feb 2003
Posts: 810
C
cold Offline OP
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
Well, as I said, I make use of this already, referring to identifiers, which are slower than hash tables, and nothing was noticeably affected to make one prefer to drop this method..
This leads me to believe that it's simply a matter of choice. If one wants so much the current speed, the numeric IDs would still be there. I don't believe any further work to develop names would be needed.


* cold edits his posts 24/7
#56593 24/10/03 04:07 AM
Joined: Oct 2003
Posts: 38
T
Ameglian cow
Offline
Ameglian cow
T
Joined: Oct 2003
Posts: 38
I agree, i think that, much like the -l switch, a -n switch could be used to either enable or disable dialog id names, so that if speed was critical you could completely disable id names so that mIRC would not automatically create a "ID name table," nor would it loop through all of the ids to find out what the name was. I don't really think the speed what be all that bad. C/C++ is quite efficient and if all you are doing is using a "struct" in an array and comparing strings to find the id just referenced or the id that has caused an event to occur, i think that this could take no more than a few milliseconds.


-TheXenocide
ParseMPopup
#56594 24/10/03 06:16 AM
Joined: Jun 2003
Posts: 195
N
Vogon poet
Offline
Vogon poet
N
Joined: Jun 2003
Posts: 195
i am aware of the efficiency of c/c++. The simple fact is anytime _any_ program has to perform additional tasks it will be slower. The issue isnt wether or not it will be slower but by how noticeable the slowdown is. Now for a smaller dialog perhaps the speed is irrelevant. However were talking about mirc script. Ive yet to see any two scripts implemented the same way. There are no standards whatsoever (at least none ive seen) i have seen dialogs using tabs with way more than 20 or even 50 controls. imagine having several dialogs open at once.

Im not doubting the validity of the idea in fact it would be a much welcomed addition but we cant overlook all issues. anyhow its a good idea one ive implemented with hash tables (cold how is it yours isnt using hash's are the dialogs small?)


Have Fun smile
#56595 24/10/03 08:35 AM
Joined: Feb 2003
Posts: 810
C
cold Offline OP
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Feb 2003
Posts: 810
Quote:
(cold how is it yours isnt using hash's are the dialogs small?)

My dialog isn't small in size, although it has only about 50 non-hidden controls. What I've done to test it was to call its table 3 times at once (using different names and dynamic x/y positions, so I could visualize them all), plus some other random dialogs which I didn't change to the "named methods". Then I've managed to use their various functions and didn't notice anything *that* slow.
However, since the dialog wasn't really finished, I've decided to test other scripts with completed and bigger dialogs. Changed some so they'd refer to their IDs via identifiers, which were like "alias -l _mp3.list { return 10 }". Scripted also a "list" identifier which would replace /did lists like "1,2,5,..." by "$dlist(_mp3,list,filter.text,filter.edit,...)", so a little extra processing was done here.
By the way, I've tested all of these while connected and being on some active channels. I didn't notice any considerable slowdown.. only with one or two dialogs which used the MDX DLL (not all of them, not everytime either).

Considering that I was using interpreted identifiers, their little downside shouldn't be any close to the result of an additional built-in support (I guess).. like I said, I don't believe speed would be the main point.
You're right, we can't overlook it, although I just thought this issue could be best analyzed by Khaled, but anyway.. I've tested it myself before with what I had in hands, so why not.

I'll see, when I have time, if I do this again with some scripts, then I could post them here, if you want to do some testing. Although you could script it yourself too smile

Last edited by cold; 24/10/03 08:46 AM.

* cold edits his posts 24/7

Link Copied to Clipboard