It looks like German and Austrian people interpret things different than people from other countries. UltraEdit document properties are of type
String on using the WebView2 engine which we expect of type
Number as it is with SpiderMonkey engine. Here are two more emails which were send by me during the UltraEdit 2024.0 beta testing. There was changed nothing up to the public release of UltraEdit for Windows v2024.0.0.28.
Number instead of string expected for some of the additional document properties
I am testing 64-bit UltraEdit 2024.0.0.21 Beta 3 on Windows 11 23H2.
I wrote this little script using the extended version of
taglist.uet.
Code: Select all
// @Engine=WebView2
var nNumber = 1;
var nAverageLineLength = UltraEdit.activeDocument.averageLineLength;
var nChangedLines = UltraEdit.activeDocument.changedLines;
var nNonEmptyLines = UltraEdit.activeDocument.nonEmptyLines;
var nSourceLines = UltraEdit.activeDocument.sLOC;
var sDateAccessed = UltraEdit.activeDocument.dateAccessed;
var sDateCreated = UltraEdit.activeDocument.dateCreated;
var sDateModified = UltraEdit.activeDocument.dateModified;
var sEnvironmentVariable = UltraEdit.getEnvironmentVariable("username");
var sFileAttributes = UltraEdit.activeDocument.fileAttributes;
var sFileOwner = UltraEdit.activeDocument.owner;
var sLongestLine = UltraEdit.activeDocument.longestLine;
var sSyntaxHighlighting = UltraEdit.activeDocument.syntaxHighlighting;
UltraEdit.outputWindow.write("nNumber = " + nNumber.toString());
UltraEdit.outputWindow.write("nNumber + 1 = " + (nNumber+1).toString());
UltraEdit.outputWindow.write("nAverageLineLength = " + nAverageLineLength.toString());
UltraEdit.outputWindow.write("nAverageLineLength + 1 = " + (nAverageLineLength+1).toString());
UltraEdit.outputWindow.write("nChangedLines = " + nChangedLines.toString());
UltraEdit.outputWindow.write("nChangedLines + 1 = " + (nChangedLines+1).toString());
UltraEdit.outputWindow.write("nNonEmptyLines = " + nNonEmptyLines.toString());
UltraEdit.outputWindow.write("nNonEmptyLines + 1 = " + (nNonEmptyLines+1).toString());
UltraEdit.outputWindow.write("nSourceLines = " + nSourceLines.toString());
UltraEdit.outputWindow.write("nSourceLines + 1 = " + (nSourceLines+1).toString());
UltraEdit.outputWindow.write("sDateAccessed = " + sDateAccessed);
UltraEdit.outputWindow.write("sDateCreated = " + sDateCreated);
UltraEdit.outputWindow.write("sDateModified = " + sDateModified);
UltraEdit.outputWindow.write("sEnvironmentVariable = " + sEnvironmentVariable);
UltraEdit.outputWindow.write("sFileAttributes = " + sFileAttributes);
UltraEdit.outputWindow.write("sFileOwner = " + sFileOwner);
UltraEdit.outputWindow.write("sLongestLine = " + sLongestLine);
UltraEdit.outputWindow.write("sSyntaxHighlighting = " + sSyntaxHighlighting);
It can be seen that I expected the document properties
averageLineLength,
changedLines,
nonEmptyLines and
sLOC as being of type
Number. But the text in the output window on running the script makes it clear that these properties are of type
String because of
+1 results in an append of
"1" to the four variables instead of incrementing their values by one.
I doubt that any UltraEdit script writer expects in future these properties as strings with the requirement using
parseInt() for doing something with the values of these properties other than writing them into a file, the output window or a message box which would work in most cases also with numbers without using explicitly
toString().
Well, it can be documented that these four properties are of type
String.
I suggest nevertheless to change the type of the four new document properties
averageLineLength,
changedLines,
nonEmptyLines and
sLOC from
String to
Number.
Better format for string value of scripting document property longestLine
I am testing 64-bit UltraEdit 2024.0.0.17 Beta 2 on Windows 11 23H2 and Windows 7.
I used in my UltraEdit Beta test script for the additional properties:
Code: Select all
UltraEdit.outputWindow.write("Longest line: " + UltraEdit.activeDocument.longestLine);
The output with usage of WebView2 JS engine is:
The format of the string value of document property
longestLine is not good for further processing it.
Better would be
instead of
as that would make it possible to use in the script:
Code: Select all
var asLongestLineData = UltraEdit.activeDocument.longestLine.split(" ");
var nLongestLineNumber = parseInt(asLongestLineData[0],10);
var nLongestLineChars = parseInt(asLongestLineData[2],10);
There are more lines needed with not looking good "
9(103 chars)" to get the line number of the longest line and the number of characters in the longest line as integer values.
"
9 / 103 chars" looks also better in my opinion.
I suggest for that reason to change the string value of document property
longestLine to format "
line number /
character number chars" if that is easy possible for the developers.