This is one of those cases where its actually good that mIRC is not multi threaded. While it is true that any dll or application can create the mapped file the only time you need to worry is in the case of an external application.
SendMessage is a blocking function (i.e mIRC does not use the ReplyMessage fn to release the caller) so when dll a uses the mapped file it wont be in use by another dll from within the same thread (most dll's are not multi threaded either). This does not mean however that an external application wich runs within its own thread isnt using it. We get away with it because of the fact that there arent too many external applications in use. Sorta not a good idea to just assume but what can you do?
The returned cid is whatever happens to be active. in the previous sample i call it from within cid 1 changing to cid 2. In this case it returns 1. If i call the same dll from cid 2 and change to cid 1 i get 2 returned from the mapped file.
I can understand Sat's position I dont think anyone should rely on the mapped file to call script from within thier dll. Unfortunately there are times where you may need to and mIRC doesnt export any sort of API (Would be a sweet feature).
Just a small sample. Imagine you store a list of say windows. Since you can have more than one window with the same name using a windows name is almost pointless. You would use the cid value of the window to determine wich one to use or its handle. The real problem comes from events. Imagine the script has an autojoin script and joins a network and a channel. If the channel and network are minimized upon joining the cid doesnt change. Now when you try to do something say add a channel window to the list you could run into problems since that window may already exist (per the 1st cid) so the new window isnt added. Later on when you try to access the window from the list based on its cid most likely youll have an error becuase the window doesnt exist in the list.
Really it may sound confusing but its actually quite popular. Alot of dll's will subclass a window for whatever reason and it needs to store the info. passing $window(@name).hwnd to every function that performs a task on that window would be tedious. Unlike dialogs there is no /did command for a window so you cant piggy back mIRC in this case. Anyway thanks for the input all.
