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.

You know , just forget it. It is impossible to talk about issues here. Yer so hellbent on making me wrong you totally missed my question every time.

I will disconnect now before closing the status window. I think this should fix my issue. But, of course, I have no idea unless it arises again.

If mIRC were my project and I saw this post I would say to myself, "hmm maybe I should look into making sure connections close properly and mirc doesnt hold on to old, unused connection ids." But that's just me.

Have you simply tried a clean install of mIRC 6.35 ? Have you, then, stated any of this error ?

There's no way to refresh mIRC's connection IDs because it would defeat the object of having connection IDs. You would have to restart mIRC. But that won't fix anything because the error will inevitably happen again so it's not benefiting anyone to pretend it doesn't exist. As I already explained connection IDs refer to the Status Window and not the connection itself, meaning that disconnecting before closing a status window is entirely irrelevant to the problem.

As I have also said at least once in this thread, nobody else experiences this problem. If hundreds of thousands of people use an application and only a single person has a problem which is an error message from a scripted command, what's the logical first place to look for the cause? It doesn't mean that it's impossible that there's a problem with mIRC but you're apparently not even willing to take basic steps to debug your script. You won't display the script so we can find the error, won't edit the script to help you find the error, seemingly won't accept any kind of answer that doesn't involve mIRC being at fault.

Also, of course none returned 25, mIRC already keeps telling you that it doesn't exist.

Only 1% of the people that I know who use mIRC actually script. Out of that 1% maybe 5% at the most script for multi-network connections. So yeah, maybe it seems like noone else gets the issue, but if noone took their car out of the garage noone would have any car issues either.


lol Rock, quite right ...

I have presented all instances of scid in my script. And it has only happened once. Years ago I saw this error a number of times with a different script. If it happens again I will echo the scids for you.

As for basic steps to debug, I know every line of my script and what it does so I know it isn't getting connection 25 from me anywhere.

You obviously don't fully understand every single line in your scripts or you wouldn't be here with this problem.

Again, as mentioned, your a) stubbornness to not properly debug your script, b) refusal to try this in a clean mirc and c) unwillingness to actually show your script makes this a completely pointless 2 page conversation.

Are you just here to say "mIRC is wrong I'm right!" or do you actually want a solution? If you want a solution it seems logical to me that you would actually do what is suggested. I don't see how you think claiming you're all-knowing is productive when you're the one with the problem.

wow, mr angry guy ....


I'd have to reproduce the error to be able to echo it. Is that stubborness? I'd have to reproduce the error to try it in a clean mirc. I have shown all uses of scid in my script.

I never claimed to be all knowing, otherwise I wouldn't have asked the question about connection id cleanup.

And yes I do know what my scripts do, I wrote them. I'm thinking that messing around with disconnecting and reconnecting caused mirc to not delete data saying I had a connection open named 25.


And seriously, why do you approach all these issues with such attitude? What can you possibly learn if your mind is already made up as to what the answer is?

Hi,
To me it seem that the message you are getting in your status window "* No such connection id: 25" is a response from mirc to something happening in your script. Therefore it must be something to do with your script and not with mirc. Your script is asking for connection id 25 and mirc is telling you that it doesnt exist. Maybe I have missed the real problem here...

Yeah pretty much. Everyone is so defensive about mIRC. In my initial post where did I blame it all on mIRC and say mIRC is bugged and broken and generally sucks? I simply asked if there was a way to have mIRC clean up its connection list.

Ya know...



And yes, my code showed the issue with its /scid $cid when $cid = 25 and 25 doesn't exist.

But I don't see how my code would cause mIRC to not delete cid 25 from its list.

Is the numerical item in your list the cid value?
To state again what has been said before: cids aren't meant to be in any particular order. Open 3 cons, close 2 cons, open 1 con - the cid of the last one has not to be 4 (or 2). A cid is nothing but an unique ID per connection. (with cons I mean "status windows".)

I don't understand why you want to "clean up the cids" - this could break scripts who refer to a particular cid.

I found the fix for your issue. Feel free to try it.

Russel, the list was an example. The point would be to remove any cid's no longer in use, not remove any in use.

The second part answers the first. You're saying that there's a bug in mIRC that's causing it to return invalid values for $cid. What just about everyone else has been saying throughout this whole thread is that nobody else appears to have this problem and the more likely cause is a line in your script that you've missed. There isn't a 'clean up CIDs' feature in mIRC because there should be no need - if CIDs needed 'cleaning up' it would be a bug in mIRC to be fixed.

So something in my scripts caused mIRC to not know cid 25 was closed?

As I tried to point out earlier, CID's are assigned when a connection is established, but they are not unassigned when that connection is closed.
At some point a CID of 25 was created, and later on, that connection was closed. mIRC sees that there is no connection for CID 25 and returns the error you are getting.

CID's aren't unassigned yes.

At some point cid 25 was created, yes. And at some point cid 25 was closed, but somehow it slipped by mIRC because now, hypothetically now since I do not know how to recreate it, /scid $cid returns /scid 25. So mIRC says /scid 25 but there is no connection 25 open.

Ok, my question was answered. "No", there is no way to refresh mIRC's connection info.

Is it a mIRC bug? I personally don't care. Logic tell's me noone is perfect, not even Khaled. :p Experience tells me not many push mIRC as I do. Experience also tells me, just as my code that works with 99% if the people, there is always that 1% that finds the little bug you (I) missed or didnt think wuold be an issue. Granted it works fine on 99% of everyones machines, if it doesn't work on 100% then there is an error in your code/foundation. It's usually something small you didn't see or hoped noone would catch. This is my experience writing scripts for the public.

