|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
OP
Fjord artisan
Joined: Dec 2002
Posts: 580 |
I was disappointed to know this bug hasn't been fixed. I reported some time ago...
Open two servers (status windows). Open a query on one and a custom window and the other, for the sake of example.
$window(*, 1) == Status Window
$window(*, 2) == First CID's window
$window(*, 3) == Second CID's window
$window(*, 4) == $null
Since $window(*, x) is suppose to account for all MDI windows of any type, shouldn't there be another "Status Window"?
|
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
$window() is session-specific, except when it comes to custom windows. If anything could be called a bug, it's the fact that $window(*,N) called from within a certain session lists the custom windows of all the other sessions too.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
|
Joined: Jul 2003
Posts: 655
Fjord artisan
|
|
Fjord artisan
Joined: Jul 2003
Posts: 655 |
When thinking about custom windows, although they are opened specifically within a session and will close if that session is closed, they are infact not session specific windows. You can not have two custom windows of the same name, on different sessions.
Because of this, i believe, as the bahavior indicates, that custom windows are treated as global windows much the same as stranded windows are when a session is closed.
The behavior of $window seems to be acting correctly in regards this this concept. Perhaps is it the behavior of custom windows themself that could be improved in this case, to properly reflect there session independant nature.
"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
|
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
|
OP
Fjord artisan
Joined: Dec 2002
Posts: 580 |
I agree that $window(n) should be session specific, but I feel $window(*, n) should report every MDI child window regradless of CID. Including crap like "Notify List", which it does already (except for status windows). I'd prefer $window(*, n) not be CID specific, unless CID becomes a an additional search paramerter of $window, or else it would need to be paired with some sort of $scon().$window (and there is the "no bracket" problem here)... Here's why, write a nice mIRC script that scans through all MDI children window, looking for a matching .hwnd value and when found return the CID of the window. I need the script to work using C++ and SendMeassge for commands and evaluations (without any script aliases being used).
// mEval and mEvalCid and functions that send the messages
// Both functions work like printf does
// To do mEvalCid, I needed to send an mIRC command like this
// "scid %d | set %%~DLL~Eval %s"
// Then evaluate "%~DLL~Eval" with the mIRC evaluate window message.
//
// Due to the bug, this function will not work with Status Windows
UINT GetCID(HWND hWin)
{
HWND hwnd;
int index = 1;
hwnd = AtoH(mEval("$window(*, %ld).hwnd", index));
while (hwnd) {
if (hwnd == hWin)
return AtoI(mEval("$window(*, %ld).cid", index));
index++;
hwnd = AtoH(mEval("$window(*, %ld).hwnd", index));
}
return 0;
}
//
// This one specifically searches for only status window CID's
UINT GetStatusCID(HWND hWin)
{
HWND hwnd;
int index = 1;
int cid = AtoI(mEval("$scon(%ld)", index));
while (cid > 0) {
hwnd = AtoH(mEvalCid(cid, "$window(Status Window).hwnd"));
if (hwnd == hWin) return cid;
index++;
cid = AtoI(mEval("$scon(%ld)", index));
}
return 0;
}
|
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
|
OP
Fjord artisan
Joined: Dec 2002
Posts: 580 |
You can not have two custom windows of the same name, on different sessions. This sucks and I think should be changed too. Two custom windows of the same name and different CID should be able to exist. Making $window(n) completely CID specific, would allow this. On the flip side, adding all status windows to $window(*, n) would be approprate to not lose functionality.
|
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
You can not have two custom windows of the same name, on different sessions. You are right it does suck, however what ya going to do, im sure there are alot of scripts that rely on a fact a single custom window can exist between sessions, so they can use it on all of them. i got around it once using non printable characters (well they printed little boxes) but they all looked the same, so it was like @[][][] blah blah and @[][][] blah blah but the boxes were $chr(1-31) (or something around that) Question : Are dcc chat/get/sends window session specific?
|
|
|
|
|
Joined: Jul 2003
Posts: 655
Fjord artisan
|
|
Fjord artisan
Joined: Jul 2003
Posts: 655 |
Question : Are dcc chat/get/sends window session specific? No, i believe they are session independant, and i think custom windows should act in the same manner that these do. While i am not sure i like the idea of multiple custom windows of the same name, it would be an improvement if custom windows were treated in the same fashion that chat/get/send windows are. Maybe a flag for the window command could be added that would, when used, create a session specific custom window. This custom window would only be manipulated by events/aliases/scripts that are called from the occumpanying session, unless scon scid etc is used. And, as a session specific window, it could then allow other custom windows of the same name to be created, either session specific to other sessions, or a session independant one (limit of 1 independant and 1 per session dependant), where the order of processing first checks session specific custom windows, and finally uses the session independant window if not previously matched to a session specific window.... ok, going on a bit now, but you get the idea... i think this would avoid breaking existing scripts, while improving on the behavior of custom windows and making them a little more uniform to other session independant windows. As for $window, it should remain session specific, and should infact list all session dependant windows followed by all session independant windows. (which is how is currently works). The above mentioned idea would, if implemented correctly into a script, avoid the problem of listing all custom windows.
"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
|
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
|
OP
Fjord artisan
Joined: Dec 2002
Posts: 580 |
Maybe a flag for the window command could be added that would, when used, create a session specific custom window. As for $window, it should remain session specific, and should infact list all session dependant windows followed by all session independant windows. (which is how is currently works). So what would $window report? Every session specific and all globals too? What if a global and session specific custom window have the same name? I think $window should have the ability to see all MDI children as a whole AND be session specific. I see no better way than keeping $window(n) session specific and $window(*, n) be completely global OR by adding a CID parameter to $window(CID, *, n). Or just make my life simpler (and save this debate?) by giving me $hwnd(hwnd).cid (Or by adding a SetProp(hwnd, "CID", cid) internal to the mIRC application), which is all I really want from $window (but need a major hack to get), for my DLL based treeview switchbar. As of now I use crappy hacks like the one I posted ealier, which I just realized, has bugs in it even now. Support for CID handling in DLL's is difficult to say the least. BTW, appending $network or $server to a custom window name is another "clean" work around for no duplicate names problem.
|
|
|
|
|
Joined: Jul 2003
Posts: 655
Fjord artisan
|
|
Fjord artisan
Joined: Jul 2003
Posts: 655 |
So what would $window report? Every session specific and all globals too? What if a global and session specific custom window have the same name? At first glance this is contradictive and completely void, however i suppose you mean every session for that cid, not every session specific mdi for all sessions. Regardless, two windows of the same name is not an issue, this can already occur (sends/gets/chats). For custom windows specifically you could just use the .cid prop to see if the window is one create to be session specific or the global one (for your purposes of determining where to place it). Which is already viable since it will return the cid of the session group it is under. Possibly a [,C] optional parimatre in the $window identifier would also be of use, where c = 0 would show all mdi children (in order, grouped by cid, then show stranded windows), c = 1 would act as it does now (active session followed by global), c = 2 just the active session no global / stranded windows. and i guess c = 3 for the latter. As a further note, maybe session independant custom windows should not be nested in the cid the command was used in, maybe they could created and remain outside, as a stranded window. Shrug, i just think creating a fundamental difference between $window(n) and $window(*,n) would create inconsistancy and confuse scripters. And improving on the behavior and relationship between $window and custom windows seems like a much more viable and useful solution.
"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
|
|
|
|
|
Joined: Apr 2004
Posts: 759
Hoopy frood
|
|
Hoopy frood
Joined: Apr 2004
Posts: 759 |
i think it would work alot better if another parameter was added to wildmatching $window.
$window(*,N[,CID|GLOBAL]) where cid returns the Nth window on that connection. And global would list Custum windows, mIRC's own dialogs (Color section, Options, Remote, Finger etc) , etcetera.
$maybe
|
|
|
|
|
