https://forums.mirc.com/showflat.php?Cat=...=true#Post30982 (So no one can tell me I didn't search :P)
But isn't there any way so you can handle multiple spaces in events?? (on INPUT, on TEXT)
I've tried a lot of things (replacing $chr(32) with $chr(160)) but nothing works in events. Maybe some one that knows a good script around??
i know one of the threads mentioned chr(160), becasue i got the idea from here afterall. Maybe you didn't search well enough. >:D
Maybe you could give me a hand?.. have searched, couldn't find it :tongue:
5 spaces = $str($chr(160), 5) etc
EDIT:
keep in mind that does not work for incoming text, only outgoing. I.e. you can't preserv an on text's sequencial spacing using that.
I know that, but that's not what i want, I know how to send multiple spaces, but what i want is:
on ^*:TEXT:*:#:{
echo $chan $timestamp < $+ $nick $+ > $replace($1-,$chr(32),$chr(160))
}
For instance, if someone SENDS me a line containing multiple spaces, i want to echo the multiple spaces, but so far, everything i tried, failed.. :@
Any ideas?
incase u didn't see it considering i posted it presumibly while you were replying
EDIT:
keep in mind that does not work for incoming text, only outgoing. I.e. you can't preserv an on text's sequencial spacing using that.
not pssible, thats like saying..
/test {
var %a = 1, %string = .a.b.c......d.e.f
while ($gettok(%string, %a, 46)) {
/set %t [ $+ [ %a ] ] $ifmatch
/inc %a
}
/echo -a %t4
}
we all know %t4 will echo d. Same goes with spaces. Mirc handles the $1, $2, ..., $n by seperating things by spaces. So if it sees two spaces and a null between them, why should it be counted? I mean if you had (underscores represent spaces)
hello_there____kingtomato
and had
on 1:TEXT:*:#: {
/echo -a $3
}
would you really want $3 to echo a null just so you can have multiple spaces?
if ($chr(32) $+ * iswm $1-) {
//echo -a $chr(32) $+ $1-
}
if (* $+ $chr(32) iswm $1-) {
//echo -a $1- $+ $chr(32)
}
if (* $+ $chr(32) $+ * iswm $1-) {
/tokenize 32 $1-
//echo -a $1 $2 $3 $4 $5
}
think that should work :tongue:
or you could try
var %space $replace($1-,$chr(32),_)
//echo -a $replace(%space,_,$chr(32))
would you really want $3 to echo a null just so you can have multiple spaces?
No, that wouldn't be a good solution either, it would be real messy, but i would like to see that mIRC gives an option to access the raw text that was send with the multiple spaces for example, but i think a have found a solution using RAWs. If it works i'll post it
var %space $replace($1-,$chr(32),_)
//echo -a $replace(%space,_,$chr(32))
I've tried that in a lot of different ways and it doesn't work. The problem is, that mIRC itself does a little cleanup on the message send, before it triggers a on TEXT event.
you can write a dll to make it work, but im sure theres an easier way :tongue:
Don't even try, raws don't respond to commands already responded and enterpreted by mirc. I do agree with you in a raw tho. Such as ever event could have a &raw variable.
on 1:TEXT:*:#: {
/echo -a This is the text sent $1-
/echo -a Raw text: $bvar(&raw, 1, $bvar(&raw, 1, 0)).text
}
the binary is able to hold consecutive spaces making it ultimatly the most reasonable choice.
First thing also doesn't do what i want
on 1:TEXT:*:#: {
/echo -a This is the text sent $1-
/echo -a Raw text: $bvar(&raw, 1, $bvar(&raw, 1, 0)).text
}
the binary is able to hold consecutive spaces making it ultimatly the most reasonable choice.
Yes that would be a good option, maybe post it in the future suggestions topic :P
I can almost definalty say it has been at one point in time. Besides the one person that matters is Khaled, and he frequents all boards. No need to post twice.
Alright
would you really want $3 to echo a null just so you can have multiple spaces?
Hell yeah, I'd love to see that. It would be completely easy to strip for those who didnt want that functionality (
var %a | !.echo -q $regsub($1-,/( +)/g,$chr(32),%a) | tokenize 32 %a), or a function could be built in for people who don't want to figure it out themselves. It's a simple solution (from the scripter's perspective) for what is, in my opinion, the biggest problem in mIRC scripting.
I still say a raw would be a better alternative than a $null. Or maybe an added system like $1, $2, ..., $N for the "regular" tokens, then $r1, $r2, ..., $rN for the "raw" and "true" token identifyers.
BTW, <--- 1000 >:D
Or just
/tokenize 32 $1- since /tokenize already kills consecutive tokens
For the sake of backwards compatibility though, I'd like to see a new identifier (like $rawtext or $fulltext or whatever) while having $N work the same way.
I'd like to see a new identifier (like $rawtext or $fulltext or whatever) while having $N work the same way
I'm with that
True, but if mIRC scripting supported null tokens would /tokenize still behave like that? I do agree that a new identifier or identifier set would be better for compatability since this could otherwise kill a lot of old scripts.
We're still forgetting yes we can have the consecutive spaces returned, but aliases still delimite just like the events do. All passing would have to be redone to accomidate the consecutive spaces. If you pass
(_ = space)
/myalias this_is_a______demo
You still get $4 as demo in the alias. But then again, you could also have the "$rawtext" in the aliase.
(I would prefer a $R1 $R2, etc variable tho. >:D)
Well that's whay I was thinking of - the entire language having null token support rather than just an exception for the on TEXT event.
I mean what is so wrong with using chr160? Its a good replacement, and would keep compatability.I do say that events like on text, on actions, etc should support multiple spaces, but then after that its up to you to keep the consecutive spaces in tact whether it be by means of $replace, or otherwise when passing to a alias or variable.
It will NOT keep compatibility. Char 160 is NOT a space. It is a non-standard extension to the ASCII table. Many fonts use it, yes, but not all. It is NOT standard.
well i tried several fonts and it alway echos this, for example
//echo -a a $+ $str($chr(160),10) $+ a
returns
a a
You tried several _windows_ fonts. Other OSes might not be the same. And remember, IRC != mIRC. People are using other OSes.
well as far as i know mirc is only compatable for windows, and this is a mirc forum :tongue: ,well if its not a mirc forum then i think the name should be changed from (mIRC Message Board)
I agree with codemastr - I think it is pointless sending characters to the room that programmes on other operating systems cannot understand. I have used $chr(160) for internal functions such as spacing information in dialogue listboxes as the TAB just puts an ugly square in place rather than shifting the text along a bit. Mind you I'd love to TAB, I just can't be bothered asking if anyone knows a way to do it.
[]1,1space[]4,1There's 5 spaces >:D
as i said this is a mirc message board, so why should i even consider other os's when mirc is only compatible for windows :tongue: ?
Because there are chat programs for other operating system, making any text sent over IRC subject to any circumstance. Why not make it universal >:D
speak english when speaking to illiterate people
[offtopic]
Just wanted everyone to know that 1K posts has been reached on this forum
[/offtopic]
But a $rawtext identifier or null token support would be the best solution IMO
What he means is that when you send a unique character to the chatroom only mIRC users will be able to see it. Users of other programmes will not. We all know mIRC dominates by far over anything else and all else added together but that is not to say that mIRC should 'go it alone'. There has to be some sort of conformity or at least discussion with the authors of other programmes and indeed IRCd's when wanting to commit to a feature or function that would otherwise stand alone.
ty watchdog.. couldn't have explained it better myself (or else i would have)
The issue has been resolved in mIRC 6.1. The message sent for just about any event is $mid($rawmsg,$calc($pos($rawmsg,$+($chr(32),:),1) +2)). Using single identifiers (including $replace() and $+()) can be done without loss of multiple spaces. The /set command doesn't lose them ether. So you can /set a %variable to something containing the original line of text with its spacing preserved. Of course, you can't /echo it because /echo loses the spaces. What you CAN do is use /loadbuf -e on a file containing only the name of the %variable you want to echo. It's a complicated process, but in the end it lets you echo things without losing the spaces and without putting in hard spaces.
i have found another way to do it without using /loadbuf (which wont wrap the same way as /echo -iN, ect.)
var %rm = $right($rawmsg,$+(-,$pos($rawmsg,:,2)))
bwrite temp.txt -1 $eval(%rm,0)
bread temp.txt 0 $lof(temp.txt) &temp
breplace &temp 32 160
tokenize 32 $replace($bvar(&temp,1-).text,$chr(160),$+(,$chr(32),))
write -c temp.txt
it basically sets a variable for the message, then /bwrites the variable to a file. write would probably also work. also, the $eval(%rm,0) should write the text '%rm' to the file, but instead it writes it's contents. if i try to /bwrite $rawmsg or just the variable, the spacing is lost.
after it is written, the file is read into memory and /breplace is used to replace all spaces with $chr(160). in turn, $chr(160) is turned into ^b^b$chr(32)^b^b (to preserve the spacing without using different characters in place of a space) and tokenized so that $1- will contain the original text but with extra spacing included.
the only downside is that any $chr(160)'s in the original text would be converted to a space, but since $chr(160) is commonly used as a replacement for $chr(32), i am willing to accept this.
The only differences in behavior between /loadbuf and /echo that I've noticed are that /loadbuf automatically scrolls to the bottom of the window, and that it doesn't keep track of your place properly, which indeed may be annoying enough to make your method worthwhile. /loadbuf wraps the same way, to my knowledge, if you use the -pi2 switches. Also, I see no reason why you cannot use $replace($right($rawmsg,$+(-,$pos($rawmsg,:,2))),$chr(32),$+(,$chr(32),)), and thus avoid reading/writing a file, and losing $chr(160).
But for me, I can accept no loss of information.
tokenize 32 $replace($right($rawmsg,$+(-,$pos($rawmsg,:,2))),$chr(32),$+(,$chr(32),))
that also works. i knew i shouldnt post the first solution i found ;/
The main problem with this approach is that it uses too many ^B pairs. Here's a test script to see what I mean:
alias text var %a | !.echo -q $regsub($right($rawmsg,- $+ $pos($rawmsg,:,2)),/(?<= )(?= )/g,,%a) | return %a
on *:text:*:?:{
tokenize 32 $replace($right($rawmsg,$+(-,$pos($rawmsg,:,2))),$chr(32),$+(,$chr(32),))
echo 2 -s $1-
echo 2 -s $replace($1-,$chr(2),<B>)
tokenize 32 $text
echo 3 -s $1-
echo 3 -s $replace($1-,$chr(2),<B>)
}Open a query window to yourself and type "hello<space><space><space><space>world" (and make sure there isn't any on *:input:?: interfering). Status will print:
[color:blue]hello world
hello<B><B> <B><B><B><B> <B><B><B><B> <B><B><B><B> <B><B>world[/color][color:green]
hello world
hello <B><B> <B><B> <B><B> world[/color]
Ie, the first method uses 16 ^B characters, while the second only 6. Apart from this, $text has the advantage that if you /tokenize it, the $* tokens will either contain the original words or the ^B pairs. In the above example, $1 will be "hello<B><B>" in the first case and "hello" in the second. This looks a lot cleaner and easier for scripts to handle.
your method is definitely better.
theres one small problem, though.. if text is preceded by a space (or multiple spaces), the first space gets chopped off.
edit: easily fixed by adding an extra set of ^b's at the beginning of the text.
Ah good point
Here's $text, adding a ^B pair at the beginning (only when necessary though):
alias text var %a | !.echo -q $regsub($right($rawmsg,- $+ $pos($rawmsg,:,2)),/(?<= [color:red]|^[/color])(?= )/g,,%a) | return %a
We can only hope that /echo will support &binvars someday.
/raw could also use &binvar support, allowing you to send any number of multi-spaced messages to the server. At least from there, we could script the rest.
Actually, we could get away using switches that cause /raw or /echo to evaluate things TWICE. Immediately after evaluation (and assuming they are on their own), $identifiers (thus $bvar.text) and %variables retain multiple spaces. It works perfectly for /loadbuf, aside from /loadbuf being generally annoying and unreasonable for this sort of thing.
There is a way.
You'll need a DLL, and a "trick" posted earlier.
As was said previously, $mid($rawmsg,$calc($pos($rawmsg,$+($chr(32),:),1) +2)) will contain the FULL content of a message, spaces and all. However, echoing it was always a problem. A DLL created by Saturn specifically for mIRC 6.16 allows you to echo it easily! (
URL here )
Although well documented for SENDING text, receiving required some searching, I found the best way to be the following:
on *:text:#:{
$dll(spaces.dll, echo, -t $chan $+(<,$nick,>) $mid($rawmsg,$calc($pos($rawmsg,$+($chr(32),:),1) +2))
halt
}
and it will echo EXACTLY what was said, spaces and all.
To SEND all your text, as is perfectly documented in the README, use the following:
on *:INPUT:#:{
if ((/* iswm $1) && (!$ctrlenter)) return
;gets the full, unmodified $1- from your editbox
var %input = $dll(spaces.dll, input, )
$dll(spaces.dll, send, PRIVMSG $target : $+ %input)
$dll(spaces.dll, echo, -aitc own $+(<,$me,>) %input)
halt
}
And as i'm sure you noticed, the DLL accepts all the flags echo accepts. From there you just need to edit the above for any type of input and text (except DCC chats since they're not supported by the DLL yet).
I hope this helps somebody because it solved all my problems and took me forever to find.