I can't work out the new date format code

Apologies — I'm bushed with the new Format method for dates that came out today in V12.0.12. The following code snippet:

var dDate = new Date (oFSOFile.DateLastModified) DOpus.Output ("The day is " + dDate.getDate () ) var sNewString = dDate.Format("D#yyyy-MM-dd T#HH:mm:ss") DOpus.Output ("The new string is " + sNewString) has output:
The day is 25
Error at line 1400, position 9 [that's the 3rd line above]
Object doesn't support this property or method (0x800a01b6)

The first two lines are only there to prove that dDate is indeed a valid date object. The code in the third line after 'dDate' is copied and pasted from the installed manual at Scripting Objects --> Date --> Format.

Changing the third line to var sNewString = dDate.Format() gives exactly the same error message.

new Date is creating a JScript Date object, not an Opus one. The Opus one is created by the DOpusFactory.Date method.

Thanks, Jon. That was pretty subtle, but now that I know, I'll be able to sort it out in the morning. You may want to add this warning to the Manual, because it's not always clear to us non-techies what is JScript and what is DOpusJScript.

By the way, congratulations on this great innovation in V12.0.12. It sidesteps all the turgid succession of myDate.getWhatever() commands that were needed previously. (No doubt you have written them behind the scenes.)

There's no such thing as "DOpusJScript" :slight_smile:

Supplementary question on milliseconds. I can get milliseconds out of the DOpus date object by doDate.ms, and then I can buffer it to three digits if I want. But I can't do it using the excellent new Format method.

If the new Format method does not provide a quicker way to get milliseconds out — and I am painfully aware that I may have missed it — could I suggest that milliseconds be handled within the Format code in the same way as hours, minutes and seconds with:

  • l as the code for milliseconds
  • lll as the code for milliseconds buffered to three digits.
    (Milliseconds are needed, for example, when creating and naming temporary files in quick succession.)

I'm not against formatting milliseconds differently, I just want to make a smart ass comment regarding your sentence. o)
I would always go for an (additional and trailing) random string in these scenarios, since even milliseconds might not be precise enough, multithreading kicking in etc.

Thanks tbone — good point! Even ignoring multithreading, these machines today are unimaginably fast. (And 0.001 seconds will be a lifetime if fullscale quantum computing ever kicks in.)

For a temp folder/file, you could use GetTempName from Windows. I am not sure how guaranteed that is not to clash, but anything you use to generate a name could clash in theory. To be certain there isn't a clash, you always need to check if the name exists already, and loop through something that modifies it until you get a name that isn't there.

Even then, if two things are running in parallel, you don't know your name is unique until you successfully create the item in the filesystem. Two things running in parallel could both generate the same name at the same time, and both see there isn't currently anything with that name, then both try to use/create the same name and trip each other up.

So I am not sure adding milliseconds to the format strings is the right answer here. The underlying problem would still be there, and it's best to address that directly.

Thanks, leo, I really appreciate these remarks — the GetTempName method is new to me. The thing I really enjoy about this forum is that you learn things every time you ask a question. My original intention was simply to do my job as a beta tester, and report that it would seem more straightforward if milliseconds were handled within Format by coding similar to the other six units of time.

Now this is getting offtopic, but for the sake of completeness and for people searching the forum. Here is a little function to get a temporary filename, taken from one of the script addins. It also makes use of the system temp folder automatically and the object returned provides separated filename, folder and fullpath for easier handling.

/////////////////////////////////////////////////////////////////////////////// function CreateTmpFileName(prefix, extension, fso) { if (!fso) fso = new ActiveXObject("Scripting.FilesystemObject"); var tFolder = fso.GetSpecialFolder(2); // 2 = temp folder var tFile = fso.GetTempName(); if (prefix!=undefined) tFile=prefix+tFile; if (extension!=undefined) tFile+=extension; return { path:tFolder.Path, name:tFile, fullname:tFolder.Path+'\\'+tFile}; }
Basic usage like this will result in a filename and path (mostly random) like C:\TEMP[b]radD7B2T.tmp[/b].

var tmpFile = CreateTmpFileName("DO.Temp.", ".txt").fullname;

Using it like this though, returns a filename which is only partly random C:\TEMP[b]DO.Temp.radF5B3E.tmp.txt[/b]. I prefer this usage, since post- and prefixed tmp-files are easier to track, mass/auto-delete, lookup, open (due to the proper extension) etc.

var tmpFile = CreateTmpFileName().fullname;