Does ReadFile truncate the data? (no but VAREXPLICIT=1 helps

[Baldrik]

Hi,
Hoping it's ok to keep raising issues here... (or: and another thing...)


I have an application who's data looks like text but isn't, ie GetWindowText comes back with nothing (G..Text works ok on other windows, this isn't the point). However, the application has its own macroised way of creating a file with the window's data, and I have been able to make MSched drive that function.

Now (this is the point), I'm having a problem reading all of it into MSched, so I can test it (with Position) for a particular string which will determine what the MSched script will do next. I seem to get 258 bytes only.

The data is all ascii printable stuff, but the file is around 2000 bytes and has only 1 set of crlf's, at the end.

Should FileSize give the same length as Length of the result of a ReadFile?? ie shouldn't I see the same number in both boxes produced by this...

let>filename=c:\name-of-file-with-size-2000.txt
filesize>%filename%,s
ask>filesize of %filename% is %s%,ok
readfile>%filename%,text
length>%text%,l
ask>length of %filename% text is %l%,ok



If truncation is meant to happen, I'd be grateful to be pointed at another method to test this file (and maybe someone could say what the limit is).


Thanks

[Me_again]

I tested your code with text files up to something over 3 megs and it worked perfectly for me = always same number displayed in the 2 boxes.

Something strange in your file maybe?

[Guest]

Thanks for that, I took out too much, sorry, please can you try this:


//make a file with 28 bytes for testing readfile and variable reuse
let>filename=c:\temp.txt
deletefile>%filename%
writeln>%filename%,rc,qwertyuiopasdfghjklzxcvbnm

//see that it's size is 28 and that readfile can work
filesize>%filename%,siz
ask>filesize of %filename% is %siz%,ok
readfile>%filename%,val
ask>good value from readfile is %val%,ok
length>%val%,len
ask>good length from readfile is %len%,ok

//mess around with the value variable a bit - use it for getwindowtext
//let>val=abcdef
getactivewindow>temp,x,y
getwindowtext>%temp%,val
ask>value from getwindowtext is: %val%,ok
length>%val%,len
ask>length from getwindowtext is %len%,ok

//reuse value variable as the result for a readfile
readfile>%filename%,val

//see the readfile didn't changed the value
ask>wrong value after readfile is %val% (value still from getwindowtext),ok
//but did changed the length of the value (??)
length>%val%,len
ask>wrong length after readfile is %len% (length still from getwindowtext),ok

//try readfile after let
let>val=abcd
readfile>%filename%,val

length>%val%,len
ask>length after let and readfile is %len% (ok from readfile),ok
ask>wrong value after let and readfile is %val% (value still from let),ok


Did I do it wrong, or is it broken?

[Me_again]

I'm seeing the same thing you are, readfile> is not correctly resetting the value(s) of val, assigned with let/getwindowtext.

[support]

ReadFile is seeing val as a variable. It is setting the file contents to a variable named the value of val. So in your example below readfile is creating a new variable called abcd which the file content is set to:

let>val=abcd
readfile>%filename%,val

This is undesirable, but not too big an issue - just make sure you always use a unique variable name that hasn't been created yet:

let>val=abcd
readfile>%filename%,filecontent

I'll make sure that at the next release we change this so that val is always reset.

[Baldrik]

Thanks. I've now spotted this:

Let>VAREXPLICIT=1

in the manual, and seen it seems to fix the problem. (by causing text or variable names to stay as coded unless contained within %'s).

I think I would have had this (the =1 effects) as the default. The =0 allows code to be less cumbersome (less %'s) but to some extent also makes it less predictable (ie by default, there seems always to be a risk that a variable's value could happen to become unintentionally equal to the name of another variable name??)

Not finding this for a while has caused a few problems, I started out thinking that everywhere I didn't put % around something it would be taken always as literal text. Now I realise the default action is different - the default (ie with VAREXPLICIT=0) is to always see if a piece of what would otherwise be text happens to also be the name of a variable, and if so get the string value from the variable and repeat the process, seeing if that's a variable name etc.

However, this =0 default effect can also be a very useful feature - it enables variablevariables, ie computed variable names etc. Just wish I'd seen it in the pdf manual sooner. I missed it because during learning this language, I mainly kept a the pdf open at the Script Commands page, with the direct links to all the commands, and sometimes open at the System Variables page, but had not seen the bit about (system variable:) VAREXPLICIT because it's not actually in the list of system variables, it's just above them!

So, VAREXPLICIT=1 for me from now on, unless wanting to deliberately using computed variablenames!