Forums Bug Reports mirc & colors

hey,
i find some irregularities in mirc 6.35 textcolors and reported it
there:

http://loudjupp.kicks-ass.net/viewtopic.php?f=8&t=7


eof

Jupp

This doesn't belong in the bug reports section at all. What if (for whatever reason) I want to send a message of white text on white background? (the same can be done here in your browser) I don't want mIRC to decide that I can't do that. Your IRC-Client has taken that option away from the user. Also, Italic has been suggested several times.

i meant mainly this differences between received & sended colorcodes . . .

What exactly *are* you reporting? The post you linked to isn't very clear.

If you're saying the following are bugs:

Then,

1. Of course mIRC can display white text on white backgrounds.. it's up to the user, not mIRC, as to what colour to use for the background and foreground. This is a feature. You can script your client to avoid using certain background colour codes in an ON TEXT event, if you'd like.

2. Of course text will be unreadable if colour codes are not set right.. again, the responsibility is on the user, not mIRC, to send properly encoded text.

3. What does "colorlike" mean? mIRC doesn't need to check for this.. again, colour codes are just data to be interpreted by the client.. mIRC shouldn't care what the data is when it's being sent, that's for the other end to worry about.

okay,

1. it's a surprise for me if u see it as a feature to write same colors to same backgrounds.

2. is 99% of all user doesn't know exactly what they are sending via different scripting.

3. validate outgoing textlines would be nice to prevent the point 2 users from sending double or triple code or useless codesettings.


but this are NOT Bugs (only suggestions),
i meant this different interpretation between sended and received colorcodes - this could be really a bug . . .

cheers

Jupp

1. People often use (in local scripts) colour codes to emulate spacing in mIRC. It's also commonly used in ASCII art popups/scripts to create a fill background. The ability to select the same bg as fg exists for other reasons too, but it exists by design. There is no reason for mIRC to police what colour codes people should use.

2. I'm not sure what you mean, but scripts should have nothing to do with this. If the script is responsible for invalid colours codes, the script needs to be fixed, not mIRC.

3. Nothing is "useless". Again, mIRC has no place policing users as to how colour codes should be used. Data is data, mIRC simply interprets it. A common alias is: "return $str($+($chr(22),$chr(22),$chr(32)),$$1)"-- this emulates multiple spaces by "abusing" mIRC's interpretation of control codes. If mIRC cleaned up whatever it deemed "invalid", uses like these would break. mIRC doesn't know what the intention of the user is, so it can't "prevent" anything.

What do you mean by a different interpretation of sent and received codes? mIRC parses colour codes the same regardless if they are incoming or outgoing. This is consistent. The other program you showed is the one that is being inconsistent.

look at the pics: Example mIRC receive/send colortext

theres two screenshots of mirc

1st is a received text froma an other user - mirc interpreted it to one single word with dark background . . .

*i had copied this text from a tcp-rawdump & paste it into mircs editfield and send this text 3 times. . .

this sendet text is interpreted different (dark background from this word of)


greetings
Jupp

Let me try and put it another way for you Jupp.

All of these concerns of yours have nothing to do with mirc. It has to do with the user who decides to write scripts for mirc.

The individual scripter is responsible for their own scripts.

If you decide to write a coloured theme on mIRC then you are resonsible to make sure it works correctly. Not mIRC or Khaled. mIRC is responsible to look correct at default settings. Once you change those, then the responsibility is yours.

okay,
then my final conclusion is:

it is the scripters if mirc interpreteting same text different

Sorry, I'm being pedantic, but you need to get this right:

mIRC is interpreting the same text in the same way, always.

For a specific set of control codes, mIRC always and deterministically returns the same result every time.

Example: if you send Ctrl+K 0 as the foreground colour, mIRC will always use Ctrl+K 0 as the foreground colour. If you send this code as the background colour, mIRC will always use this code as the background colour.

It interprets the codes exactly as they're sent.

It seems the alternate IRC client you showed does not support background colours, or perhaps it supports them contextually. This is that IRC client's fault, not mIRC. mIRC will unconditionally show the background/foreground colours, regardless if it makes it "more difficult" to read. This is not a bug, it is by design. This is the part you got right (or probably meant to say): it's for scripts to deal with this behaviour, not mIRC.

my software acting like i need it - and the colorparser/stripcode works very well - but don't let us talk about my software - let's talk about mIRC.

i won't annoy you here with this stuff but it is only an advice to check mIRC 6.35 really in that way before you say that.

my evaluation exceeding so i have no longer time to spend for mIRC.

To sum up your point of view, mIRC create a way (rules) to add color and such in text and perfectly respect this rules, your client isn't respecting this rules (since it act like you need it) so it's a mIRC bug ?

i have to excuse me for the difficulties, you are all right here!
i found a wrong recognition of the ctrl-o char here - so thats my own fault.