brrriinng
lol, man I should have read what you said correctly, my original statment about the DLL loaded in what cid was pointless sorry.
I didnt even pay enough attention to realise your calling a dll that calls mirc back again
I would assume its showing 1 becuase when it calls mirc its like a seprate event (a someone is calling me event if u like), while someone else may have mentioned this also I would ask what is the result of evaluating $nick instead of $cid if you called the /dll from with in a ON *:TEXT ? and also $me (if using differing nicks per cid).
I think the key to saying if this is a bug of not is this line from the help file.
"To prevent simultaneous access to the mapped file, your code must check whether the mapped file exists or not before using it. If it exists, you should assume that it is in use by another program, and should try again later."
To me that says that mirc is dealing with sendmessage requests from programs as events in there own right and not part of the current event running as if it was then you shouldnt have to wait as your the only one doing anything.
I would find it disturbing if another aplication which was doing alot of sendmessages to mirc suddenly encountered that during one of them the $cid had changed to a different number.
As a matter of interest does the returned $cid always appear as 1 or does it match the first status windows cid?, (open second status window, then close first status window to make the new first status window (was the second one) cid change number)
