I have my client set to open a new log every time I connect to the world I play, I just noticed today that the last "successful" creation of a log was on:
12-25-2006(04-21 PM)
Ever since then (and what ever version came out after that date) it has apparently been failing to create the log file, since the %L path is being derived off of the "current" directory, instead of off of the program directory. In other words, since I opened some other program and fiddled around after Mushclient was running, it apparently retrieved what the "system" thought was the current directory, looked for a folder called "logs" there, didn't find it, beeped (or just failed to open one silently, then went on as though I never tried to open one. I have now manually set the correct directory until we figure out what the heck is going on here. :(
Basic rule seems to always be, "Never trust the OS to give you the "right" location for where you need to be *ever*!" lol
I suggest you go into global preferences and change the log files directory to be a fixed path, not a relative one.
The whole thing with the "current directory" is driving me crazy, I can't think of a good way around it.
The problem is basically caused because when you open a file browser dialog box, the flag is set to allow the directory to change.
In other words, if you use the Notepad to edit some scripts, then once you browse to your scripts directory, that becomes your current directory, so trying to open a second file remembers where you were. It would be quite annoying to have to re-browse every time.
However the big catch is, now the current directory has changed, if you are logging to (say) ".\\mylogs", then it now looks for that as a subdirectory of your scripts, and not your world file.
ok I can think of one solution to the directory problem, and will lay out the idea as follows...
Upon RUNNING of MUSHclient, have it retrieve its location and store this in a variable (internal C++) that other functions will use to Prepend relative paths, i.e. those starting with a period, or 2 periods, THEN pass it to the proper function that will use the path attained.
When I make a program in Autoit, and I need to use relative paths to the program itself I do the same task, but then again it is automatically done and placed into a variable @ScriptDir, and the script/executable FULL path is stored in @ScriptFullPath
I don't know HOW to impliment such a fix, BUT that would correct nearly ANY issue with relative pathing, the only issue might be using Wine, as I don't know how it handles relative pathing.
With Wine, when I press shift-ctl-J, a file selector pops up in the right place. This is after I changed directories a few times to load plugins in weird spots, and used Notepad in Wine to change directories. It seems that Wine is storing the working directory as the "current directory" or just does better at keeping track of what program is looking where.
I hesitate to report this as a bug at winehq, but I guess for 100% compatability, you have to include the stupid.
Also, with logging, MC just dumps whatever I have in the output buffer into the file. I don't log much (don't think I've used the logging more than twice in the 10+ years I've used MC), so I don't know if I'm doing something weird or Wine is. How do I get the client to continually put new lines into the log file?
Nevermind... it's working. I just had to wait a bit for some of the text to get added. Just hitting enter a few times to get the prompt didn't put anything new in, even though the prompt is logged. Seems to be working well now that I'm actually out doing things.
Well. The problem is, if you get the current directory when it starts, are you getting the "current" directory or the "start in" path stored in the short cut? Now, running the application directly means you always get the right path, since its "start" location is always the same as the file. But under Windows, you can define a different location for it to start in, which is then returned by some functions for getting the path... Its a major pain in the ass..
It also looks like another one of those, "Duh! Its so easy why can't you figure out out?", problems, like one we have been talking about now and then...
Wait, why is it bad that you can override the initial current directory of a program? On the contrary that is an extremely useful thing to be able to do...
To answer your question, if you get the current directory when it starts, then assuming the current directory has not been changed, then yes, you will get the initial directory, aka initial working directory.
Upon RUNNING of MUSHclient, have it retrieve its location and store this in a variable (internal C++) that other functions will use to Prepend relative paths ...
Well this isn't as easy as it looks. For one thing, when running a script you don't know if the script will open files. Maybe the script will deliberately change the current directory and it will be broken if you change it back.
Things can get heavily nested. For example a script does a LoadPlugin, the plugin loads an include file, the include file does a "require" of a Lua file, the "required" file opens a disk file.
Not sure if that is relevant Nick. The point here is to make sure the *base* directory is the same from the moment it loads and thus that things like the main program directory remain the same all the time, not to force the application to always stay in the same directory. In theory, the real problem with logs is either a) %L tries to use the "current" directory as in ".\logs", unless you specify one or b) we need a %M that will always be the location where Mushclient started, so that %M%L will be "C:\Program Files\MUSHclient\" + "logs\" (presuming it starts in the default install location). specific folders, like log files, etc. shouldn't "ever" use the current directory, but instead should always use one either a) derived from the initial start location or b) one *specifically* given by the person either manually opening one in the script or from the user specified default location, in cases where the person wants to put them some place else. Where the "current" directory is relative to any of this is completely irrelevant and shouldn't have any effect at all, "unless" someone specifies when manually scripting the location to open a log, etc., that they want it created/opened locally using "." or "..", then its their problem if they or something else changed the current directory before doing that (and imho its bad practice to do that anyway, precisely because its not 100% certain that it will remain the same).
Most things, like a DOS window, for example, or other applications, get the current directory, store that, then keep track of *only* those changes *it* makes to that path, so that its own "current" location remains independent of what the system thinks it is. Its just basic common sense. The only time the "current" path is used, from the OS, is during initial startup and in cases where you are opening a file and the assumption is that the last open folder is where you want to load it from. This imho is both good and bad too. Some programs default to their own location for that, and its a pain to navigate to some place else to find the file you want. Others store the last place you had opened in the system registry, so it can start their. Still others take the current working location, which can be either where they started, or where you last opened something after the program itself is running. Imho, the first and third are useless, with both in a tie as to just how useless they are, depending on the situation. You get the **exact** same problem if you just happen to have something else, like a text editor, open, (it) changes the OS working directory and your script then tries to open something that isn't where its supposed to be anymore either. Its generally much better if the application/script keeps its own track of where things are, including it own "last opened" location and ignores what the bloody OS thinks is going on. Relying on the OS to know what is happening is absurd, dangerous and nearly always useless.
Most things, like a DOS window, for example, or other applications, get the current directory, store that, then keep track of *only* those changes *it* makes to that path, so that its own "current" location remains independent of what the system thinks it is.
I'm not sure what you mean by that. I don't think they do any such thing.
Look, the current path is the path that is used when a file is opened without an absolute path. So for example, if the current path is c:/foo/bar and a program opens "abc.txt" then it is really c:/foo/bar/abc.txt.
Programs don't normally store the current directory. Each process maintains its own notion of the current directory. So, if you start two DOS windows, and in one change (cd) to /foo, and in the other change to /bar, and then attempt to open a file, it will open in the new directory.
It would be ridiculous and unwieldy if every time the program decided to change directories (programatically, 'chdir ("/foo")' ) it also had to keep a "working copy" of the current directory.
Quote:
Relying on the OS to know what is happening is absurd, dangerous and nearly always useless.
It isn't clear to me how such a scheme would work in a scripting framework. You are suggesting the application should "know better" than the operating system what the current directory is. So, when you call a script (eg. on a trigger), the script can do anything, including open files. How can I second-guess what the script code might do and prepend the current path to any open calls it may or may not make?
Conceivably a script might call a DLL, and the DLL might open a file in the current path.
Quote:
In theory, the real problem with logs is either a) %L tries to use the "current" directory as in ".\logs", unless you specify one or b) we need a %M that will always be the location where Mushclient started, so that %M%L will be "C:\Program Files\MUSHclient\" + "logs\" (presuming it starts in the default install location).
Well I think you are right, the problem is using relative paths in the first place. But if you did what you suggest, and then later browsed for a different log file path, the path could end up being:
Quote: It would be ridiculous and unwieldy if every time the program decided to change directories (programatically, 'chdir ("/foo")' ) it also had to keep a "working copy" of the current directory.
Wait, what!!! No, what I mean is that it you have two DOS windows open and you do "cd foo" in one of them, the other one doesn't go back and go, "Gosh! The current directory changed, better look in foo now!" It remembers where "it" is. This is obviously a bit harder to manage with scripts, but we are not talking about scripts here, we are talking about Mushclient itself remembering where the heck **it** is supposed to be looking when you use its own functions. This isn't a fracking DOS window and we are not sending the OS a series of commands like:
cd c:\MY Documents\
open log .\logs
It makes no sense for it to be using a relative path based on where some completely different program last opened something. If anything else did this you would have a major mess. Imagine, for example, you are working on a paper for some projects and you save it, only 5 seconds before you do your virus scanner opens something in "its" directory, and so now your copy of Word decides to save all its files in "that" location, instead of in the folder "it" considers to be the default for documents. Oops! No, ***not*** keeping a predetermined location and making the people who want to use some other location "specifically" say so is what is *unwieldy*.
Quote: Well I think you are right, the problem is using relative paths in the first place. But if you did what you suggest, and then later browsed for a different log file path, the path could end up being:
Huh??? Oh, right, in the script. But that isn't the same bloody thing, and it would only do that if you did something absurdly silly, like not checking for the "C:". In other words, fixing it is a matter of doing what ever other application does in this case and assuming that, if you are in "c:\foo\bar", then "\logs\log.txt", "logs\log.txt" and ".\logs\log.txt" are **equivalent** and should produce "c:\foo\bar\logs\log.txt". Obviously "..\logs\log.txt" should produce "c:\foo\logs\log.txt". Howevery, something like "g:\bar\foo\logs\log.txt" is **not** a relative path in the first place, so its path should override any path information that is there and give you "exactly" that path. Sorry Nick, but I can't imagine why you would think that *any* application that uses relative paths would handle "g:\bar\foo\logs\log.txt" by making it "c:\foo\bar\g:\bar\foo\logs\log.txt". Mind you, I have seen at least one case where some fool did that in a program. It was fixed in the next version. lol
Point being. If someone gives a relative path, it should be relative to the program's path, not what ever arbitrary path happens to currently be active. If someone gives a non-relative path, then 99.9% of all existing applications go, "Ah, OK. You want to change directories or even volumes entirely, no problem, I will just ignore the path I have and use yours, **for this operation**. Unless there is a specific command for "changepath" or the like, this has "no" effect on where everything else goes. If you don't do it that way, then its *impossible* to know where the frack the new file will end up, since *anything* running on the same machine might change the main part of the path, invalidating the original location. Think about it. Lets say I am writing a log "only" occationally to, I don't know, keep track of in game lotto winnings, but nothing else. I am closing them opening a log, changing the name to have the exact time in it, but not keeping it open. The location I "want" it to be in is "c:\program files\muschlient\logs", so I open a file using ".\logs\blah.txt" Now, I open one, it works, the file is written, I close it. WinAMP or something opens a new file in "c:\my music\anime", this changes the "current" directory, so the next attempt to open a relative path is actually "c:\my music\anime\logs\blah.txt". Oops! It doesn't even open. The next thing is some download manager, which opens and starts downloading a file, it just ran from "c:\program files\my downloader\". This time it works, because it "does" have a "logs" directory, only they are not where the are "supposed" to be, since I have been assuming that the path is going to be relative to the application I am using, not what ever semi-random location the OS may now be pointing to.
It every application handled relative paths the way yours does Nick, with all due respect, the machine would be unusable and no one would have a clue where anything was saved. You are not second guessing "everything" the script is going to do, just the ones related to "your" client, where the logical expectation is that they are relative "to" that client, not some arbitrary location that can't be controlled. If some fool wants to use something like the system io functions in Lua to futz around and "they" put there own stuff in a relative path that isn't derived from anything, that is *their* problem. lol
If you don't do it that way, then its *impossible* to know where the frack the new file will end up, since *anything* running on the same machine might change the main part of the path, invalidating the original location.
I think you are confusing multiple processes here. Naturally, changing the current directory in (say) Word, would not affect MUSHclient, and vice-versa.
There is no "current directory" for the PC you are sitting at - for "you" the user. It is current for an application - a process.
The whole point of current directories is, that if the application chooses to change it, then from that point on, relative paths are relative to the new location.
Quote:
... so that %M%L will be "C:\Program Files\MUSHclient\" + "logs\" ...
Huh??? Oh, right, in the script. But that isn't the same bloody thing, and it would only do that if you did something absurdly silly, like not checking for the "C:". I
What script? You just said you wanted to be able to use %M%L in your log file pathname. My point was if %M contained the application path, and %L was the log file path - an absolute path - then you would get the file name I gave as an example.
Your suggestions aren't consistent. You asked for %M to be the application path. You didn't say anything about "and if it happens to be next to a %L then you have to check if they are both absolute paths, and delete the absolute part of one of them". In any case, which one would you ignore? If %M was on D: and %L was on E: which one takes preference? I'm not doing anything absurdly silly here, you are suggesting that you be allowed to concatenate two possibly conflicting paths, and I am pointing out the pitfalls.
You are firing off suggestions, and I am trying to make you think about the total ramifications of them.
Quote:
If someone gives a relative path, it should be relative to the program's path, not what ever arbitrary path happens to currently be active.
Even this suggestion is fraught with peril. You say "the program's path", not the "initial directory". Is that really what you mean?
Let's take an example. Two people use one PC. MUSHclient is installed in 'C:\Program Files\MUSHclient'.
However they start it in different directories (the intial or startup directory). For example, one might be 'C:\Files and Documents\Shadowfyr\MUSHclient' and the other one might be 'C:\Files and Documents\Marilyn\MUSHclient'.
The point of doing that is so that you can each have your own world files (and log files etc.).
Because of this you both open your logs in a relative '.\logs' directory.
If I did what you suggest and make the open relative to the "program's path", then all logs will be in 'C:\Program Files\MUSHclient\logs', which is where neither of you want them.
You really need to think carefully about what you are suggesting. I have added a new feature in version 4.03, to let you specify the startup directory in log file name:
Thus, the logical thing to do, if you didn't want to specify an absoluate path for the logs in the global configuration, would be to log to something like:
%E\logs
Quote:
... but we are not talking about scripts here, we are talking about Mushclient itself remembering where the heck **it** is supposed to be looking when you use its own functions
I still maintain that for MUSHclient to "remember where it is supposed to be", is like asking it to "remember the time" because, as you put it "Relying on the OS to know what is happening is absurd, dangerous and nearly always useless.". You have to rely on the operating system a little bit.
Quote: Huh??? Oh, right, in the script. But that isn't the same bloody thing, and it would only do that if you did something absurdly silly, like not checking for the "C:". In other words, fixing it is a matter of doing what ever other application does in this case and assuming that, if you are in "c:\foo\bar", then "\logs\log.txt", "logs\log.txt" and ".\logs\log.txt" are **equivalent** and should produce "c:\foo\bar\logs\log.txt". Obviously "..\logs\log.txt" should produce "c:\foo\logs\log.txt". Howevery, something like "g:\bar\foo\logs\log.txt" is **not** a relative path in the first place, so its path should override any path information that is there and give you "exactly" that path. Sorry Nick, but I can't imagine why you would think that *any* application that uses relative paths would handle "g:\bar\foo\logs\log.txt" by making it "c:\foo\bar\g:\bar\foo\logs\log.txt". Mind you, I have seen at least one case where some fool did that in a program. It was fixed in the next version. lol
So what if my copy of MUSHclient is in "C:\Program Files\MUSHclient" and my startup directory is "C:\Files and Documents\Biggs\MC" and they both contain subdirectories and files identically named "\logs\log.txt" Not to try and shoot this idea down, but I'd just like to know what you think the program should do if I try to open up a file with ".\logs\log.txt"
Quote: It makes no sense for it to be using a relative path based on where some completely different program last opened something.
Ok, this time I am trying to shoot down an idea. You do realize that the file picker Windows provides is a program, right? That's how you can click on "Explore current directory" in a lot of programs and have a window pop up with whatever directory is considered the "current directory" by said program. Occasionally these issues can collide with each other, especially on older programs designed for Win98 or earlier systems. Wine tends to get around this by storing the current directory slightly differently as far as I can tell, since I can't duplicate the issue you mentioned in the first post of this thread.
The other thing I want you to consider is that when you make a request like "please change the behaviour of the program to do X instead of Y" that a whole lot of people (maybe thousands) are relying on behaviour Y, and have written scripts expecting it.
For example, someone may have a script run at program startup that does a ChangeDir - quite deliberately, so that afterwards stuff (like logs) is in a relative path to the new directory.
To make the client override that and force relative paths to be relative to the executable (or the startup directory, you haven't said which you really mean yet), could make such scripts break.
Well, with a combination of grabbing the startup directory, or the first working directory, and using ChangeDir, you can muck about with where you have the client pointing to wherever you want.
My only comment about the "expected" behavior you are talking about Nick is that ***its not reliable***, so if they are actually relying on it, they are seriously foolish anyway. The point it, its *not* reliable if you are basing your behavior on commands that can't remember and maintain a known directory location, from which to derive those paths. That's the whole problem to start with. I would really hope that scripts that use directory commands are using something more stable, otherwise its inevitable that the script **will** fail when something else changes the location. Personally, I would rather have "reliable" design, not backward compatibility.
What commands "in" a script that involve the "scripts" own functions are doing is one thing, what commands that are part of the client design do.. That is imho entirely different. Frankly, depending on how the io functions for the script system work, it might not even be reliable to expect *those* to produce the same results from moment to moment when using the clients file commands. Why not? Well, who is to say 5 different plugins won't all be using those io functions? Why cater to bad programming practice, instead of just saying, "relative paths are not reliable and can change unexpectedly, so if you want to open a file some place *other* than in one of MUSHclient's own directories, provide a 'complete' path. If you don't, it might not work correctly." Given the problems we already have with this, relying on the existing behavior is plain bad design. I am not talking about changing what the script does, just the stuff "in" the client, where I think everyone is likely to presume its relative to the program path. If some fool wants to play, "Lets hope the directory is right today!", with script io, more power too them. But I just don't see the benefit of ignoring reality and presuming its either good coding practice in a script (or any place else) or that it actually works now (it doesn't, it simply doesn't break often enough for people to *get* that it won't work like they think it does).
But heh, its your call, for now. Its not like I have scraped together the hundreds of dollars needed to try to fix it myself at this point. lol
So out of curiosity, have you looked at the GetInfo function at all?
Quote: (strings - calculated at runtime)
51 - Current log file name
52 - Last "immediate" script expression
53 - Current status line message
54 - World file pathname
55 - World title
56 - MUSHclient application path name
57 - World files default path (directory)
58 - Log files default path (directory)
59 - Script files default path (directory)
60 - Plugin files default path (directory)
61 - World TCP/IP address (as string, after DNS lookup, eg. 10.0.0.16)
62 - Proxy server TCP/IP address (as string, after DNS lookup, eg. 10.0.0.22)
63 - Host name (name of this PC)
64 - Current directory
65 - Script function for world save
66 - MUSHclient application directory
67 - World file directory
These values can be used to grab whatever you need. I don't see why we have to cater to bad programming practice either, such as not using available functions to get a defined path to your file rather than just going for the "current directory" which, being just "current", can change. By the way, all of my scripts, logs, etc are in C:\blah blah blah, and my current directory is "H:" and I have had no problems whatsoever with any of my scripts. Also, to fix issues with having hard file paths to plugins on my world file on my USB drive, I've made a script that's executed once the file is loaded that will grab the program directory and load the plugins with a relative path from there. Not terribly hard to do, and then I have a variable with the path I need stored.
Given that a script (or a DLL a script calls) might change the current directory without "notifying" MUSHclient, and given that another script might rely upon the current directory, I would have to say this:
Warning - do not rely upon using "relative paths" in MUSHclient.
In fact, in a recent script, I found exactly that problem, so I added a "ChangeDir" into an alias. See:
Shaun, as I said, or tried to, several times, the issue isn't necessarily with script. You ***can't*** use "GetInfo" to set the location for opening a log automatically "in" the log settings, so the existence of such a command is worthless in that context. In the context of the World and other settings "in" MUSHclient, lets assume for the sake of argument that we don't even have/use scripts, it makes no sense for those settings to be using a relative path that is not associated with some known location. At the very least, one needs some way to make very clear that the "log" directory, in that context, ***is*** related to the program's own folder, not some arbitrary place that changes every time the system does something. Imagine for a moment if MUSHclient treated any other setting that way. Loaded worlds, its script engine, its spellchecker, its plugins, etc. from a "relative" path that was based on an arbitrary location, instead of the program path. Nothing would work. Therefor, it makes no sense that the relative path "in" the settings for log files should point at anything other than the one directly under the application path either.
If someone wants to open a log file or anything else based on a relative path that "isn't" in that path, let them do it in the script itself and suffer the logical consequences of that. But the "inbuilt" function for maintaining logs and opening them should imho, have a consistent "default path", which comes from the client, not the OS, since its the *client* that is handling the logs, not WinAmp, Explorer, Word, a database of your aunt's favorite cookie recipes *or* even the script system.
That's all I am saying here. I really don't care what the behavior is "in" the scripts. But it makes no sense for 90% of the functions for loading everything in through the client's internals to be based on a path relative to the client, but have logs inexplicably, when defined through the same, just try to open where ever the system happens to have last opened a folder. And GetInfo doesn't do anything to fix that, nor does the, "Use %L to have it open in the default log file path", make sense unless there is "really" a default of some sort, and not just where ever the system is looking at the time.
Someone wants to point the system at Z:\foo\bar and then do "openlog (".\logs\log.txt")", or what ever the command is in scripts for it, I wish them luck. But I don't think it makes any sense for the built in log management to presume that someone has, can or "will" set the path to the right place *before* opening one with the default log path. It just doesn't make any sense, either in context of a) what is being done or b) the description of the options for that log command.
Let me put it another way:
%L%N_%m-%d-%Y(%I-%M %p).txt - Program path.
.\logs\%N_%m-%d-%Y(%I-%M %p).txt - Where ever the system is currently pointing.
%L **implies** that the application already knows where that "is", the install already makes a folder (I think) by that name, so the logical conclusion is that, unless you specify otherwise by changing it, %L should be the application path + ".\logs\". Show me *any* application that supports such things that doesn't presume a default location based on "itself", instead of an arbitrary one, and which works right, and I will be happy to concede that the description of %L makes any sense at all the way it currently works.
That still doesn't explain why anyone would persist in using relative path names when you know they don't work the way you expect them to work. It's generally poor practice to use relative paths when full paths are possible just do to the confusion that might happen. My log files for each world are set with a full path, since I know where I want my file to be. If I have something that can vary due to which world or user is using a plugin I've made, then I just have code set with OnPluginOpen to set it to a hard file name.
What's really so hard about putting "C:\Program Files\MUSHclient\logs\%N_%m-%d-%Y(%I-%M %p).txt" as a filename?
Nothing it hard about doing that. The issue is, if we really get down to it, that how %L operates is imho misleading. I can't speak for everyone, but I suspect that most people when they read that it provides the, "log path", are going to look at the directory structure for Mushclient, see that there is a path like "c:\program files\mushclient\logs" and *assume* that this means that the default location for that path is going to be the application path + "\logs\", not some completely unknown location. Its confusing. And worse, when it doesn't open because it can't find a "logs" directory in what ever place it does try to open it, it fails silently, so that unless you notice that the log icon isn't active, you don't know it isn't saving one. This is, imho, very bad, regardless of what ever other arguments you made about what the correct behavior should be.
Well, if you would care to notice... I don't use the "%L" because I don't want to deal with any type of dynamic link. I've said this in a few posts, and you still try to say that I'm arguing that it's a perfectly acceptable way to do things. All I'm saying is that you have declared something is a bug, you have explained it, you have offered a solution that does not work in all situations, so don't use %L.
Can't we just have %L point to the default log path as declared in the global preferences menu?
most people when they read that it provides the, "log path", are going to look at the directory structure for Mushclient, see that there is a path like "c:\program files\mushclient\logs" and *assume* that this means that the default location for that path is going to be the application path + "\logs\"
You haven't replied to my question about whether it should be the application path or the startup directory path.
Technically, you shouldn't be writing to anything in the application path because that is shared between multiple users, and should even be set to read-only.
The startup directory should be a writeable directory that is unique to each user.
I might also point out that if I am using any program at all (like Word for example) and I ask it to open a file in a relative path, expect it to be a relative path to where I currently am, not to where the application happens to be on disk.
Hmm. Ok, Nick, you have a point in that case, assuming you want to get that complicated. Under XP, Vista, etc. it would be the current user, under older ones, it would be the application path, since there is no "user" path. But that brings up another issue. Mainly, if you are going to put it in:
Win XP, etc. - Current User:/MUSHClient/
Win 98 < - /My Documents/
Then you need to either a) inform the user than the directory doesn't exist and ask if they want to create it *or* b) automatically create one. And if you really want to argue about that, then logically, on something like XP, the folder paths would have to be:
C:\Program Files\MUSHclient - main application and other support files.
C:\Documents and Settings\User_Name\MUSHclient\Worlds
C:\Documents and Settings\User_Name\MUSHclient\Plugins
C:\Documents and Settings\User_Name\MUSHclient\Logs
And so on. In any case, you have to make sure there is a directory to open/create something in at all. Frankly, for myself, I prefer to keep it where it is, even for XP, simply because if I change users I don't want to "lose" access to thing. But, if you really want to worry about that, then yes, any user data should be placed in the "users" data area, not in the program directory structure. That just opens a new can of worms though, especially if someone, like me, doesn't want it being put there and locked to a specific user account. In any case, the logical place for the data under older ones is "My Documents", but about 50% of the programs I know don't do that, and you still have the, "I am sorry, but the folder you are trying to put it in doesn't exist.", issue, not to mention that if you "do" put it in there you still need to make sure the name is unique, by doing what I show above and placing the files in "MUSHclient\Logs", not just "Logs".
It makes more logical sense in a way to do that (not that logic is high on the list of priorities for Windows software...), but it means adding checks for OS version, checks for user name on those that use them, checks for the existence of folders, code to create or request creation of them if they don't exist, and so on. And still installations only happen on those in the root system, you may also need to set up folders for "each" user that will use it, either at initial install or when each user runs it (the later being probably easier).
And no, the "document" directory should be unique and writable for each user. That isn't the same thing as the "startup" directory at all. Things like Word tend to remember the last place you opened/wrote something. The nicer ones remember each independently, so if you are doing something like image manipulation the "open" path doesn't mess with the "save" path. But they most certainly don't use, "where I currently am, according to the OS.", usually. The ones that do are imho, a major pain in the ass to use, since 90% of the time you have to navigate to what ever you are actually trying to do, even if 100% of the time the files you open with it are in the same place.
In any case, right now MUSHclient isn't XP aware. It has no clue that user profiles exist, that its running in one or that there is a document folder for that user. Its program directory ***is*** its document path, so its "startup" location is its own directory path. That means that at the moment its actually using "something else's" startup path/document path (depending on what the last application run was doing), when it tries to open a file, instead of its own. And that is where the problems are coming from. Word would break the same way if it used the path for some other program every time it did something, instead of remembering the last path you used *in it*, or using the path to the document you opened with it. That is the only case where the document path should change, if the document you open is some place other than where the program would normally look. And even then, unless you want to make plugins, logs, etc. sub paths to the worlds, those have their "own" document paths that are independent of the world files, in the current design.
Or to put it another way, you don't expect something like OpenOffice to look for word documents, spreadsheets and databases all in the "same" place you last opened a word document. You expect it to know that you last saved the word document in foo\bar, the last spreadsheet in foo\rab and the last database in foo\dbs, and not confuse those. But if you open something in foo\junk, you expect it to remember that "that" file is in foo\junk, and to not change directories on you, unless you do "Save As", and thus force it to forget the "foo\bar" location it normally starts in when opening files. Right now MUSHclient is doing the equivalent of starting in foo\bar, having something else start two seconds later in foo\me, and then trying to open its logs in foo\me instead of where *it* started. To use Word as an example, Word would **never** do this, nor would 90% of the other programs that exist.
Quote: Or to put it another way, you don't expect something like OpenOffice to look for word documents, spreadsheets and databases all in the "same" place you last opened a word document. You expect it to know that you last saved the word document in foo\bar, the last spreadsheet in foo\rab and the last database in foo\dbs, and not confuse those. But if you open something in foo\junk, you expect it to remember that "that" file is in foo\junk, and to not change directories on you, unless you do "Save As", and thus force it to forget the "foo\bar" location it normally starts in when opening files. Right now MUSHclient is doing the equivalent of starting in foo\bar, having something else start two seconds later in foo\me, and then trying to open its logs in foo\me instead of where *it* started. To use Word as an example, Word would **never** do this, nor would 90% of the other programs that exist.
I actually get quite annoyed at Firefox because of this method of storing files. If I save a picture, then go to save a text file, then a .zip, and I want it all in the same directory, I have to select that directory each time. There is no guarantee that just because I saved a picture to one directory means that I want to save every picture there.
The program nedit takes an interesting approach that sort of splits between the two ideas. The current file directory is whatever the directory is of the document you currently have on top. If you go to another tab with a file based in a different directory, then you will get that file's directory as the base. If you don't have a file that has been saved, it defaults to the directory in which you started the program.
Another odd issue to go along with the default directories in the method that you suggested for going into the documents folder automatically, is that you may not always run the program from the same spot all the time. I carry a copy of MUSHclient on a usb drive when I travel. There is no way to be sure that I have a user account on the computer that I'm using (could be logged in as a guest). Also, there certainly isn't a way to make sure that the usb drive will ever even have the same drive letter. This is the situation where I have a script grab all the information I need to make the relative file paths work instead of trying to use internal links.
In any case, right now MUSHclient isn't XP aware. It has no clue that user profiles exist, that its running in one or that there is a document folder for that user.
I agree about the can of worms. :)
Well it was written before XP existed, however I should point out that the "global preferences" are stored in the Registry, under HKEY_CURRENT_USER. That means that if you change users (ie. profiles) then you would get a different set of global preferences. Now, the global preferences contain your paths like DefaultWorldFileDirectory.
Thus, changing users should let you get a different default world file directory. eg.
Quote: ou expect it to know that you last saved the word document in foo\bar, the last spreadsheet in foo\rab and the last database in foo\dbs, and not confuse those.
I don't expect this behavior. On the contrary I want it to keep the last directory I used, and not try to be clever by guessing which directory I really meant.
Yeah, the thing I don't like about some products is they try to be too smart. For example the idea that it should keep its own internal "current directory" perhaps tied to a current world, or plugin, or notepad, or whatever you have in mind.
I remember a while ago I tried to write a simple letter using Office 98 or some such thing, and a little box popped up and said "I see you are trying to write a letter - would you like me to help you?". I replied "yes" which was one of the biggest mistakes I made that day.
From then on, I spent about half an hour wrestling with how *it* thought I should format the letter, compared to what I really wanted. I would left-justify something, and it would right-justify it and change the font. I would change it back, and it would do it again. I had to abandon that letter entirely.
I could give lots of examples, but basically I don't want software to try to be "too smart". As for the directories, if I change them, well they are changed.
A suggestion I *would* be prepared to look at is changing the flags in the file browser dialog boxes (however many of them there are) so that they do not switch directories. That way, the "current" directory will probably stay the same (unless a plugin changes it).
However if you try to open 10 different files in a non-standard directory, you will have to navigate to it every time.
Not sure they are flags per-say. Its a persistence function. When you close the object, persistent ones will either a) write information about their current state into the system registry (bad, since we are trying to get away from that, and worse, since I don't think this is necessarily a built in feature) or it fires an event of some sort that calls code in the object specific to saving that persistent data. If you don't have that code, then it may remember where it is *when running*, but it forgets where you had it the next time you load the application. I have no idea how MFC handles this issue.
And frankly, remembering where you where last is pretty dumb behavior. If I open a file of a specific type in Word/OpenOffice from the A: drive or a USB drive, etc. it will "try" to look there first, because that is the last place it remembered, instead of returning to a default location for that file type. The only ones that remember the specific location you *want* a type of file to go are ones where those files are directly linked to the application as part of its own design and mandate specific locations. That or ones that have no persistency at all and instead always default to their own application path, which is imho a major pain in the ass when the place you save everything for them is 10 directory clicks away from there. :( But no, remembering where you last put a file isn't that bright. If its something like, "Which paint brush would you like to load?", then I would expect it to always start with, "C:\Progra~1\MyPaint\Brushes", if its, "Which image do you want to load?", I don't want to have to navigate from "C:\Progra~1\MyPaint\Images" to "My Documents\Images" every bloody time. There is a right time and a wrong time to be that smart<>stupid. lol
Restores the current directory to its original value if the user changed the directory while searching for files.
Quote:
And frankly, remembering where you where last is pretty dumb behavior.
I don't think it is that dumb. Say I have a folder of photos I took recently, and I open one up in Paint or some such program. I view it, and close it. Then I want to look at another one. I don't want to have to work my way from the "default" directory for pictures (whatever that is), to another drive maybe, and a deeply nested folder, just to get another one.
I don't want to have to navigate from "C:\Progra~1\MyPaint\Images" to "My Documents\Images" every bloody time. There is a right time and a wrong time to be that smart<>stupid. lol
OK I see you acknowledge that point. So how does the program guess when to be "smart"?
Quote: Another odd issue to go along with the default directories in the method that you suggested for going into the documents folder automatically, is that you may not always run the program from the same spot all the time.
Well, in the case of what I am talking about, it would only use a default location if you specify one. If you leave it blank, it should either a) remember the last place you where or b) use the normal path, if you haven't run it before. Right now.. Its not doing either, its letting everyone else tell it the place it should be. If it did either (a) or (b) we wouldn't be having the problem. I say this since some of the posts that follow your comments, including the post itself, seem to be implying something that I didn't say or intend.
Quote: OK I see you acknowledge that point. So how does the program guess when to be "smart"?
You are already telling it when to be that smart, by allowing us to specify an exact default path for it. The problem is, its being even dumber than most, in that its ignoring its "own" box in favor of what is going on in someone else's. Think of it this way. Each application can either watch what everyone else is doing, or it can ignore everyone else. The method you are currently using to get the path, instead of using either a basic, "If you don't specify what the path is, then it should normally place it in X.", or a, "Oh, you last saved a file in Y, I will try to open it there (which in the case of logs doesn't imho make much more sense)", you are getting the path from something that keeps track of what everything else on the system may be doing. If I am opening a log file for Mushclient, I expect, as I suspect most people will, that, unless I say otherwise, its going to be where Mushclient's installer specified as the default location. I might, if I **manually** open a log file expect the world to "remember" where I want log files for that world. If I set it up to open automatically, then imho, it should be either the "last place" that one was opened, if I have done so before, the default path in global settings, or the normal Mushclient path if I have a) not opened any logs for that world and b) there is no default path specified for where to put them.
In other words. Good behavior would, and this is just my opinion, be to go:
Is this an auto open?
Yes - Look for "Last Log Folder=" in world data.
Was one found?
Yes - Open the new file in this path.
No - Is there a global "default"?
Yes - Open in the global path and set "Last Log Folder" = "Global Default Path".
No - Open in install default path (or what ever you decide Mushclient should use here).
Right now that is "Application Path" + "\logs\.
Set "Last Log Folder = Global Default Path.
No - Open file dialog with path set as per same logic as above.
If the user changes the path, then set "Last Log Folder" to where the user specified.
Note, this *may* require, to avoid the pitfalls of placing this data in the world file, which might not be saved, or in the registry, where its a pain in the rear, saving some settings in an old style .ini file for the client. Something like:
[World Log Paths]
b42313b380ebf45f5c61edce = "C:\Documents and Settings\Kagehi\MUSHclient\Logs\"
Also a good place like the current size/location of Muschlient's main window and other "global" settings. Frankly, I think that in some ways, their switch from .ini files to system registry, in a wide number of cases where it just doesn't make any bloody sense to have them, since they are not shared between applications, was a serious mistake. I mean, you want to register a component or provide other automation or intercommunications data, fine, but why add in the other 90% of the data that isn't relevant to any of that, and which just increases the size, complexity and odds of one accidental error fracking the whole bloody system? Damn silly if you ask me.
Shaun BiggsUSA#37
Actually, it looks like one big problem is actually the difference between 9x and 2000 or XP.
Quote: Otherwise, if the application has used an Open or Save As dialog box in the past, the path most recently used is selected as the initial directory. However, if an application is not run for a long time, its saved selected path is discarded.
This is found in the 2000/XP section of the OPENFILENAME Stucture link that's posted above. All the suggestions listed above are already implemented, but they are far down the queue. Might also explain why I haven't had any issues using my laptop with win98 on it.
Quote: [World Log Paths]
b42313b380ebf45f5c61edce = "C:\Documents and Settings\Kagehi\MUSHclient\Logs\"
So in other words, like my suggestion of looking at what is set in the global preferences section...
Quote: Also a good place like the current size/location of Muschlient's main window and other "global" settings. Frankly, I think that in some ways, their switch from .ini files to system registry, in a wide number of cases where it just doesn't make any bloody sense to have them, since they are not shared between applications, was a serious mistake.
The only issue with this is that you still have to have the .ini file stored somewhere that the computer can find. The registry seems to be as good a place as any for this data. Plus it takes less space to store and is faster to load than it would be to read a .ini file, since it just has to query the registry.
I'm not sure I totally agree with what Shadowfyr is saying, however he does have a good general case.
As an experiment, I have modified version 4.03 to have this new behaviour:
If it uses one of the following three global configuration strings:
Default world files directory
Default log files directory
Default plugins directory
and ... you attempt to open a file using one of those (eg. logging a session, adding a plugin, opening a world) and the directory name is a relative path, then it will prepend the MUSHclient startup directory (not the application executable path).
I think this is reasonable behaviour. In other words, if you start logging immediately after opening MUSHclient, and the log file directory is "./logs/", then the current behaviour is for "logs" to be under the startup directory.
In current versions, if you then change the directory (eg. by browsing for a file), then "logs" is no longer where we expect. So, the code above should make sure it actually is where it initially was.
To clarify this, the change will not alter the current directory, so file browsing will still work, and if a plugin chooses to change the directory it can. However the specific cases of the MUSHclient's default directories will now work in a more natural way.
Frankly, I think that in some ways, their switch from .ini files to system registry, in a wide number of cases where it just doesn't make any bloody sense to have them, since they are not shared between applications, was a serious mistake.
I agree with Shadowfyr here - I think personally the system registry is just one huge central point of (possible) failure, which is hard to read and virtually impossible to back up and restore. It is certainly hard to roll it back if you install something you no longer want.
One change that could make sense would be to put configuration stuff into a localized file (maybe the startup directory is a sensible place) and use Lua to read it in. After all, we already have Lua, and that was what it was initially designed for. It is incredibly fast at reading stuff like that.
Yeah. Ini files where "always" in the execution path of the application, same with some other configuration files. Shifting them to the registry just created more things that could be bugged, suffer memory glitches, not save right, etc. And just one wrong entry could actually, in some cases, trash the whole registry, since there where no real protections against the system or another application, especially under 9x, accidentally killing data that didn't belong to the application in question, but *did* exist in something the user had access to, or which was available globally, when running in that mode.
You might as well just give viruses direct access to program code or paint a bullseye on the icon for registry files. lol
Quote: "[World Log Paths]
b42313b380ebf45f5c61edce = "C:\Documents and Settings\Kagehi\MUSHclient\Logs\""
So in other words, like my suggestion of looking at what is set in the global preferences section...
Um, not really, since, presumably, if you decided to place it in something like "D:\My Logs\MUSHclient\Log Cabin", then what would be saved in there as the last log path used for that world would be:
But yeah, there should be a logic hierarchy and some logical sense as to what happens in which cases. Nick's change should be fine, in that it creates the behavior I was expecting when I used it, even if it doesn't go "quite" as far as letting each world remember the place it is using independently.