mIRC Home    About    Download    Register    News    Help

Print Thread
#36342 14/07/03 09:48 PM
Joined: Jun 2003
Posts: 67
D
Babel fish
OP Offline
Babel fish
D
Joined: Jun 2003
Posts: 67
on *:DIALOG:HLDR.Setup:SCLICK:11:{
did -a $dname 15 $+(%,HLDR.Server) $+ $chr(32)
}


it inserts the variable fine but i cant get it to insert the space


while (demi == nub) {
inc %skill
}
#36343 14/07/03 10:31 PM
Joined: May 2003
Posts: 215
Fjord artisan
Offline
Fjord artisan
Joined: May 2003
Posts: 215
mIRC autmatically strips spaces at the beginning or end of a line, use $chr(160).


- Jason
#36344 15/07/03 02:05 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
Using $chr(160) is a bad idea since it is not guaranteed to be a space in all fonts.

#36345 15/07/03 02:54 PM
Joined: Dec 2002
Posts: 127
F
Vogon poet
Offline
Vogon poet
F
Joined: Dec 2002
Posts: 127
after having read codemastr's response, i decided to find out for myself just which font's $chr(160) was not a 'space' in. i printed out a listing of my font's dir and went through each of them in charmap.exe to see the output of $chr(160) in that font. here are the results:

(note: i have winxp, and have only added maybe two fonts since i've had this machine. ymmv)

out of 167 total fonts, 112 had $chr(160) represented by a 'space'. now, that's only 67%, so it would seem that using $chr(160) as a space would only work for 2 in 3 (proportional, not actual) users. however, taking this one step further:

once you take the wingdings, the outlook fonts, system fonts and those not actually suitable for use by a human (they contain no letters), you have a total of 126 fonts. so, the previous 67% now becomes 89%, so 9 in 10 (proportional, not actual) users would be able to use $chr(160) as a space.

now, codemastr is right, using $chr(160) is not a guarantee, but hey, ~90% is a pretty safe bet in my book.

so, demitrix, i'd say go with lammkott's advice and use $chr(160)


------
deep down, i'm really superficial.
#36346 15/07/03 05:36 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
you're results are horribly biased though. Since when have IRC clients for other OSes ceased to exist? Mac, *nix, BeOS, Amiga, PalmOS, those are just some of the OSes that quickly come to mind that have IRC clients. Did you check the fonts available on those systems? Because if you didn't, all you proved is that your numbers hold for _Windows_ fonts, not fonts in general. So you've proven that 90% of Windows users have character 160 as a space. Now consider the fact that "real IRCers" are generally computer nerds and therefore have a tendency to play around with more than just Windows, so we'll just make a rough figure that 30% of IRCers are using non-Windows OSes. Until you can prove that the other OSes have fonts supporting character 160 as a space, you've only proven 60% of IRCers will actually be able to see it as a space.

Also there are other issues arising out of using 160. No one asked what the original poster was using it for, this can lead to big problems. For example consider this (somewhat unrealistic) example. He is making an IRC Services command popup thing. He has a configuration page where you can specify the command, ie "/msg nickserv" in his implementation he has chosen to force the user to include a space after it, which is reasonable since it is possible that you want the "identify" command to redirect to just "/" which would translate to "/identify" when the command is appended. Now he has made it so the user must type "/msg nickserv ". If that trailing space is a character 160, and he sends "/msg nickserv $+ $chr(160) $+ help" for example, all thats going to happen is the server is going to response with a no-such-nick error. So a character 160 won't work in all cases. If you intend to tell people to use 160, you should at least know what they are using it for since it my not work in their situation. His example (based on the name of the variable) makes it look like it might be something for sockets, in which case if the particular protocol says a trailing space is needed, a character 160 won't work.

#36347 15/07/03 06:14 PM
Joined: Dec 2002
Posts: 127
F
Vogon poet
Offline
Vogon poet
F
Joined: Dec 2002
Posts: 127
did you read the original post? this is a question about a dialog, a mirc specific feature. and since mirc is a windows-only irc client, the poster need only worry about _windows_ fonts.


------
deep down, i'm really superficial.
#36348 15/07/03 06:26 PM
Joined: Dec 2002
Posts: 2,809
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
Umm not true at all. What if the dialog is an "away system" and the specific control is the away message to be displayed in a channel? That will be displayed to anyone regardless of what clien they run. Again this goes back to my statement of "you should ask the original poster what exactly he/she is doing"

#36349 15/07/03 07:02 PM
Joined: Dec 2002
Posts: 127
F
Vogon poet
Offline
Vogon poet
F
Joined: Dec 2002
Posts: 127
too true. didn't think of that, i guess i just assumed that the poster was using $chr(160) for the same things i use it for: tab emulation and hard spacing for local echos.


------
deep down, i'm really superficial.
#36350 16/07/03 05:35 AM
Joined: Dec 2002
Posts: 1,321
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Dec 2002
Posts: 1,321
codemastr:

Your point is valid...but not in dialog scripting. The exit point (whenever the message is sent to the IRC server) is the correct place to $replace() 160's with 32's and let mIRC strip off spaces like it normally does. The dialog coding does not care what you use.

I do agree that you should NOT send out any 160's whatever. If spacing is important, using something like /play which will respect internal spacing. If you need to send out a blank line in a file, simply put a bold code on that line by itself. No IRC client has a problem with that and it's unprintable.

As far as the biasing is concerned, I think the 89% is an extremely low estimation of which fonts are used in Windows itself, thus used in the dialog. Most normal users (power users aside) don't even know HOW to change their Windows fonts, much less have any inclination to change them to those few fonts that use 160 for something other than a space. Most likely, those are specialized fonts NOT used for generic Windows text-based functionality, like menu bars, titlebars, dialogs, etc.

I would conservatively estimate that 99.9% (that's only 1 person in 1000) of all Windows users would be completely unaffected by using 160's in a dialog. And the ones who WOULD be affected would likely be power users who would know what the deal was with their fonts, choosing either to use or not use that script or that font...on purpose. I would also conservatively guess that the percentage would be much higher when you figure in how many of those 99.9% actually use mIRC and run a script that would be affected.


DALnet: #HelpDesk and #m[color:#FF0000]IR[color:#EEEE00]C
#36351 16/07/03 01:02 PM
Joined: Dec 2002
Posts: 127
F
Vogon poet
Offline
Vogon poet
F
Joined: Dec 2002
Posts: 127
after looking back in more detail as to which fonts mapped $chr(160) to a 'blank', these fonts were of note:

YES - Tahoma, Verdana, Times New Roman, Arial
NO - Bright, Hooge


------
deep down, i'm really superficial.

Link Copied to Clipboard