>They have a useful technique for dealing with such complaints - they ignore you.
>I have stopped filing bug reports.
You do realize this is intentional don't you? If the number of people sending in bug reports drops then obviously they can claim that their OS is becoming more reliable. Sort of the same logic as a ship builder claiming that a lack of complaints is the result of sound design and not the ships sinking with all hands still aboard. ;) lol
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
I filed a number of bug reports at the MS web site, documenting some reasonably serious problems, such as __int64 arithmetic not working, and other things.
They have a useful technique for dealing with such complaints - they ignore you.
I think I've only ever once filed an error with Microsoft, and it was mostly venting my frustration. I'm pretty sure it was in regards to an early version of MediaPlayer, and my post was written something like this:
Documentation error:
Documentation fails to list command line arguments that are available with Media Player.
I laughed my ass off when one day, skimming though the MS KB, I found that listed! (I was probably returning to see if they were documented on the website).
PS: I think they STILL don't document those command line arguments anywhere.
Get my plugins here: http://www.magnumsworld.com/muds/
Constantly proving I don't know what I am doing...
Magnum.
Amended on Thu 23 May 2002 11:33 PM (UTC) by Shadowfyr
Message
>*mutters under his breath for a considerable time*
lol
It is definitely a documentation thing. One source I looked at had something like lpCommandlineargs in it. The irony here is that 'techinically' the DOS window is Windows command shell and shell apps run there just like they do in a Linux/Unix bash. The problem is that unless you have encountered a shell app on Windows you would never know this and the specs on ShellExecute don't bother to clear things up for you. ;) Just another reason to dislike MS. The behaviour makes sense, but it helps to actually be given some bloody clue what the system is doing with it. lol
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
Yes, I understand that, what I meant was from a program. For instance, you don't have to quote things in C, like this:
FILE * f = fopen ("my file with spaces", r);
If you did, it probably wouldn't work.
I know there is a quote there, but that is to get the literal into C, what I had to do for ShellExecute was like this:
FILE * f = fopen ("\"my file with spaces\"", r);
It is probably a documentation thing. No doubt ShellExecute takes that argument, not as a "file to open" but as a "command line" in which case it is reasonable to quote a file name if it happens to be on the command line.
Ok.. The guy from SciTE confirmed something - notepad works correctly for a good reason. It, CryptEdit and most of the others we have been comparing SciTE to all allow 'only' a single file as an input and don't have any other command line atributes. Winword and Wordpad however allow multiple files in their command lines and so does SciTE. They all fail exactly the same way. This means my assumption about ShellExecute is correct and it is calling the program as though you where running it from a command prompt. Programs that use more command line functions than a simple file name or accept multiple files 'will' always fail when you call them using a name that has spaces in it, unless you force them to recognize it as a single string with "". It should say somthing about this in docs for it someplace, but I have looked at 3 seperate sources and they all just show lpCommands or something similar. This is a bit like having a routine that accepts RegexpString, but not bothering to explain what a regular expression is, but this seems to be a common practice with Microsoft documentation. lol
In any case the rule seems to be that if the program requires you the use "" from the command line, then it will alos treat the name exactly the same way when called with ShellExecute. If the program can only except one name it loads it, if it can open more than one file it will treat the name as multiple files. This is not a bug with SciTE, unless MS also screwed up Word and Wordpad the same way. This is not likely.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
Hmm. Interesting that notepad does... Being a complete piece of junk I would have thought it more likely to fail. lol Anyway, using the short verion of C:\Progra~1\ works for where it is and as you say, moving it someplace else is not much of an improvement unless you want to eat up your primary directory and that is not a good idea unless the program itself won't run from someplace like the normal program directory, since eventually you do hit a maximum file limit in there. Nice to know it is the other guys program though. ;)
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
A bit of investigation shows that choosing notepad works, even with a space in the data file name. Thus, the problem appears to be with Scite's parsing of the supplied file name.
Similarly, the internal notepad works.
For now, I suggest simply moving the scripts away from "Program Files" - strictly speaking they shouldn't be there anyway, although "My Documents" mightn't be much better. ;)
Try making c:\mushclient and putting your files there, trying to keep spaces out of path (and file) names.
Amended on Wed 22 May 2002 11:29 PM (UTC) by Shadowfyr
Message
Hmm. Yeah it 'may' be SciTE's fault. As I said, normaly a list of files has "" around them precisely because it makes them seperate files. However it doesn't look like ShellExecute provides any way to specify how many files are being provided and it may be parsing it the way DOS (which is basically the 'shell' under windows) and DOS can't see a single file that has spaces if it isn't in "". I really don't know much about ShellExecute, so am not sure what the assumptions involved with using it are, but if it is intended to be used to send command line like arguements then it 'should' treat spaces as a break and command seperator. If it does treat it this way then obviously you have to "" anything with a space in it or it won't work any better than if you tried the same thing from inside a DOS window, where I have never seen 'any' program that didn't treat such a name as multiple command line arguements instead of a single file.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
if ((long) ShellExecute (Frame, _T("open"), m_strScriptEditor,
m_strScriptFilename, NULL, SW_SHOWNORMAL) <= 32)
::AfxMessageBox("Unable to edit the script file.",
MB_ICONEXCLAMATION);
The script editor name, and filename to open, are supplied as separate fields. I don't "quote" them and don't see why I should. Sounds like Scite isn't handling the case of spaces in the path properly, as you suggest.
Amended on Wed 22 May 2002 05:54 PM (UTC) by Shadowfyr
Message
Nope I am using Windows 98. It looked like SciTE may have in my case looked at the line and did something like this:
C:\Program Files\MUSHClient\AgesScripts.vbs
|
V
C:\Program - Invalid path, skipped.
|
V
Files - No primary path, so tack on 'C:\Program Files\SciTE'.
|
V
C:\Program Files\SciTE\Files\MUSHClient\AgesScripts.vbs - Final result.
The above result may also be because it thought MUSHClient was passing it a file list, though usually such lists are"
"file1" "file2" "file3", but in this case it may have seen "C:\Program" as one file and the rest as a second file within it's default directory.
This is a common problem with some programs that don't treat long filenames with spaces in them correctly. If the one you tried to link to wasn't in such a directory then it would have worked correctly anyway. Usually replacing the directory with it's short DOS equivalent works, i.e. Progra~1. This quirk is rather annoying, since often once the file is actually loaded the programs with this problem use normal save dialogs that can handle the long names and spaces. :p
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.