mIRC Home    About    Download    Register    News    Help

Print Thread
#234808 10/11/11 11:12 PM
Joined: Jul 2006
Posts: 3,961
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,961
When you use control to copy the control codes, if you start copying from a colored text, mirc remove the padding 0 of the color and add a control+o at the end.
Code:
//echo -a a $chr(3) $+ 07text
start copying from (assuming color 7 is orange) text and paste the result in your editbox, the color is 7 and not 07 and you should be able to see the control+o


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #234809 11/11/11 02:09 AM
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
So what's the problem, exactly? 07 and 7 are the same color, and I think it's a good idea to put a ctrl+O on the end of the copied text.

drum #234810 11/11/11 02:12 AM
Joined: Jul 2006
Posts: 3,961
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,961
The problem is that it works correctly if you try to copy from the beginning: the color is correctly 07, not 7, and there's no control+o at the end.
7 and 07 are not the same, if the text has been entered with 07, it is expected to see 07, not 7 and vice versa, fact that it correctly show 07 and no control+o if you copy the whole line shows there's a problem somewhere

Last edited by Wims; 11/11/11 02:14 AM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #234811 11/11/11 04:35 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
7 and 07 are the same, they both represent the same color. One is simply padded. mIRC is using the simplified syntax of the current colour that begins the copied snippet because it does not have the full context for the initial color code. This seems intentional to me.

You should really have tested this with better inputs, you would realize that simplifying to 7 does NOT lead to potential bugs-- if the text starts with a number, mIRC intelligently uses 07 instead:

//echo -a $chr(3) $+ 07 $+ 7654321

Doesn't seem like a bug, just yet another one of your odd expectations. mIRC should have the right to simplify copied control codes wherever it can. The Ctrl+O is certainly intentional. Why does mIRC have to return exactly what was in the buffer when you are only copying a snippet of the line? mIRC is rebuilding part of the line here, specifically the part with the color code (because it was not copied, it was reconstructed).

The difference between copying the text and the whole line is that your copying caret begins after the color code in the buffer. It would seem impossible to tell mIRC that you want to copy an invisible character in the buffer, so mIRC assumes you are pointing to the location AFTER the color code. This is a fair assumption. Especially since this would be the same as if you copied from the '5' or the '4' in the above example. In other words, copying from the "7" is equivalent to copying from the "6", "5", "4", etc.. The behaviour is consistent with copying text after a code was inserted. mIRC only knows that the current color is $chr(3) $+ 7, it doesn't know (or need to know) the exact syntax used to begin that color sequence. Yes, the two copy behaviours might differ, but that doesn't mean one is a bug, it just means there are two separate cases depending on context. Each one works consistently and produces correct valid results, what's the problem this time? Is there an actual scenario where this doesn't copy the right COLOR that you wanted? If it's copying the right color but in a different form, it's still the right color, and mIRC is still correct.

If you're asking for mIRC to optimize the copying routines so that copying from a character that immediately follows a color code would copy the preceding color code byte sequence as well (rather than reconstructing it as it would for any character following it), that would be a feature suggestion, not a bug report. As it stands, mIRC seems to work as I've described above, which seems intentional, correct, and consistent.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #234812 11/11/11 04:58 AM
Joined: Jul 2006
Posts: 3,961
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,961
Calm down, it just looks strange to have 07 in one case and 7 in another, I never said anything about what I think mIRC should or shouldn't do or that it is was a bug or that mIRC was incorrect, I just thought that the inconsistency should be reported.
Same for the control+o, it might be intentional but why not always putting it then?


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #234813 11/11/11 07:53 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Please don't report every "inconsistency" you come across immediately. Doing some research into why helps narrow down reports to the ones that actually *are* bugs. The best way to go about this is to assume that when you come across an odd behaviour, YOU are the one who is wrong until you can prove otherwise. Avoiding noise in the forum makes life easier for everybody, crying wolf everytime you see some random odd behaviour makes the real reports harder to follow.

The ctrl+o is placed for the exact same reason that the ctrl+k is reconstructed. If mIRC has the full line, it doesn't need to reconstruct the control codes. If only a partial copy is done within existing control codes, mIRC will insert ctrl+o at the end, that's just how it was decided to be implemented. If you have issue with the current behaviour, you should ask for a feature suggestion. The fact that mIRC inserts a ctrl+o is not a bug.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Wims #234814 11/11/11 11:19 AM
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
I'd have to agree with argv0. This is not a bug. There are definite reasons for the way it works and argv0 has pointed them out. If it's working as intended, then it's not a bug. If you disagree with how it's working, then it's a feature request. Khaled uses the bug reporting forum as a kind of bug tracker (unless he has another bug tracker we don't know about) and when it gets filled with things that aren't bugs, it makes it more difficult for him to determine which posts are bugs that need fixed and which ones are not.


Invision Support
#Invision on irc.irchighway.net
argv0 #234817 11/11/11 04:39 PM
Joined: Jul 2006
Posts: 3,961
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,961
Actually I reported the problem for someone else, so the inconsistency might be recognized as a potential problem by others people too.
Quote:
Doing some research into why helps narrow down reports to the ones that actually *are* bugs. The best way to go about this is to assume that when you come across an odd behaviour, YOU are the one who is wrong until you can prove otherwise.
That's what I do everytime. I'm sorry, I didn't assume I was wrong when I saw mIRC was sometimes using 7, sometimes 07. Anyway, there was no way to say if it was wrong or not.
You are certainly right about the control+o thing but the color problem is still something to consider so the report was worth it, and come on, who is making noise about every suggestions/bugs on this forum if not you?


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #234818 11/11/11 06:07 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
I'd advise you to simply ignore people who expect some kind of proof or propose that you undertake any other arbitrary burden before reporting something you consider a bug. Obviously common-sense is in order and a little investigation never hurts, but to demand absurd and frankly unattainable levels of rigour of everyone who thinks they've found a bug would only serve to create a chilling effect on bug reports and consequently harm the application as a whole.

In short: if you think it's a bug, report it. Don't worry about satisfying anyone else's criteria of a valid bug report.


Spelling mistakes, grammatical errors, and stupid comments are intentional.

Link Copied to Clipboard