Just found this...

Scite from http://www.scintilla.org/ is an editor for a wide range of languages including Perl, VBScript, JavaScript and XML. Looks like it would make a good replacement for the internal editor for those of us that have hit the limit. It also supports quite a lot of other languages as well, like 34 in total, not including 'normal' text files.

One interesting feature is that it breaks code into compressable sections. I.E. Like a file like, you can click on a - by the line 'sub something()' and it will compress it too two lines like so:

thus hiding everything in between, so that it is out of the way if you are trying to edit something else.

However... A few problems - I am not sure what Mushclient is sending to the other program or if the glitch is in Scite, but when I tried to used the 'edit script' button under 3.20, (I know, I know, I need to upgrade, but yah haven't fixed all the glitches yet. lol), I end up with:

C:\Program Files\WScite\Files\MUSHClient\AgesScripts.vbs

instead of

C:\Program Files\MUSHClient\AgesScripts.vbs

I also noticed with MUSHClient that if the program you try to use doesn't actually support opening files through COM or Mime that there is no option for using a command line like 'Notepad+ %1'. Hopefully the incorrect directory problem in this case is MUSHClient's fault as much as the editors and can be fixed easy, but if not the assumption that programs used to edit scripts will always be Mime/COM/whatever compliant make a few possible external editors difficult to use and the edit button pointless in those cases.

I just downloaded Scite and tried it as the external editor and it seemed to work fine.

I have changed the code slightly to try to fix your problem.

To open files like that I use ShellExecute. Are you using Windows 2000? It might work slightly differently under that.

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

Here is the code I use to call the editor ...



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.

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.

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.

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

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.

*mutters under his breath for a considerable time*

OK, I have changed the ShellExecute call to plonk quote signs around the filename, like this:



That seems to work for Notepad and Scite.

I have to say it sounds bizarre, normally you don't quote arguments to operating system calls.

Try this:

Using quotes at the DOS command line has been around since the inception of FAT32.

Yes, it's strange to those of us who grew up with FAT16, which was simply FAT back then. :)

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.

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

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.

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 have stopped filing bug reports.

>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

>You do realize this is intentional don't you?

Indeed, yes.