Custom Query (3933 matches)

When passing a RFC3339 formated date-time string to _DateTimeSplit, the seconds are ignored.

_DateTimeSplit("2019-03-07T20:31:30Z", $aDate, $aTime) Returns correct $aDate, but $aTime[3] = 0

Solutions:

• StringLeft($sDateTime, 19)
• Or make a more complete function that will completely support RFC3339 date-time (with miliseconds/nanoseconds...)

After months of observing an odd problem when clearing the text in a RichEdit control, I isolated the statements involved: _GUICtrlRichEdit_SetSel($hEdit, 0, -1, True) _GUICtrlRichEdit_ReplaceText($hEdit, "")

The odd part is that every now and then (a third of the time?) the text of the button I use to invoke those statements replaces the contents of the windows clipboard. In other words, if "Clear Text" is the text on the GUI button, then "Clear Text" shows up on the windows clipboard. Strange.

I replaced those statements in the particular script I am working on with: _GUICtrlRichEdit_SetText($hEdit, "") ... which works.

I realize this is an obscure problem, but the next time someone works on the _GUICtrlRichEdit features, they might want to look at it. For now, I'm fine.

The current example of StdoutRead is parsing the input of the Run-command wrong. It's this block in particular.

; Use StringSplit to split the output of StdoutRead to an array. All carriage returns (@CRLF) are stripped and @CRLF (line feed) is used as the delimiter.
Local $aArray = StringSplit(StringTrimRight(StringStripCR($sOutput), StringLen(@CRLF)), @CRLF)

The comment is wrong too. All carriage returns are stripped but carriage returns are @CRs not @CRLFs. @CRLF (line feed) is also wrong.

If you break up the commands line by line it looks like this:

Local $sStrippedCR = StringStripCR($sOutput)

Local $sTrimmed = StringTrimRight($sStrippedCR, StringLen(@CRLF))

Local $aArray = StringSplit($sTrimmed, @CRLF)

What happens?

L 1: All @CRs are removed from the string L 2: 2 characters are removed from the right side of the string although only @LFs are left therefore resulting in cutting away one character from the last array entry (which gets created now) L 3: Split the array with @CRLF. Since no third parameter is provided $STR_CHRSPLIT is provided which results in a still-decently-split array.

The error probably wasn't noticed due to $STR_CHRSPLIT still splitting the array (with @CR and @LF) and the very last character missing of the array entry which you only see if you pay attention.

I don't know who came up with the wrong line but he must have been on drugs or something. Windows (AutoIt doesn't run natively on other operating systems) uses @CRLF by standard and we are parsing from a windows command anyway. Instead of complicating the whole operation with StringStripCR we could've made it so much easier:

How to fix?

Local $aArray = StringSplit(StringTrimRight($sOutput, StringLen(@CRLF)), @CRLF, $STR_ENTIRESPLIT)