Forums Bug Reports Paste From Clipboard

Khaled, it wasn't about a DCC Chat Window.

I copy the whole whatsnew.txt to my clipboard, the I paste to a channel/query window. As per my previous post, when the multibyte... options enabled, it will send only a random amount of bytes 900 958.

Try it again?

Midori indicated that this also happened in a DCC chat window. However If I use debug.log I see the same thing in a channel/query window, mIRC is sending the whole of the whatsnew.txt file, except of course that I get disconnected for flooding, so I never see it arriving :-]

http://duckyshack.co.uk/u/2508/f53042331.jpg

There is an image of both the options settings and the font window settings that I'm using currently.

I've only tested this in a channel window, as did symphone (at which point I'd copy/paste his text in notepad2 and see how big it was) and it was my friend silverfire that said it was broken in DCC Chat window, I've told him to post here numerous times.. dunno why he hasn't.

Here are the combinations of the boxes and which ones break what function(s).

Key: MultibyteDisplay -> md, MultibyteEditbox -> me.

md = me = 1
Paste from ctrl+v is limited to 900-1000 bytes (random per files), non-english languages show up just fine in both the edit box and the display screen.

md = 1, me = 0
Paste from ctrl+v is completed, non-english languages show up while being typed in edit-box, but come out as ?-marks in the chat window.

me = 1, md = 0
Paste from ctrl+v is limited to 900-1000 bytes (random per file), non-english languages show up correctly in both edit-box and chat-window.

me = md = 0
Paste from ctrl+v is complete, non-english languages show up while being typed in edit-box but become ?-marks in chat window.

Changing these options while there is already non-english characters in the channel window doesn't change their display, only prohibits them from coming out correctly to the screen.


Also.. not sure what symphoney was doing, perhaps the built-in flood control, but he never flooded out when pasting >.>

As an addition to the above: whenever md = 0, pastes of another languages characters, say from MSN, do not appear in mIRC correctly.. say from ten lines of Japanese. but if you copy-paste one line of Japanese from any site or MSN, it still works.

Going back and checking this box, md = 1, causes pasting of Japanese from MSN to fail (?-marks) but pastes from a Shit-JIS site still seem to work (en-bulk-pasting).

Not sure why this happens, just wondering if it has any relation to things that might be breaking.

Thanks for the help. It looks like this issue may be related to a recently posted bug report. I had originally assumed that this was an editbox issue but it turned out to be a utf encoding limitation. This should now be fixed in the next version.

Wow.. so someone was telling me, this past weekend, that stuff from my RSS feed script wasn't being displayed in channel. So I took issue to blame the ircd for blocking spam from going through to all the users in the channel if I was an unvoiced (and higher) user in the channel (it seems to work fine if I'm voiced, hence blaming the ircd at first).

In an attempt to test this, I copied the text from the past screen (in buffer) and attempted to use /play -b p.txt to play from clipboard what I had just coppied (normal copy, not ctrl+copy) and, in a channel where I was without modes, it all played fine. Then I copied the text with ctrl+select for copying the color codes, and when I again used /play -b p.txt, it stopped after a seemingly pre-selected number of bytes.

Doing it a few times... (all cases had colors, underlines, and were done with /play -b p.txt)
930 bytes (no unicode)
901 bytes (some unicode chars too)
922 bytes (some unicode)
926 bytes (no unicode)

--Not pasting what I copy & pasted as it contains a lot of website links (being an RSS feed and all) and would prolly violate some rule. But I can make a screeny of what I see on my end if needed.

And, once more for prosperity I did the /play -b p.txt on normal copied text (without control codes) and it all played just fine.

Although my script uses a while loop, I was testing with /play and found that bug.. figured I'd post that here as well ;P

P.S. Thanks for fixing that first bug, was actually looking for it in 3.0, but I guess 3.1 (or w/e) will work fine too!


Edit:: Just found out is in indeed the ircd limiting spam in general, oper or otherwise, if the person has no modes in a channel, from a while loop.. but the /play bug still exists anyhow.

Since this bug is probably extremely irritating (at least it is for me, and I don't see why it wouldn't be for everyone else) for those who use unicode and paste many lines of text, is there any chance of seeing a version of mIRC with this fixed sooner than in 5 months when the next version of mIRC is released?

I know it's a long shot, but I thought I'd ask.