Ok, can I stress again, noone is perfect? Nor are we intended to be.

Thank You.

As others have said, no. It's not an issue of mirc not knowing that cid 25 was closed. Judging by the fact that thousands of scripters have been using $cid since it was introduced and it's only you who seems to have a problem with it, I would bet my right arm that it's something in your script going wrong, not mirc. And if I were you, I wouldn't even consider the possibility that the absence of similar reports is due to the fact that "not many push mirc as you do": frankly, this is a quite naive point of view, especially since you can't back up your claims.

This is quite confusing - if you don't care why did you bother creating and maintaining this thread? If you really want to get to the root of the problem, you should care, and you should also listen to what others are trying to tell you.

Nobody here is getting defensive on mirc but even if people show a tendency to dismiss a problem as a mirc bug in the absence of evidence, they are perfectly justified: if I had a penny for every bug report I've seen that turned out to be a script problem, I'd be rich.

Again, $cid never returns a value that does not correspond to an existing session. The sooner you come to terms with this, the sooner this thread will die (something long overdue).

Indeed.

Well my man, it did. I posted all instances of /scid in my script. They all use $cid, so I dont understand.

I didn't make this post to announce a bug or potential bug. I wanted to know if there was a way to clean up the cid list since /scid $cid was returning /scid 25 and cid 25 had been closed long before.

And yes, they were getting defensive. I asked a question but pretty much everyone ignored it to tell me it wasn't a mirc bug. I didn't ask if it was a mirc bug or even insinuate it was a bug, I asked if I could maintain the cid list.


$cid never returns a value that does not correspond to an existing session

So tell me then, where was the corresponding session? (it had been closed hours earlier by the way)

And I'm not the only one who has experienced this issue. I'm just the only who has posted about it here.

People ignored your question because it seems very likely that your question was based on a false premise (that $cid was reporting an invalid ID). If mIRC was reporting an invalid ID in $cid as you keep asserting then there wouldn't be a feature to reset it, it would be a bug that would have to be fixed. That is why everyone is setting your original question aside - because either way it's irrelevant to the situation. There's a bug to be fixed here somewhere, the only question is whether that bug is in mIRC or in your script. On that note, it seems you're the one who's getting defensive because you refuse to acknowledge the possibility that there's something wrong with your script even though I've already pointed out that the usage of /scid that you've posted so far is completely redundant and stems from a misunderstanding of how /scid works.

This isn't a witch hunt, but some of us do care if mIRC has a bug in it which is why it's useful to find the true cause of your issue. At this point however I think it's time to give up. I've repeated myself at least three times in this thread and you seem to have a mental block on understanding anything I say so I'm ready to write this off as a scripting error and leave you to deal with that since you clearly don't want any help in that area.

No, actually I would have been happy to use echo's around where I use scid but I didn't know how to duplicate the issue. But this has happened again now and I did put echos and recieved nothing in the window. Only the same error message.

We can't read your script from here, post relevant code.

Which proves that you've got another /scid somewhere in your code that you don't know about. You may be 'pushing mIRC more than most people' or not, but if this error wasn't directly from the /scid command then that wouldn't matter, there would be a lot of people seeing this if it were a mIRC bug unrelated to that command. Remember it needn't even be plaintext "scid" in your code, it could be a dynamic command call such as "%cmd blah blah" where the variable (or identifier) supplies the command. Or it could be a timer (I know you said you've checked but the timer could be intermittently created), or the command could be being provided to mIRC via DDE, COM, or a DLL. It could even be the result of an exploit in your code where someone is trying to execute that command remotely (although admittedy it's unlikely that they'd be using /scid).

i think you should call it a day lol!

Amen. I can't believe everyone is still trying to convince this guy who still doesn't get it and apparently never will.

Thanks starbucks. I guarantee I dont have another scid, inadvertantly or not besides ones that mirc may use in its own commands. i.e.: /server.

I do have the mIRC automatic rejoin on.

I won't post all my code. It is still under development and I like to keep it private before I make it public. Besides its almost 1000 lines spread over 4 files. However, I have shown all instances of scid and after this post and talking with friends I decided to remove most of those anyway. I used them out of concern about what mIRC would consider the active connection. Thank you for helping me understand that an event will only perform commands in that cid.

I do have a question about this disconnect event. Though this wasn't present with the initial error, it may be causing the recent one. As I said, this issue arises after multiple disconnects.


Point of this is that on this server the login account name is an email address, not your nick, so when it disconnects mIRC makes the nick $mnick, but $mnick is another nickname I have connected to a different network on the same mIRC. So it connects as "guest_$mnick".

So the status window stays open. This would mean even though the connection disconnected, the cid doesn't get deleted right? So the command /server with no switches will connect to the server on the existing connection I'm assuming.

Also, no timers. Only dll I have is dcx, no com object code in my scripts and I don't see how I would have an application trying to communicate with mIRC via DDE. I really doubt someone is trying to execute commands remotely through this mirc.

Thank You

Ya well I don't give up that easily.

You don't want or you can't ? What's the problem with understanding that nothing but a /scid command give you the error ?
I'm sure you've already tried a lot of things to debug your code, but really, you think that if there was such a bug in mirc it will display you THIS error message ?

You've said earlier :

It's funny, because this proove that there's a /scid that you're not aware of somewhere :')...

Also, another clue is that you've reproduced the error two time in a short period while others never reproduced it.