|
|
Joined: Jul 2006
Posts: 4,150
Hoopy frood
|
OP
Hoopy frood
Joined: Jul 2006
Posts: 4,150 |
Using SendMessage() to evaluate $mid($null,1) correctly gives $null. If you try to evaluate $nick from a remote context event with the wrong eventid number, $nick doesn't evaluate to $null but to the plain text "$nick" (just like in the editboxes), rather than $null, which is wrong. extern "C" int __stdcall getvaluefromeventid(HWND mWnd, HWND aWnd, CHAR *data, char *parms, BOOL show, BOOL nopause)
{
char pre[70];
strcpy(pre,data);
int eventid = atoi(data);
strcpy(str,"$nick");
SendMessage(mWnd, WM_MEVALUATE, MAKEWPARAM(0, 12), 0);
strcat(strcat(strcat(strcpy(data,"trying to evaluate $nick from eventid: "),pre)," -- value: "),str);
return 3;
}
//somewhere else, before calling the above:
file = CreateFileMapping(INVALID_HANDLE_VALUE,NULL,PAGE_READWRITE,0,5000, "mIRC");
str = (LPSTR) MapViewOfFile(file, FILE_MAP_ALL_ACCESS, 0, 0, 0);Now about the implementation of this feature. One could easily wonder why do we need an ID for this. It was certainly possible to evaluate with SendMessage from an event before, but I guess local identifiers wouldn't be evaluated, either because it was overlooked, or on purpose. One would then think a simple BOOL value or similar (or'ing the cIndex parameter with a new value for example), telling mIRC that SendMessage is allowed to evaluate local identifiers would work. Why is the eventid required? Playing with this, you quickly realize the current implementation allows one to evaluate local $identifier of previous events triggered in the same 'chain': Script1.mrc: on *:text:!mytrigger:#mychan:set %oldeventid $eventid
Script2.mrc: on *:text:!mytrigger:#mychan:$dll(mydll.dll,myfunct,%oldeventid) | unset %oldeventid
Note that if the chain is broken it doesn't work. While this requires an ID to work, it's not documented and practically speaking, I can't find a purpose for it, I could eventually see a purpose if you were able to get local identifiers's values from any event given its eventid.. Why is mIRC using this method instead of a simple bool value?
Last edited by Wims; 26/07/14 09:32 PM.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
Joined: Apr 2004
Posts: 871
Hoopy frood
|
|
Hoopy frood
Joined: Apr 2004
Posts: 871 |
If you try to evaluate $nick from a remote context event with the wrong eventid number, $nick doesn't evaluate to $null but to the plain text "$nick" (just like in the editboxes), rather than $null, which is wrong. This sounds like a simple case of "don't do that then." There is no legitimate case for passing in the wrong event ID, so when you do, you (the DLL writer) are at fault, and anything that mIRC does as a result can at most be classified as "undefined behavior." Why is mIRC using this method instead of a simple bool value? Have you considered that mirc supports nested event execution? ( link to give you some idea of what that means)
Saturn, QuakeNet staff
|
|
|
|
|
Joined: Dec 2002
Posts: 5,424
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,424 |
If you try to evaluate $nick from a remote context event with the wrong eventid number, $nick doesn't evaluate to $null but to the plain text "$nick" (just like in the editboxes), rather than $null, which is wrong. Are you checking the error value returned by SendMessage()? It will return 1 for success and 0 for failure. If you specify the extended error information option, it will return more detailed error information.
|
|
|
|
|
Joined: Jul 2006
Posts: 4,150
Hoopy frood
|
|
OP
Hoopy frood
Joined: Jul 2006
Posts: 4,150 |
While I agree, there are no legitimate case for passing wrong values to commands or identifiers either, yet there mIRC is quite verbose.
I did include an example of 'nested events', though I'm talking about mIRC events (the message loop is not our business), what would be a legitimate case where if we didn't have the eventid parameter, the design of the feature wouldn't work?
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
Joined: Jul 2006
Posts: 4,150
Hoopy frood
|
|
OP
Hoopy frood
Joined: Jul 2006
Posts: 4,150 |
I'm not checking the error value returned by SendMessage(), forgot about that, sorry I should have be checking for that.
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
Joined: Apr 2004
Posts: 871
Hoopy frood
|
|
Hoopy frood
Joined: Apr 2004
Posts: 871 |
I did include an example of 'nested events' Why no, you did not. With nested events, one event triggers while another event is still being processed. Consider the following (contrived) snippet: on *:SIGNAL:signal?:{
echo -s entering signal handler: $signal (eventID $eventid $+ )
.signal -n signal $+ $calc($remove($signal,signal) + 1)
echo -s leaving signal handler: $signal (eventID $eventid $+ )
}
alias nested_signals { .signal -n signal1 }
Running /nested_signals will give you something like: entering signal handler: signal1 (eventID 791)
entering signal handler: signal2 (eventID 792)
entering signal handler: signal3 (eventID 793)
entering signal handler: signal4 (eventID 794)
entering signal handler: signal5 (eventID 795)
entering signal handler: signal6 (eventID 796)
entering signal handler: signal7 (eventID 797)
entering signal handler: signal8 (eventID 798)
entering signal handler: signal9 (eventID 799)
leaving signal handler: signal9 (eventID 799)
leaving signal handler: signal8 (eventID 798)
leaving signal handler: signal7 (eventID 797)
leaving signal handler: signal6 (eventID 796)
leaving signal handler: signal5 (eventID 795)
leaving signal handler: signal4 (eventID 794)
leaving signal handler: signal3 (eventID 793)
leaving signal handler: signal2 (eventID 792)
leaving signal handler: signal1 (eventID 791) This is an example of nesting of event execution. As for event IDs, the general idea is that by using the event ID, a DLL can retrieve the value of any of context-specific identifiers in the stack of (nested) events that are currently active. In this particular example, $signal obviously contains a different value within the context of each of the handlers being active. Thus, if called from the signal9 level, a DLL could evaluate $signal using each of the listed event IDs, and get each of the signalN (N=1..9) values as a result. Now, whether it is actually useful to perform evaluation in the context of any but the top of the event stack, I don't know, but I certainly wouldn't exclude the possibility. In any case, the event ID is a legitimate construction to allow for it to be done. As an aside: if one calls "//while (1) nested_signals" from an editbox, mIRC gets stuck in such a way that ctrl+break has no effect and must be force-closed.
Saturn, QuakeNet staff
|
|
|
|
|
Joined: Jul 2006
Posts: 4,150
Hoopy frood
|
|
OP
Hoopy frood
Joined: Jul 2006
Posts: 4,150 |
Right, they weren't nested but the point is the same, you have more than one event and you could possibly want to get the local identifiers for each, though signals there make more sense than my on text events because in my example, pretty much all local identifiers have the same value for each event. Thanks 
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
