mIRC Home    About    Download    Register    News    Help

Print Thread
Connection Id (cid) and code blocks question. #265744 12/07/19 06:06 AM
Joined: Apr 2018
Posts: 83
E
Erasimus Offline OP
Babel fish
OP Offline
Babel fish
E
Joined: Apr 2018
Posts: 83
I am lead to believe that a code block (could be a raw numerical handler) can obtain the cid of the connection that called it though the use of $cid.

What about an alias that is called from within that original block ? Does it inherit the cid or does it have to be passed as a parameter ?

I would also ask the same thing particularly regarding dialog code blocks. I know the call to the dialog gets the cid of the connection that it was called from ($cid again), but what about the dialog handlers (the blocks with :sclick:<id number>:{ etc. ) ?

I have a few dialogs that I have converted so that you can call the dialog up from one connection, deal with that connections info, make changes etc., then switch (I use a drop down to select the service from), get it's cid from a look up in a hash table, then try to work from that. Do I specifically have to pass something to the mouse click handlers etc to maintain using that cid or is it inherited from the dialog ?

I forgot to mention, the dialogs are modeless.

On a related matter, why are cids not simply 1,2,3,4 ? I'm seeing ones like 1, 277, 5107, 5323 during 4 different simultaneous server connects.

Re: Connection Id (cid) and code blocks question. [Re: Erasimus] #265746 12/07/19 11:43 AM
Joined: Feb 2003
Posts: 2,642
Raccoon Offline
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,642
CIDs and WIDs live in the same global namespace, which is just an incriminating unique resource number, also used by several other resources (unknown). That's why they become large so quickly.

The value that $cid returns is inherited by all aliases, etc, called within an event.

I would presume, without testing, that the $cid returned by a modeless dialog event will be whichever $cid happens to be active. I would further presume that the $cid will represent the dialog's "parent" at the time of the dialog event in question, if the dialog had been assigned a parent (-a switch?), but this is all worth testing for yourself.

Rather than looking up a connection's CID, you can simply request the value via $scon(N).cid on demand.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Re: Connection Id (cid) and code blocks question. [Re: Raccoon] #265752 12/07/19 08:57 PM
Joined: Apr 2018
Posts: 83
E
Erasimus Offline OP
Babel fish
OP Offline
Babel fish
E
Joined: Apr 2018
Posts: 83
Originally Posted by Raccoon

The value that $cid returns is inherited by all aliases, etc, called within an event.

I would presume, without testing, that the $cid returned by a modeless dialog event will be whichever $cid happens to be active. I would further presume that the $cid will represent the dialog's "parent" at the time of the dialog event in question, if the dialog had been assigned a parent (-a switch?), but this is all worth testing for yourself.

Rather than looking up a connection's CID, you can simply request the value via $scon(N).cid on demand.


Ok, thanks for the info and I will carry out tests. I assumed the inheritance due to the single thread in mIRC, but needed it confirmed.

Between asking the question and getting your answer, I've been doing a lot of thinking about this and found something that will probably help me out.

Originally the script was designed for a single connection to a specific server There were a significant number of global variables to hold state information and data relevant to the connection, which changed when the server's IRCd was updated (unreal to inspircd). Alongside that ran a separate script for the other connections that was rather minimalistic.

More and more I found that the small script was calling aliases within the bigger initial script, so I decided to amalgamate the 2 scripts, and it will eventually have a connect manager built into it. Rather than making the global variable count double/triple/... (extremely impractical) I decide to make the jump to Hash Tables - never done that before now.

Each server is given a small shortname (3-5 characters) that is used to access the data for each connection, sometimes with suffixes added to the end of that shortname or in conjunction with a code for an object type - example for idlerpg games (possibility of 2 games on any server): the table uses the shortname code + 'C' + GameNumber for the channel name and shortname code + 'B' + GameNumber for the Bot name, and so on.

It's in that area where things start to get complicated. Turns out that 3 servers I connect to have IRPG channels, all called the same name, and 2 of them share the same Bot name, so ensuring I get the correct cid is important. I still use a global variable holding the channel names which is used with On Join code, and is especially good since $addtok will not enter a duplicate - keeps the data size down and probably faster for the channel name checking
Code
 On *:JOIN:%IRPGChannels: { 

I already pass the shortname on to various aliases so decided to create 2 new tables. One called shortname which has the connection id as the item name and the shortname as the data. The other, ConnId, has this reversed: shortname forms the item name, cid the data.

This allows any section of code to look up one or the other dependant upon the info it can get. If it uses the cid it can get the shortname etc. this also removes the need for those multiple if ($server == <whatever>) and makes the whole thing rather dynamic.

The tables are populated as each server is connected using On Logon, and the relevent data removed at On Disconnect. These tables also provide me with the chance to check if a sever is connected or inactive, the inactive one(s) having features in the dialogs disabled if inactive.

It all appears to work at this point, but testing and refining continues.