mIRC Home    About    Download    Register    News    Help

Print Thread
/close trigger ON CLOSE ? #191786 15/12/07 10:21 PM
Joined: Mar 2006
Posts: 22
R
rehinged Offline OP
Ameglian cow
OP Offline
Ameglian cow
R
Joined: Mar 2006
Posts: 22

Re: /close trigger ON CLOSE ? [Re: rehinged] #191812 16/12/07 07:11 AM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Then /window should trigger on open, /dialog -m and -x should trigger ON DIALOG, and I'm sure there are plenty more examples. Changing only /close would be inconsistent, and changing everything would probably break many scripts

It should also be noted that -x in /dialog explicitly states "without triggering any events", which is the standard behaviour.

Also, there is really no gain... Instead of calling /close and putting your script code in the on close event, you would make an alias to close the window and perform the on close events, which would also be called from the on close event if needed. This is how it's done now and it works quite well. If it ain't broke, why fix it?

Finally, there is still the issue of what would happen if you wanted to /close without triggering events (like /dialog -x's current behaviour)? There would be no way to express that.. and there are good reasons to want to.

Given that the benefits aren't very apparent, I personally don't see the need to break scripts that may not be compatible with this behaviour for functionality that is already available via different means.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: /close trigger ON CLOSE ? [Re: rehinged] #191879 17/12/07 12:19 PM
Joined: Mar 2006
Posts: 22
R
rehinged Offline OP
Ameglian cow
OP Offline
Ameglian cow
R
Joined: Mar 2006
Posts: 22
Simply because you know a way to solve such a scenario, doesn't mean that is enough. By which, I only mean to point out that this IS a consistency request, and not a "broke, so fix it".

Need I quote the help file?:
Code:
on 1:CLOSE:@:/echo -s Just closed $target custom window


That line has been there for years.

That event is going to be triggered when $target is closed.

The only difference between /close and that X is the involvement of GUI activity. The [X] is, effectively, calling an internal variety of /close... I wouldn't even be surprised if its roughly the same chunk of code.

I know a current scripted sollution to this. One does something like (off my head-top):

Code:
alias window.close {
  if ($window(@window)) { close -@ @window }
  unset %window.*
}
on *:close:@window: {
  window.close
}


And it's done.

I'd be interested to know what very good reasons you reference for NOT having ON CLOSE do what its name clearly suggests it does, though. I see not one good reason that /close should be named /close and not trigger the ON CLOSE event.

Script interpreters change all the time, and I see this change being not only minor (to function), but logical.

An -x exception switch would also be logical.