Loading ...
Sorry, an error occurred while loading the content.

Re: [Clip] Get Fully Qualified File Name

Expand Messages
  • Alan C
    ... near start of clip it does have those. But clip then converts those long into shortname [^$GetShort( ^%File1% )$] So, added a line, saves into longName
    Message 1 of 11 , Apr 19 1:41 AM
    • 0 Attachment
      R Shapp wrote:

      >Hi Group,
      >
      >I'd like to modify the "Compare two files" clip that is supplied with the
      >Utilities clipbook to show fully qualified files names.
      >
      near start of clip it does have those. But clip then converts those
      long into shortname [^$GetShort("^%File1%")$]

      So, added a line, saves into longName variables *before* this shortname
      conversion.

      then near end of clip, once the output doc is open, replace back the
      short with the long.

      1 line added near beginning. 6 lines added near the end.

      (untested) and longName2 isn't handled yet nor is the word "and" deleted
      from your output. But it does at least do part of what you wanted.

      Clip code stuff next:


      ;End the procedure if no file is specified
      ^!IfTrue ^$IsEmpty("^%File1%")$ End

      ; next line added (prior to getshort operation)
      ^!Set %longNam1%=^%File1%; %longNam2%=^%File2%


      ;Set output file name in a variable
      ^!Set %OutputFile%=^$GetName("^%File1%")$.dif
      ;Convert long file names to DOS short names
      ^!Set %File1%=^$GetShort("^%File1%")$

      ; ---------------------------------------------------
      ; clip code same as before
      ; ---------------------------------------------------

      ;Open the output file if it exists or show error message
      ^!IfFileExist ^%OutputFile% Next ELSE Error
      ^!Open ^%OutputFile%

      ; next 6 lines added
      ^!Delay 4
      ^!Jump DOC_START
      ^!Replace "Comparing files " >> "^%EMPTY%" IS
      ^!MoveCursor +1
      ^!Select WORD
      ^!Replace "^$GetSelection$" >> "^%longNam1%" IS


      ^!Goto End

      :Error

      ; code same as before

      ---------------------------------------------------------
      ---------------------------------------------------------
      Alan.
    • R Shapp
      Hi Alan, Thanks for the help with modifying the Compare two files clip. Your code worked fine. I added some extra words and white space. Both long file names
      Message 2 of 11 , Apr 20 4:17 PM
      • 0 Attachment
        Hi Alan,

        Thanks for the help with modifying the Compare two files clip.

        Your code worked fine. I added some extra words and white space. Both long
        file names are now being displayed.

        The clip still needs a tweak because when the file names are relatively short
        like C:\Trial 1 and C:\Trial 2 I get the "File comparison failed" message.

        When the file names are long, I get some extra output that looks like leftover
        text generated by the original clip. See the output of a comparison of long
        file names immediately below my signature. Below that, you will see the
        modified clip based on your previous message.

        I suspect that suppressing the extra output will also solve the failed
        comparison problem.

        Thank you for any further help.

        Ray Shapp

        ******Sample output begins on next line***********
        C:\Documents and Settings\RAS\Desktop\plain_black.css
        and
        C:\Program Files\Easy Imager\Templates\plain_black.css
        were compared with the following result:

        .css and C:\PROGRA~1\EASYIM~1\TEMPLA~1\PLAIN_~1.CSS
        FC: no differences encountered


        ******Modified portion of clip begins on next line*******
        ^!Delay 4
        ^!Jump DOC_START
        ^!Replace "Comparing files " >> "^%EMPTY%" IS
        ^!MoveCursor +1
        ^!Select WORD
        ^!Replace "^$GetSelection$" >> "^%longNam1% ^Pand^P" IS
        ^!Replace "^$GetSelection$" >> "^%longNam2% ^pwere compared with the following
        result:^p^p" IS
      • Alan C.
        ... C: Trial 1 I don t understand. That does not look like a file name to me. ... I think the dos fc utility outputs that text. And, unless some programmer
        Message 3 of 11 , Apr 22 1:10 AM
        • 0 Attachment
          On Wed, 20 Apr 2005 19:17:47 -0400, R Shapp wrote:

          > The clip still needs a tweak because when the file names are relatively short
          > like C:\Trial 1 and C:\Trial 2 I get the "File comparison failed" message.

          C:\Trial 1

          I don't understand. That does not look like a file name to me.

          >
          > When the file names are long, I get some extra output that looks like leftover
          > text generated by the original clip.

          I think the dos fc utility outputs that text. And, unless some programmer builds a custom replacement for the fc.exe then likely we cannot stop that. however, You're right, the text wasn't being replaced or removed. we can replace or remove.

          > ******Modified portion of clip begins on next line*******
          > ^!Delay 4
          > ^!Jump DOC_START
          > ^!Replace "Comparing files " >> "^%EMPTY%" IS
          > ^!MoveCursor +1
          > ^!Select WORD
          > ^!Replace "^$GetSelection$" >> "^%longNam1% ^Pand^P" IS
          > ^!Replace "^$GetSelection$" >> "^%longNam2% ^pwere compared with the following
          > result:^p^p" IS

          ; new modified to replace the former modified------
          ^!Delay 4
          ^!Jump DOC_START
          ^!Replace "Comparing files " >> "^%EMPTY%" IS
          ^!MoveCursor +1
          ^!Select WORD
          ^!Replace "^$GetSelection$" >> "^%longNam1%^Pand^P" IS
          ^!Insert "^%longNam2%^pwere compared with the following result:^p^p"
          ^!Find "^pFC: " IS
          ^!Jump SELECT_START
          ^!DeleteLine
          ^!Save

          Try ^^_that_^^, swap the above out for your: "Modified portion of clip begins . ." as enclosed from you further above. The new modified works here.

          Because there was no longer any selection when the second replace line goes to task it was not correct to use getselection again. In doing so, it was acting like Insert since there was no selection that is why I changed the second replace line to an Insert line (more correct though the old/former ultimately accomplished the same thing).

          my email client when I receive, it messes up Replace lines in clips. I hope it does not do this when I send. So, if you have a problem, the very first thing is to closely inspect the replace line.

          Try: shift + F12

          those keys. That toggles the non printing so that you can visually see the space characters. a space shows as a dot. when messed up as I had reported, the replace line contains space that shows *without* a dot even while all other spaces show with a dot. That is char 26. masquerades as a space. easy to remedy. just place cursor at back edge then strike the backspace key then strike the space bar and you're done.

          But you may not get any. It may not do it when I send. But oh, does it ever do it when I receive!

          Thanks. Alan.
        • R Shapp
          Hi Alan, Thanks for the revision to the revision! 1. My email client doesn t alter incoming message. 2. The file names were actually Trial 1.txt and Trial
          Message 4 of 11 , Apr 22 4:01 AM
          • 0 Attachment
            Hi Alan,

            Thanks for the revision to the revision!

            1. My email client doesn't alter incoming message.

            2. The file names were actually "Trial 1.txt" and Trial 2.txt" I
            inadvertently omitted their extensions.

            3. The blank space in the file names was causing the "File comparison failed"
            message. I thought it was possible to run the comparison with the file names
            in double quotes, but the DOS FC program refuses to handle file names
            containing blank spaces even after enclosing the file names within double
            quotes.

            To test this, I opened a DOS window and changed to the directory where both
            "Trial 1.txt" and Trial 2.txt" are stored. The following DOS command didn't
            produce any output at all:

            FC "Trial 1.txt" Trial 2.txt"

            When I renamed the two files "Trial1.txt" and "Trial2.txt" the modified clip
            ran just fine.

            Different question: In trying to understand how this (or any other) clip
            runs, is there a "debug" mode I can set in order to see the result of the
            execution of a single step at-a-time?

            Thanks again.

            Ray Shapp
          • Alan C
            ... FC Trial 1.txt Trial 2.txt You are missing one quote there on trial 2. that is what I wondered is if quotes might work. At first I thought it odd that
            Message 5 of 11 , Apr 22 4:00 PM
            • 0 Attachment
              R Shapp wrote:

              >[ . . ]
              >3. The blank space in the file names was causing the "File comparison failed"
              >message. I thought it was possible to run the comparison with the file names
              >in double quotes, but the DOS FC program refuses to handle file names
              >containing blank spaces even after enclosing the file names within double
              >quotes.
              >
              >To test this, I opened a DOS window and changed to the directory where both
              >"Trial 1.txt" and Trial 2.txt" are stored. The following DOS command didn't
              >produce any output at all:
              >
              >FC "Trial 1.txt" Trial 2.txt"
              >
              >When I renamed the two files "Trial1.txt" and "Trial2.txt" the modified clip
              >ran just fine.
              >
              >

              FC "Trial 1.txt" Trial 2.txt"

              You are missing one quote there on trial 2. that is what I wondered is
              if quotes might work.

              At first I thought it odd that the getshort in the clip didn't eliminate
              the space (somehow) but maybe it is unable to do so the reason might be
              that dosname is 8 characters or less on the left hand side, up to the
              dot. And, space included, you are at 7 characters which already is
              equal to or shorter than 8.

              You may be stuck with having to rename them.

              >Different question: In trying to understand how this (or any other) clip
              >runs, is there a "debug" mode I can set in order to see the result of the
              >execution of a single step at-a-time?
              >
              >
              In clip help I clicked the search tab then entered debug and up came

              ^!SetDebug

              amongst some others. (that is debug) I haven't used debug much. But
              perhaps I should try it again and re asses whether I need to use it more
              or not.

              I've opted mostly to make use of a stop point:

              ^!Goto end

              wherever that is placed then you can visually see (if selected, how much
              selected, cursor position, etc. these sorts of things). If it's doing
              as expected up to that point then move that goto end line further up and
              run again. In this way you can pinpoint where the problem begins in a
              clip. sometimes I use ^!Delay 10

              that pauses long enough between each clip code line so the user can
              visually see on the screen what is happening.

              ^!Replace "^p" >> "^p^!Delay 10" ISH

              Select a few lines then run that if you'd like to do so. It will put
              delays in.
              --

              When I write clips, I think modular. I begin small. I test a lot. If
              a problem comes up I deal with it right then and there. In this way, I
              cannot get more than one problem at a time to troubleshoot. The problem
              has to have something to do with the most recent line or lines of code
              that I have added to the clip.

              Programming tends to teach that. I took an algorithm class for
              programming. This class said: (after you have your plan) build in
              pieces. test each piece. glue some pieces together then test again.
              then glue some more pieces together then test again. In clips I've
              found that goto end and labels can keep separated such pieces as I speak
              of. Removal of the "goto end" equates to "gluing together"

              ^!Info ^%my_variable%

              that's handy so as to see the content of a variable.

              And I'm sure that others can add yet even more onto these that I've listed.

              Alan.
            • R Shapp
              Hi Alan,
              Message 6 of 11 , Apr 23 1:30 AM
              • 0 Attachment
                Hi Alan,

                <<FC "Trial 1.txt" Trial 2.txt">>

                The missing double quote was a typo in my email to you but not in the DOS
                command as actually entered. I noticed the typo after I sent the message.


                I also found ^!SetDebug, however, I was using it incorrectly. I was leaving
                off the parameter "ON". ^!SetDebug alone does nothing. Your comment sent me
                back to the Help system where I found my error.

                ^!SetDebug on is hard to follow. I am now printing the clip before I run it
                in debug mode. My next move was to display a copy of the clip on a second
                networked PC sitting next to my primary PC. I notice that the line numbers
                reported by debug are off a tiny bit. That's probably because of the way NTP
                counts blank lines (or maybe it's line wrap). I'm still experimenting with
                this.

                Thanks again for all the help and the ideas about setting stop points etc.

                Best regards,

                Ray Shapp
              • hsavage
                ... run it ... second ... numbers ... way NTP ... experimenting with ... etc. ... Ray, Correct line counts are obtained with Wordwrap OFF, any txt/html file
                Message 7 of 11 , Apr 23 6:16 AM
                • 0 Attachment
                  R Shapp wrote:

                  > ^!SetDebug on is hard to follow. I am now printing the clip before I
                  run it
                  > in debug mode. My next move was to display a copy of the clip on a
                  second
                  > networked PC sitting next to my primary PC. I notice that the line
                  numbers
                  > reported by debug are off a tiny bit. That's probably because of the
                  way NTP
                  > counts blank lines (or maybe it's line wrap). I'm still
                  experimenting with
                  > this.
                  >
                  > Thanks again for all the help and the ideas about setting stop points
                  etc.
                  >
                  > Best regards,
                  >
                  > Ray Shapp

                  Ray,

                  Correct line counts are obtained with Wordwrap OFF, any txt/html file
                  you're manipulating should have ^!SetWordWrap 0 strategically placed in
                  the clip before beginning to operate on the file.

                  ºvº
                  05.04.23
                  hrs > hsavage@...
                • R Shapp
                  Hi HRS,
                  Message 8 of 11 , Apr 24 2:57 AM
                  • 0 Attachment
                    Hi HRS,

                    <<any txt/html file you're manipulating should have ^!SetWordWrap 0
                    strategically placed in the clip>>

                    Thanks for the tip, Harvey. What do you mean by "strategically"? What would
                    be wrong by placing the command as the very first executable statement? Also,
                    is there any harm in leaving it in the clip after all development and
                    debugging are finished?

                    Regards,

                    Ray Shapp
                  • hsavage
                    ... What would ... statement? Also, ... Ray, By Strategically placed I mean, ^!SetWordWrap 0 or ^!SetWordWrap OFF should be placed immediately after loading
                    Message 9 of 11 , Apr 24 6:40 AM
                    • 0 Attachment
                      R Shapp wrote:

                      > Hi HRS,
                      >
                      > <<any txt/html file you're manipulating should have ^!SetWordWrap 0
                      > strategically placed in the clip>>
                      >
                      > Thanks for the tip, Harvey. What do you mean by "strategically"?
                      What would
                      > be wrong by placing the command as the very first executable
                      statement? Also,
                      > is there any harm in leaving it in the clip after all development and
                      > debugging are finished?
                      >
                      > Regards,
                      >
                      > Ray Shapp

                      Ray,

                      By 'Strategically placed' I mean, ^!SetWordWrap 0 or ^!SetWordWrap OFF
                      should be placed immediately after loading the subject file.

                      If the file to be edited is already loaded you can place the command at
                      the beginning of the clip, but, if you're going to load the file in the
                      course of clip operation wordwrap needs to be turned off after the
                      subject file is loaded.

                      If the file you're editing was last saved with wordwrap ON, wordwrap
                      will still be ON when the file is reloaded.

                      ºvº
                      05.04.24
                      hrs > hsavage@...
                    • Alan_C
                      R Shapp wrote: [ ^!Setwordwrap OFF ] Also, ... The goal is to leave it in the clip. There can be exceptions to the goal/rule. But unless you know that an
                      Message 10 of 11 , Apr 24 1:21 PM
                      • 0 Attachment
                        R Shapp wrote:
                        [ ^!Setwordwrap OFF ] Also,
                        > is there any harm in leaving it in the clip after all development and
                        > debugging are finished?

                        The goal is to leave it in the clip. There can be exceptions to the
                        goal/rule. But unless you know that an exception warrants leaving it
                        out then it's safest to keep it in.

                        If you go to the web archives for this list and search for such things as:

                        wordwrap

                        word wrap

                        setwordwrap

                        It's very likely that you'll find even more about this topic.

                        Alan.
                      Your message has been successfully submitted and would be delivered to recipients shortly.