Forums Developers Multiple Spaces

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



not pssible, thats like saying..



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))

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

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

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

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'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.