Forums Bug Reports $cid and /dll bug

Im not sure if this is a bug in the mapped file or in the way mIRC handles the active connection when calling a dll however the returned values are not always correct.

I have a function GetCurrentCID as follows.



its fairly straight forward simply asks mIRC to evaluate $cid wich is of course the current connection id.

The following test dll function is used to test the GetCurrentCID function



As you may be able to tell calling the 'test' function from the dll will pop up a MessageBox showing the current cid. typically this is the cid thats active when you /dll ...

however the following code doesnt work properly. assume you have 2 connections with id's 1 and 2. if you call the following line in connection 1 you would think you get 2 in the MsgBox however you get 1

//scid 2 dll blah.dll test .

ive tried every possibly combination of /scid and /scon you can imagine including /scid 2 | /dll ... and so on. it works the same no matter if its in a script or on a cmd line (in a window).

the following code however works

//scid 2 echo -a $!cid

the only difference is when the 'command' portion is /dll ($dll and $dllcall do the same thing) it fails.

I know bugger all about how mirc deals with dll's, so ill ask this and ignore it if its not relevent.

Is it showing the $cid of the initial load of the dll ?

As in if while on cid 2 you do the first dll call, does it maybe show 2 from then on?

i havent really tried to say keep the dll loaded and retrieve the cid at various other times.

However im almost certain it may be an issue in the mapped file. I believe when mIRC evaluates the $cid from the mapped file it just uses whatever happenes to be the active (or last active) connection. However it should work /scid 2 dll .. should first change the connection then call the dll. Wich means 2 would be the active connection as for all of the other script (such as echo from above).

Without really having looked into the issue, I'd guess that this is just the way mIRC works: the Connection ID changes that your script performs, obviously only affect the CID for the running script, and not the active window overall. Therefore the CID must be local to the running script only, and mIRC apparently returns the global active CID (the one of the active window) when evaluating stuff for SendMessage calls, instead of taking the local CID value from the running script. That's not a bug, just a design decision (and, especially with stuff like whilefix.dll, probably a good one too)..

That said, why don't you just pass $cid to the DLL call in the first place?

as i remember that bug helped tremendously in preventing her from completing nicklust3 and how does $cid have anything to do with my dll lol

What do you mean by that?

The idea of /scon and /scid is to be able to call script within the context of a different connection. First it makes no sense to allow that to work for some script code say for example /echo and not for others such as /dll.

The idea of passing $cid could work in some cases but not all. Many times a function already expects several arguments adding another one and another and another just to workaround an issue would complicate each call to the dll.

Many people have come to me with various problems. Almost 80% of the time the problem is in thier usage. The pass the wrong argument or ommit one that was required. Requiring an additional argument would most likely lead to more problems.

Simple fact is it is a bug. It should be dealt with.

Using the mapped file was designed to allow a dll to communicate with mIRC by using its native scripting language. If it doesnt handle that language properly or work the same as it does from within mIRC script files then it isnt doing what it was designed for. Thats a bug

agreed

(emphasis mine)

Um.. where did you get this idea from? Sure, scripts will be evaluated just as from script files with this method - however, nowhere does the helpfile state that this will happen from within the context of the script currently being executed. The SendMessage stuff just might not be designed to work that way - you might disagree with that decision, but that still doesn't make it a bug, as far as I can see...

Edit: note that identifiers like $nick also don't work when using your method to evaluate identifiers, called from within eg an on TEXT event. If I understood you correctly, you would say that that should also work?

Following from my assumptions earlier - if mIRC were to temporarily replace the global CID whenever a script calls /scid (and restore the original when the script is done) , then a script that uses /scid as well as whilefix, would effectively change the active window that way. That wouldn't be pretty. Granted, I'm assuming quite a few things about mIRC's internals here..

Heres a simpler way to look at it. If you use mIRC script it should act/work/behave like mIRC script. Where the script was called is irrelevant. I also dont see anywhere in the help about how /scid and /scon work a certain way except when its called from a mapped file.

The idea behind the mapped file is fairly straight forward from its usage. No it doesnt state my words exactly but that is indeed what it does. If i tell mIRC to evaluate a line of script from the mapped file how could you not infer that that is indeed its job.

Bottom line is you have two scenarios of identical code $cid and /scid work one way when called from a script and totally different when evaluated from the mapped file. If you follow program flow the mapped file is no more than a sub routine.

/dll -> SendMessage -> script code

no different than an alias calling another alias etc.. There is no need to have two different scenarios with the multiserver script.

I never claimed the opposite - my point was that your assumption about the context for the evaluation was, indeed, an assumption. I'm not sure if you saw the edit I made to in last reply to you, but I guess you haven't - I would say that it proves that your assumption was wrong, and that the issue at stake here is the evaluation context; your problem with $cid is only a symptom in that regard.



Since SendMessage is an anonymous way of communicating with mIRC (the WM_MEVALUATE message itself does not tell mIRC where it came from, it could have been an external process sending the message!), I would say that your assumption is not "fair" in the sense that it does not logically imply how evaluation with SendMessage should behave. An external process would usually not want to execute from the context of the currently running script, after all.

However, mIRC could determine whether the SendMessage came from a DLL called by a script, by checking InSendMessage() when processing the WM_MEVALUATE message, and picking an evaluation context based on that - and in fact, that would make a nice feature suggestion.

The idea wasnt symantecs. A remote process most likely wouldnt care or use the cid at all. I dont think including the context within the dll itself would harm any code and can only improve it. The real problem is the sample i gave above

/scid 2 dll ....

from that line its clear i want the dll executed from withing the context of the cid 2. It isnt by chance becuase im explicitly forcing the change.

InSendMessage wouldnt work with PostMessage either nor does it garuntee that its called from within the context of mIRC's primary thread or a worker thread. Same affect with a remote process wich is a primary thread.

What mIRC should do is export its own API and allow the dll to call it. My point here is you can call it whatever you like but its completly reasonable to assume that code like /scid 1 then echo -a $cid would work and theres no reason to assume that they wouldnt work just because the code was called from within a mapped file.

The help file doesnt state that it does work but it doesnt state that it doesnt work. The only other tool you have to determine how it will work is /help /scid wich shows you how it works not how it doesnt work.

If you want to call it a feature suggestion thats fine. My take is the help file says $cid works a certain way and in some cases it doesnt hence the bug. I only wanted to get it mentioned ive already droped the project i was working on when i noticed it.

Fair enough.

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)

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.