Forums Scripts & Popups Script doesn't work for the person that requested

Not stable? It returns the directory the executing script is in - that's all. It doesn't change unless you move the script to a new directory and then reload it.

As for $mircdir not supporting paths with spaces, you can see that it clearly does return paths with spaces by installing mIRC to a directory with spaces in it and then typing //echo -a $mircdir

The problem you're getting is when you try to pass a file/directory to certain commands without enclosing them in double quotes.

If a command has just one parameter (a file), or a command has only one file paramater and that parameter is last, then it's perfectly fine to pass a path without spaces. For example:

These are all fine:
/run c:\documents and settings
/splay c:\documents and settings\3.wav
/splay -p c:\documents and settings\x.mp3

But this is not:
/filter -ff c:\documents and settings\x.txt c:\documents and settings\y.txt

The reason for this is that mIRC has no idea where the first file ends. This is why you have to enclose it in quotes:

/filter -ff "c:\documents and settings\x.txt" "c:\documents and settings\y.txt"

You can do this by doing:

$+(",<file>,")
" $+ <file> $+ "
or $qt(<file>) (only added recently)

Identifiers don't suffer from the same problem because all parameters are separated by commas, so mIRC has no trouble working out filenames.

If this seems unclear, feel free to ask and I can try to clarify some points.

If you get errors stating that C:/... .../, then you can use $qt() to put it in quotation marks, which will resolve the error.
Edit: Hixxy beat me to it

Yeah I used quotes and it does that, but for some mdx things it doesnt. It's weird. I chose to call the file as I mentioned and haven't seen any errors.

As for $scriptdir, I've seen it change from going to my main directory "SoulFly_v1" that mirc.exe is in, to my SoulFly folder. I just wanted it to return the same root directory everytime without hassles.

It does do that as long as you don't move and reload your script.

If I use an identifier to point to a specific place I want to make sure it ALWAYS points to where I want it. I mean, Im giving anyone this code to use. People do straaaaange things with it. Running from the desktop is just one of the mildest. It's my opinion, my preference, since it will not provide me with the exact same path EVERY SINGLE TIME I go to it I cannot use it. Make sense?

Remember that spaces require an identifier (or quotes) to work. If you try something such as:

/write $mircdir\script\script.txt hello

And $mircdir == c:\Program Files\mIRC, then you will have problems.

However, if you use it in an identifier, such as:

//echo -a $read($mircdir\script\script.txt,1)

And $mircdir is still == c:\Program Files\mIRC, then it will work properly. For the first example, you'd need $qt() or similar methods of adding quotes. As long as you follow that rule, it will never give you problems with spaces.

I have always used $scriptdir and my scripts can be moved anywhere on anyone's computer and it has never been unstable. Remember that the rule for spaces is the same as with $mircdir.

If you still have issues with it not working properly, I'd suggest posting example code here and see if someone finds something that was done incorrectly, because it should work all of the time if you're following the rules mentioned above.

$mircdir is not static either. Someone moves mIRC to a different location and it changes..

If you use completely static directories by hardcoding them into your script (ie. you use /write "c:\program files\mirc\x.txt" a) then that's just the worst way possible. If I install mIRC to c:\mirc\, then I'm going to want settings stored somewhere around there. Not in an entirely different folder.

Thanks for all your ideas and Im sorry this got off topic. As I said, to point to a file in a subdirectory, I have been using:

/SubDir/filename.ext

Haven't had any issues so far. *crosses fingers*

If it's just for yourself, that's an okay way to do it. However, if you distribute it and someone installs your script to something like c:\mirc\scriptname\ and it points to something like data\data.txt, mIRC will assume it's in c:\mirc\data\ and it may actually be in c:\mirc\scriptname\data\ instead. That's why $scriptdir is safer.

In regards to the hard coded locations of those files, the directory was specified by the original requester, and, as of this posting, nothing seems to have helped. For some reason the ini file doesn't want to allow to be created on his system.

did you echo those two things Russel and verify that they are correct?

That wasn't in response to you.

Does the user have write-access to that location? Or is the file read-only? /writeini doesn't appear to produce errors when it fails to write to a file for any reason. It would seem to be a bug.

All variables and identifiers are returning correct values per the situation. I had him try it with no ini file, and the first parameter that was echoed $file(c:\mircstats\Stats.ini) returned $false.

I then had him manually create the ini file, and at that point it reeturned $true

However, the only way to get the $true was to manually create the ini file, and then the file wasn't updated with the information supplied.

Aside from that, the other variables and identifiers have all returned expected values.

Since the op can manually create the ini file in that location, and the text file with the questions is also in the same directory, I can't see how he could not have write-access to the directory, and the ini file shouldn't be read-only, especially when it's being created (or supposed to be created via the script.)

Edit: The op has informed me that the directory has a read-only attribute, but he's been unable to remove that attribute. This makes no sense to me, since he's able to manually create the ini file.