Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ General ➜ Just found this...
Just found this...

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  

Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Tue 21 May 2002 07:22 PM (UTC)

Amended on Tue 21 May 2002 07:40 PM (UTC) by Shadowfyr

Message
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:

+ sub something()
  end sub

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.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #1 on Wed 22 May 2002 02:04 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #2 on Wed 22 May 2002 05:51 PM (UTC)

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
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #3 on Wed 22 May 2002 10:35 PM (UTC)
Message
Here is the code I use to call the editor ...


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #4 on Wed 22 May 2002 11:24 PM (UTC)

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.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #5 on Wed 22 May 2002 11:46 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #6 on Thu 23 May 2002 03:20 AM (UTC)
Message
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. ;)
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #7 on Thu 23 May 2002 05:35 AM (UTC)
Message
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.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #8 on Thu 23 May 2002 05:45 AM (UTC)

Amended on Thu 23 May 2002 06:14 AM (UTC) by Nick Gammon

Message
*mutters under his breath for a considerable time*

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


if ((long) ShellExecute (Frame, _T("open"), m_strScriptEditor, 
          CFormat ("\"%s\"", (LPCTSTR) m_strScriptFilename), 
          NULL, SW_SHOWNORMAL) <= 32)
  ::AfxMessageBox("Unable to edit the script file.", 
                  MB_ICONEXCLAMATION);


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #9 on Thu 23 May 2002 01:58 PM (UTC)
Message
Try this:

C:\> cd program files
Too many parameters - files
C:\> cd "program files"
C:\Program Files>

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. :)
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #10 on Thu 23 May 2002 09:43 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #11 on Thu 23 May 2002 11:32 PM (UTC)

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
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #12 on Fri 24 May 2002 06:33 AM (UTC)
Message
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.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #13 on Fri 24 May 2002 07:10 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #14 on Sat 25 May 2002 12:32 AM (UTC)
Message
>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
Top

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.

45,281 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home