6,681583
Grand MasterGrand Master
6,681583

    Sep 02, 2017#16

    Open the output window on running a script in development to see error message output by built-in JavaScript interpreter.

    The commands work also with UE for Windows v14.10 with exception of command ASCIIToUTF8 which was introduced with UE for Windows v17.30 as it can be read in text file changes.txt in program files folder of UltraEdit v17.30 or any later version.

    The property lineTerminator was introduced with UltraEdit for Windows v16.00. Here is a code which I used several times when a script should work also for very old versions of UltraEdit.

    Code: Select all

    // Determine line termination used currently in active file.
    var sLineTerm = "\r\n";
    if (typeof(UltraEdit.activeDocument.lineTerminator) == "number")
    {
       // The two lines below require UE v16.00 or UES v10.00 or later.
       if (UltraEdit.activeDocument.lineTerminator == 1) sLineTerm = "\n";
       else if (UltraEdit.activeDocument.lineTerminator == 2) sLineTerm = "\r";
    }
    else  // This version of UE/UES does not offer line terminator property.
    {
       if (UltraEdit.activeDocument.selection.indexOf(sLineTerm) < 0)
       {
          sLineTerm = "\n";          // Not DOS, perhaps UNIX.
          if (UltraEdit.activeDocument.selection.indexOf(sLineTerm) < 0)
          {
             sLineTerm = "\r";       // Also not UNIX, perhaps MAC.
             if (UltraEdit.activeDocument.selection.indexOf(sLineTerm) < 0)
             {
                sLineTerm = "\r\n";  // No line terminator, use DOS.
             }
          }
       }
    }
    There must be at least 1 line with line termination selected in active file for else branch.

    The else branch could be optimized by using this code:

    Code: Select all

       var nLineTermPos = UltraEdit.activeDocument.selection.search(/\r?\n|\r/);
       if (nLineTermPos >= 0)
       {
          sLineTerm = UltraEdit.activeDocument.selection.substr(nLineTermPos,2).replace(/^(\r?\n|\r).*$/,"$1");
       }
    That is faster in case of active file has UNIX or MAC line terminators and many lines are selected.
    Best regards from an UC/UE/UES for Windows user from Austria

    81
    Advanced UserAdvanced User
    81

      Sep 03, 2017#17

      Hi Mofi, if I use the below code:

      Code: Select all

      UltraEdit.newFile();
      UltraEdit.activeDocument.unixMacToDos();
      Then why do I need to determine the line terminator of the new file (as I have already converted the file to DOS using UltraEdit.activeDocument.unixMacToDos())?
      Shouldn't the below code be enough to create an array using all the string in the new file?

      Code: Select all

      var sLineTerm = "\r\n";
      var myString = UltraEdit.activeDocument.selection.split(sLineTerm);

      6,681583
      Grand MasterGrand Master
      6,681583

        Sep 03, 2017#18

        Well, a script doesn't need to determine the line terminator type in following two cases:
        1. The script is designed for working only on files of using always same line terminator type like DOS on Windows.

          I'm sure that 99% of all scripts written by users themselves can be written with a hard coded line termination in their scripts.

          Unfortunately when I am writing a script for someone else and publish it in forum I do not know in 99.99% of all cases the line terminator type because of original poster has not mentioned it although I recommended this in the help for newbies announcement. That's the reason why I have to make the scripts I publish independent on expectations on line terminator type of processed file(s). The scripts I use for myself contain always simply \r\n because I have configured UltraEdit and UEStudio to convert always all files to DOS on load and save them with original line terminator type. New files are ANSI files with DOS line terminators. So all the scripts and macros written for myself run definitely always on files with DOS line endings.
        2. The script sets the line terminator type independent on configuration for new file(s) before writing into the new files using always a hard coded line termination.

          On reading back data from a new file, the line terminator type is well known in this case. But I have never written a script which writes something into a file and read it back from file. That is useless as the strings written into the file were once already in string variables in memory. So why should a script write them into a file and read them back to memory?
        I have commented upper half of your script. That is a job the script writer should do and not somebody else asked for help. I'm quite sure that when you read the comments, it becomes clear what are you doing wrong and why the script needs unnecessary long time to finish.

        Code: Select all

        // Select everything in active file.
        UltraEdit.activeDocument.selectAll();
        
        // Copy entire file to active clipboard.
        UltraEdit.activeDocument.copy();
        
        // Load text from active clipboard to string variable my_File.
        /* The selected text could be assigned to string variable my_File
           directly using var my_File = UltraEdit.activeDocument.selectAll();
           The file content in clipboard is not further used in entire script. */
        var my_File = UltraEdit.clipboardContent;
        
        // Define a JavaScript RegExp object to find globally disp-formula
        // starting tags with an identifier deqn with a range specification.
        var my_exp = /<disp-formula id="deqn\d+-\d+">/g;
        
        // Get all strings matching this regular expression.
        var find_exp = my_File.match(my_exp);
        
        // Was any string found at all?
        /* Why !== is used instead of just != is not clear for me. Either variable
           find_exp is a null pointer or it is an array of strings. The extra data
           type check caused by using !== instead of just != is not necessary here. */
        if (find_exp !== null){
        
           // Create a new file with encoding and line terminator type as configured.
           /* If the condition above is not true because a disp-forumla element with a range
              identifier could not be found in file content of active file respectively  in clipboard
              content, no new file is created which results in keeping input file as active file. */
           UltraEdit.newFile();
           /* A new file becomes always automatically the active file. Also the right
              usage of setActive() is something like UltraEdit.document[1].setActive();
              It does not make sense to use setActive() on already active document. */
           UltraEdit.activeDocument.setActive();
        
           // Write each found string into the new file line by line with using just
           // line-feed as line termination.
           /* The new file is hopefully created as UNIX file as this is expected by this code. */
           for (var i=0; i<find_exp.length; i++){
              UltraEdit.activeDocument.write(find_exp[i]+'\n');
        
              /* This line is really useless. It runs the same match as already used
                 above again on entire file content to get again all strings matching
                 the regular expression and replaces the currently processed array of
                 strings with a newly created array of strings with the same strings. */
              find_exp = my_File.match(my_exp);
           }
        }
        
        /* The caret is moved to end of file which is useless on being the new file
           with the found strings written into the file line by line as the caret
           is already at end of this file. But it is also possible that the caret is
           moved to end of input file which results in discarding the selection too. */
        UltraEdit.activeDocument.bottom();
        
        /* In case of active file is the new file, the last line termination is deleted.
           Otherwise the last character at end of input file is deleted without knowing
           what is at end of input file. */
        UltraEdit.activeDocument.key("BACKSPACE");
        
        /* The new file or the input file is converted to DOS. */
        UltraEdit.activeDocument.unixMacToDos();
        
        /* On new file trailing spaces or tabs are removed although it definitely does
           not have trailing spaces or tabs because of the used regular expression.
           But it is also possible that trailing spaces and tabs are remove from input file. */
        UltraEdit.activeDocument.trimTrailingSpaces();
        
        // Select everything in new file or once again in input file.
        UltraEdit.activeDocument.selectAll();
        
        /* Well, the new file is definitely not empty. The active file could have
           been empty, but that was not verified at beginning of the file and so
           it is possible that code above processed clipboard content not copied
           by this script to active clipboard. */
        if (UltraEdit.activeDocument.isSel())
        {
           /* Determine line terminator type of either new file which was expected
              first as being UNIX and was converted next to DOS or of input file. */
           var sLineTerm;
           if (UltraEdit.activeDocument.lineTerminator <= 0) sLineTerm = "\r\n";
           else if (UltraEdit.activeDocument.lineTerminator == 1) sLineTerm = "\n";
           else sLineTerm = "\r";
        
           /* All lines of active document (new file or input file) are loaded now
              into an array of strings with each line being a string in the array
              with strange name myString. In case of active file is the new file,
              the string array myString contains the same strings as the string
              array find_exp created multiple times above. */
           var myString = UltraEdit.activeDocument.selection.split(sLineTerm);
        }
        Best regards from an UC/UE/UES for Windows user from Austria

        Read more posts (-12 remaining)