Forums mIRC Help * No such connection id: 25

Hello.

I am wondering why this error keeps popping up in my active window.

* No such connection id: 25

I connect to different networks so I definitely have opened and close cid 25. I am wondering why this is repeating. I have checked all of my code, variables, ini files and hash tables, but there is nothing about cid 25. I have checked timers and have none going.

mIRC's ReTry feature is on and set to re-connect.

I know I can restart mIRC and it will be ok, but I'd prefer to be able to fix it if it arises.

Any suggestions?

Well clearly you're giving the /scid command a bad CID somewhere. You should search through your scripts for any usage of /scid and use /echo a debug message before each one. That way it should be which part of your code is causing the error and hopefully from there you can narrow the problem down.

But I do not have cid 25 saved anywhere and it is not hardcoded in /scid 25. I don't understand how my code would continue to try to make cid 25 active repeatedly with no timers activated and 25 not anywhere.

Many times I use /scid $cid. I do this in normal "on" events and raw events if I want to make sure that cid is active. But there is no cid 25 and it is not saved anywhere in my code.

if you have /scid $cid some where and your getting this message, and 25 doesn't exist, mIRC may have experienced a bug, who knows

when I type //Scid 25, i get as expected (and like you) :
* No such connection id: 25

This mean you're doing this too somewhere in your script, use echo to debug each line that contain "scid $cid" or something similar, or try to load each file of your script one by one on a clean install, but i'm sure it's not a problem with mIRC.

Is it possible that you may have had 25 connections (not necessarily simultaneously) which would generate the CID of 25.

Eg: Connect to servers 1 - 5 (creates 5 CID's)
Disconnect from servers 2 -4 (does NOT reduce number of CID''s)
Connect to servers 2,3, and 6 -10 (creates an additional 6 CID's, bringing the total to 11 CID's)

Now using the above example:

I have experienced this type of behaviour before, which is part of the reason I prefer to use scon rather than scid

Note: This is just a theory based on what I have seen in this topic and my own experience.

CID are connexion id, it's a number which just represent a connexion.I'm not sure about what you mean, this behavior is normal.

Well clearly it's coming from somewhere. Nobody else is getting this message so the chances of it being a bug in mIRC are around nil. Like I said, you should add debugging messages to each occurrence of /scid in your code and see where its coming from.

Sorry, guess I didn't make it clear.
If, after running a scenario like I posted, I went to use /scid 2
then it would come back with the same error message as described in this topic.

As I said, this is just a suggestion as to why the OP might be getting the error he is.

Yes, I guarantee that cid 25 was opened. That isn't the issue. The issue is that, with it closed, I am getting a mirc error saying "no such connection."

I'm thinking there was an error closing that connection so mIRC still thinks it's open?

I can put echo's on my /scid's but I don't know how to reproduce this error. Also, I guarantee I do not have 25 written everywhere and I only use /scid $cid. Since $cid is an mirc identifier I do not know what control I have over it.

Here is every scid instance I have. mIRC 6.35 by the way.



I don't see how my code could be causing the error. I can see how my code (i.e.: scid $cid) can, but the issue isn't fixable on my side. Or is it?

I don't understand why you're using /scid $cid anyway, since the script will always apply to the current connection by default. So unless there's other parts of code where you're changing the connection (by using /scid or /scon) those lines are redundant. Same goes for $scid($cid).

That still doesn't explain the error you're getting, but it certainly suggests maybe you're not fully understanding how /scid behaves and maybe there's more going on in your code than you realise.

There's also a glaring bracket mismatch in that code...

Also, if you started any /timers with that scid $cid command then they would continue to be sent when the connection closes and that could easily explain the problem.

I use scid to make the connection the active one. For instance let's say the user is connected to 5 different networks and is currently chatting on the 3rd network. If I use the command /window -c "Status Window", I want to be 100% sure it will close the correct connection.

You know, I wonder if I should /disconnect before closing the status window. I wonder if because I close the connection by closing the window, does it give mIRC a better chance of not deleting the connection.

Argv0, I didn't include the rest of the code as it wasn't relevant to the topic. I was showing the use of scid in my events.

Which is correct, as mIRC cannot send instructions to a connection that is closed.

This was exactly the point I was trying to get across earlier.

Connection ID's do not reset until mIRC exits. Opening and closing connections simply keeps increasing the number of CID's until mIRC exits.

So why is mIRC trying to connect to cid 25or make it active?

I'm curious, have you tried to restart mIRC? maybe you should and maybe the problem will go away. i know you stated that 'I know I can restart mIRC and it will be ok, but I'd prefer to be able to fix it if it arises.' but this may be the fix if you haven't tried it yet. after all when windows screws up what can you do? restart.

mIRC isn't. Your script is. This isn't a mIRC bug, that error message comes from the /scid command being used. If you don't believe me unload all your scripts and see if it happens. You'll find it doesn't.

A connection ID is associated with each Status Window - it doesn't matter if that window is connected to a server or not. As I tried to explain before, mIRC scripts are automatically switched to the appropriate connection ID in events - so in an on join event all commands will occur for the connection where you just joined a channel, in a raw event all commands will occur on the connection that the raw message just came from, and so on. The only time you need to use /scid $cid or $scid($cid) is if you have explicitly changed the connection to another one earlier within that peice of code. Again, the use of those commands with $cid doesn't explain the bug itself, but it is completely unnecessary unless there are more /scid commands that you haven't shown us.

Edit: Have you looped through with $scon(N) to list the connection IDs and see if any of them is 25? I strongly suspect that there won't be, but this should show us definitively one way or the other.

Yes I did loop through the scon's and checked each cid and none returned 25.

I dont care if I use /scid $cid. This ensures the active windows will, or will not be, targeted.

And if my script says /scid $cid, and the identifier $cid is provided by mIRC, and the cid mIRC gives me for $cid doesn't exist ... Sounds like an mIRC issue to me.

My question was whether there was a way to refresh what mIRC thinks are my connections without restarting mIRC or closing existing connections.

I do not believe there is a command or way to refresh the connections mIRC thinks it has. Can you please test a theory to see if restarting mIRC fixes the issue? That is the biggest solution to a lot of computer problems and I do not know why you seem to be refusing this bit of help / advise.

As I keep saying the use of /scid $cid most likely isn't the cause of the bug itself, it just shows a misunderstanding by the scripter in how it works and suggests there may be other issues arising from other incorrect uses of it.

There are hundreds of thousands of people using mIRC and thousands more using scripts which make use of $cid and /scid, the only person having this issue is you. Clearly that puts the likelihood of the problem being mIRC very low on the list and points squarely at an issue in your script. I've already told you how to verify the offending line (place echoes before each use of /scid to verify the values being passed to it) and you don't seem to have done that yet. I don't know what you expect us to do if you're not willing to help yourself and us to determine the true cause.