Variable value unexpectedly truncated

[mpiaser]

I have an issue which doesn't make sense.  As you can see in the attachment, the variable SaveFileName contains the value of W:\228\working\open.mrb

but when I issue the statement: Display(5,"MRI Report view" Open,SaveFileName) it displays 8\working\open.mrb

Why are the left five characters being ignored?

[mpiaser]

I wonder if this is related to the newest version of Winbatch.   Was something changed where a backslash in a variable value is interpreted differently?  I'm wonder if W:\228 is being interpreted as some type of escape character?

[td]

Can't reproduce the problem using this very simple script.

Code: Winbatch

SaveFileName = 'W:\228\working\open.mrb'
Display(5,"MRI Report view Open",SaveFileName)

Nothing has changed it WinBatch that word effect how backslashes are handle in string variables and your attachment does not show what the contents of the variable are at the time you pass it to the function.  It just shows the contents of the variable at some point in your script. However, the presence of an ErrorMode function is suggestive...

[td]

Consider stepping through your script one line at a time in the WinBatch Studio debugger.  That way you will be able see the value of your variable change as your script executes.

[mpiaser]

The problem is that the string is being truncated during the SendKeyTo command.  I have tried IntControl functions 34 and 43 but I still get the same results.  I am sending W:\223\Working\NAME.MRB and Winbatch starts typing in the middle of the "working".  I have tried TimeDelays before the SendKeyTo operation too.

Obviously it is a filepath that I'm trying to fill in.  I am able to do a !fo and the path dialog shows up just fine.

[ChuckC]

What application are you sending the key strokes to?

This doesn't seem to be a WinBatch problem, per se, but rather a problem with the application receiving the key strokes possibly misinterpreting what's being sent.  I doubt, tho, that the "\22" is being misinterpreted as an escape sequence, since the value to be substituted at that point would be a double quote character, which doesn't seem to be what's being placed into the file open dialog.  Instead, I'm guessing that there's some sort of delay between when the "!fo" is received and when the file open dialog is actually present and ready to receive input, and the leading part of the path simply isn't being received by the appropriate control on the open/save dialog.

In all cases, wherever possible, don't sent key strokes when you have the possibility of using the Control Manager extender to more precisely automate the control & data entry for an application.

[td]

Have to agree with Chuck.  You likely have either some kind of focus issue in what is likely the File Open common dialog or a problem with how the dialog is processing the keyboard input.  For example, the File Open common dialog does background processing to produce a selection list when you start typing a path in the File name edit box.  This can disrupt timing a bit when the first keys are sent.

[mpiaser]

I changed my code to use ClipPut and then SendKeys for^v and this worked.