NULLs are not possible because the Javascript core engine handles strings as NULL terminated character array. So every NULL byte in a character array is automatically the end of the string. IDM can't change this and of course in text files NULL bytes should be never used or present.

Yes, the Javascript engine creates for your example a byte array with correct byte size and property length contains the correct number of bytes for the array. But array property length is not equal the string length for your example. It is the size of the array, not the string length. Try following in a HTML file:
and you will see only "Text 1 is: zero" in the first message box and "Text 1 length is: 9" in the second message box.
The third alert outputs also "Text is: zero" because the strings are correct concatenated, but the NULL character inside the string variable is the terminating character for the print. This is confirmed by the fourth message showing "Text 2 length is: 40".

And yes, the clipboard buffer is just a dynamic memory buffer which can hold also binary data. The clipboard is not a string array, it is a byte array and therefore can contain all values from 0 to 255 which are not special interpreted (normally) as the bytes in a string array are when accessing the data in the array.

UltraEdit.clipboardContent = UltraEdit.clipboardContent;

I'm not wondering that this clears the clipboard content because the clipboard is a dynamically allocated memory buffer using malloc() and free() in 'C' or new and delete in C++ (which uses in the background also malloc() and free()). So when you assign (=copy) a buffer to the clipboard, the first function called is free() to release the existing memory buffer of the (active) clipboard. Now the clipboard buffer pointer is NULL and therefore the next function calls for getting the size in bytes of the new data, allocating the buffer with required byte size from heap and copying the data must fail here. So your line is the same as UltraEdit.clearClipboard(); with the only difference that you test also the error handling of the functions used in the background for handling dynamic memory buffers.

However, the problem you have here is not the Javascript engine and how it handles bytes with value 0. The problem is that UltraEdit stops character copying from the clipboard buffer to the file buffer in text mode on first ocurrence of a NULL byte which is in my point of view a correct behavior because NULL bytes are binary bytes and should not exist in a text file (except in UTF-16 files). For example if you create a new file, write some text, switch to hex edit mode, replace 1 character with 00, select all bytes in hex edit mode, turn off hex editing and paste now the clipboard content into the file in text edit mode, UltraEdit pastes only the text left the NULL byte. But when you now switch again into hex edit mode and paste the clipboard content, you will see that the clipboard contains really all bytes because all of them are inserted in hex edit mode.

999999 wrote:Actually, the first alert prints different text on different browsers. IE and Opera print "one", while Firefox and Chrome print "onetwo". That's because the alert function works in different manner on these browsers, that's all. Javascript have all the data, and the second alert can prove that.

Yes, that's what I wanted to explain. The array contains all bytes, but how the bytes are interpreted on read depends on the interpreting functions. In C/C++ a NULL terminated string (not a Unicode string) is always printed from first byte to the first occurrence of a byte with value 0. Of course a very dangerous definition if somehow the NULL byte was overwritten before which can easily happen on string manipulations. IE and Opera (= my preferred browser) are handling it in this way in the alert() function. Unicode string arrays contain an extra length property which is used also for printing Unicode strings. It looks like Firefox uses this length information for printing in the alert() function. I don't know which implementation is correct for JavaScript and of course it is not important for this issue here.

999999 wrote:That's not related to the topic. C and Javascript have different rules, although they have a similar syntax.

Yes, that is not related to the topic. But you asked why the second paste inserted nothing and I give you the answer. UltraEdit.clipboardContent is not a core JavaScript function, it is a function implemented by IDM written in C++. However, I'm quite sure that the methods how to handle dynamic memory buffers are the same in all programming languages and of course the JavaScript engine used by UE/UES is written probable also in C/C++. But I don't know exactly.

999999 wrote:Which proves that the behavior of UltraEdit.clipboardContent is not a correct behavior of a Javascript string, and (first post again) - "UltraEdit.clipboardContent won't accept NULL char"

As I can see on your code I have to agree that the string with the NULL byte is different handled by the clipboardContent function written by IDM in comparison to the dynamically created string variable arrays by the JavaScript core engine. And I agree now that maybe this is a lack in program code of UE/UES. But only the IDM developers can look into this issue and find out were the truncation of the string with the NULL byte occurs.

But I guess the priority to look into this issue is very low for IDM because who really needs to use the clipboard with strings including NULL bytes with that method?

Aha! You want to write a script which converts an ASCII string with hexadecimal values into binary data.

What about using a special ASCII character sequence for a NULL character like #!? and finally run in hex edit mode a hexadecimal replace all to convert every occurrence of this special character sequence into a NULL byte as workaround. For example with following scripting code at the end of your script:
You can use a longer, more complicated place holder string if you think this sequence could exist in the data.

You may also look on Paste hexadecimal.

Please report this program bug by email to IDM. Thanks.