file manipulator object bugs

I have been messing with the file manipulator object trying to figure out how it is used, so I can document it... I have been running into some strange bugs with it and was wondering if someone could take a look. When I run it in the debugger it has different behavior than when I run it normally. Also, not all fields are being printed out in the dataBox editbox.

Here is the .cap:http://www.box.net/shared/n2afjo79eq

Here is the text file I have been using: http://www.box.net/shared/d8e06jmknr

bump.... certainly somebody uses the file manipulator. or has it been deprecated in favor of the build in system text commands?

I had a look at your cap. I'm afraid I can only confirm that the text manipulator is buggy.

Try changing the order of the sub-events 3 and 4 and you'll get the two lines that were missing before - but the other are then missing. By changing the order of the subevents you can even get the preview to crash.

Basically I would say, that it has something to do with the mixture of accessing the lines with getstring and getsubstring, espacially using the |For each substring|-condition. Somehow Construct gets confused by this.

For example, I have set up a new textfile with six lines in the format "Line 1: One" and so on through "Line 6: Six". If I only use |For each substring delimited by ":"| in the |on line read| event, and set the action to append...

TextManipulator.GetSubstring(":", 1) & ":" & TextManipulator.GetSubstring(":", 2) & NewLine[/code:1rsz3y9h]
or

[code:1rsz3y9h]TextManipulator.Getstring & NewLine[/code:1rsz3y9h]

...I get exactly the lines 1, 3 and 5 of the textfile, missing every second line. But when I copy the event and let Construct do the same thing twice, I get all lines from 1 to 6 and in the right order!

I would say, if this isn't reported as a bug yet, you should do so and then wait with the documentation until it is fixed

Thanks Tulamide. I was afraid that was the answer. I'll submit a bug if there isn't already one.