Split String, bug or feature?

[droodled]

Dear All,

I can't find anything in the help files, or on the forum regarding this, could someone maybe comment. Am I doing something wrong, or is this a bug/feature of the program.

I'm using the T array to temporarily store items from time codes in a subtitle file to be analysed.

With e.g string containing ":" to split upon, and containing 3 parts after splitting. When I start to add that information in position 1 of the T array, it should occupy 1 to 3 in the T array.

-Nothing more, right!!??

In case the array contains other values in 4 and onwards, I found that those will be erased? See also below sample code.

<COMMENT Value="============================================="/>
<COMMENT Value="Variable holding CRLF"/>
<VARIABLE SET TO ASCII CHAR Value="13" Destination="%CRLF%"/>
<VARIABLE SET TO ASCII CHAR Value="10" Destination="%T[1]%"/>
<VARIABLE MODIFY STRING Option="\x07" Destination="%CRLF%" Variable="%T[1]%" NoEmbeddedVars="FALSE"/>
<COMMENT Value="============================================="/>
<VARIABLE SET STRING Option="\x00" Destination="%SRTLine%" Value="00:00:10,500 --> 00:00:13,000  X1:63 X2:223 Y1:43 Y2:58" NoEmbeddedVars="FALSE"/>
<VARIABLE MODIFY STRING Option="\x09" Destination="%T[99]%" Variable="%SRTLine%" Start="1" Count="29" NoEmbeddedVars="FALSE"/>
<SPLIT STRING Source="%T[99]%" SplitChar=" --> " Dest="%T%" Index="1"/>
<SPLIT STRING Source="%T[1]%" SplitChar=":" Dest="%T%" Index="2"/>
<SPLIT STRING Source="%T[4]%" SplitChar="," Dest="%T%" Index="4"/>
<SPLIT STRING Source="%T[99]%" SplitChar=" --> " Dest="%T%" Index="6"/>
<VARIABLE SET STRING Option="\x00" Destination="%T[6]%" Value="%T[7]%" NoEmbeddedVars="FALSE"/>
<SPLIT STRING Source="%T[6]%" SplitChar=":" Dest="%T%" Index="7"/>
<SPLIT STRING Source="%T[9]%" SplitChar="," Dest="%T%" Index="9"/>
<MESSAGEBOX Caption="Variable T99 was erased during Splt String command!!!???" Message="%T[1]%%CRLF%%T[2]%%CRLF%%T[3]%%CRLF%%T[4]%%CRLF%%T[5]%%CRLF%%T[6]%%CRLF%%T[7]%%CRLF%%T[8]%%CRLF%%T[9]%%CRLF%%T[10]%%CRLF%%T[11]%%CRLF%%T[12]%" Icon="4"/>

T99 was erased, causing the 2nd part of the macro code to not work.

-Is this normal behavior (feature), or a problem (bug)?

I've changed my macro code to circumvent this, but it makes it all more complex, and thus needs more variables.

Thanks for any hints/tips

Best regards,

[Samrae]

I am sure that is intentional. What if you have a series of Splits or if you have a variable amount of data? You wouldn't want an entry in, say, T[15] to be left over from a previous split. If the split command did not clear the other elements in the array it would require you to do a Clear Variables command prior to any Split command. That would make your macro even more complicated.

 

I think it is a good idea to have separate variables for separate purposes. The named variables feature of Macro Express Pro makes this possible. I would suggest that you define an array variable %TimeCode% and not try to use the T variables for more than one purpose. A big advantage of doing this is that the name of the variable describes what is in it. With Macro Express 3 I used to maintain a set of comments (actually Remarks in ME3) that described what the T variables were used for. Much time was spent referring back to that list and fixing problems where the wrong T variable was accidentally used.

[droodled]

@Samrae,

 

Thanks for your reply, and I understand your point.

 

I could use the same arguments though for the manner in which I wanted to use it. Additionally, you have the clear variable command to clear a variable, even only part of it, thus why would you clear with the split command.

 

There's probably merits for both explanations.

 

The above macro code is only a sample of the processing part for lines read from a subtitle file to be analysed.

 

After processing the actual information is indeed stored in named variables.

 

Due to this problem though, I needed to create additional variables to be used temporarely. Thus making things more complicated, and probably slower.

 

Anyhow, I got around it, but my initial idea would've made things MUCH simpler, and needed less variables.

 

Best regards,