Setting text file parameters with Visual Fox Pro 5.0/Windows 7.0

[njsandor]

I just transferred my VFP program to Windows 7.0 and it is running fine. I suspect this question involves the operating system rather than VFP. When I create text files for transmission, it creates text file with Notepad. The default margins and font size are different on the new operating system. As this file is used as a template for transmission, I want to know: how do I confirm if notepad is indeed being used, how do I adjust default margins and font size in this program?

 

[njsandor]

Thanks to everyone for their feedback on this problem.

I changed notepad's font size in Windows 7.0 to match what I was using in Windows 98. AND, I decreased the right margin from .75 to .25. My data was still being truncated.

I put the code ? fln1
wait "fln1" timeout 6
in my code to make sure the entire line of code was being captured correctly and everything checked out. It was. Here's the line of code I'm working with:

REPLACE fln1 with ALLTRIM(DTOC(tfld24aa)) + " " + ALLTRIM(DTOC(tfld24ab)) + ;
" " + ALLTRIM(tfld24b) + " " + ALLTRIM(tfld24da) + " " + ;
ALLTRIM(tfld24db) + " " + ALLTRIM(tfld24e) + S24F + S24FF + ;
ALLTRIM(STR(tfld24f,7,2)) + " " + ALLTRIM(SUBSTR(tfld24g,1,1)) + " " + ALLTRIM(SUBSTR(npi,1,10))

The npi number (last field) was being truncated. I did a test and changed the npi ALLTRIM command to read ALLTRIM(SUBSTR(npi,1,9)) {one character shorter)} to see if the npi # would appear when I opened notepad. Success! It appeared. I removed one space between ALLTRIM(tfld24b) AND ALLTRIM(tfld4da) and the npi # in it's entirely appeared in Notepad. I'm going to ask our third party to remap this file since I've modified the data placement in this line.

All the Professional VFP code and data files were simply copied from our Windows 98 computer to our Windows 7.0 computer. No changes were made. For some reason the program under Windows 7.0 can't accommodate the length of that long field(???) I'm not going to spend any more time on it. I've fixed it, it will be remapped and we'll go on.

Thanks again for everyone's input!

Melody

 

[Olaf Doschke]

Melody,

In regard to your code, hopefully you're conscious about ALLTRIM trimming off spaces, making the whole output variable length and variable positions of data, in contrast of what you want. If you need exact positioning in certain columns, don't use ALLTRIM, then use PADL or PADR to pad to a predefined width. Any of the fields may be something like a counter, having had a recent carry to a +1 longer string, and therefore now shifted. Then it was mere coincidence, this happened in the transition to Win7. And obviously any shift anywhere causes the last field to be shifted.

I believe what you say is what you see, but it's still not a reason of notepad nor windows.

The npi number (last field) was being truncated. I did a test and changed the npi ALLTRIM command to read ALLTRIM(SUBSTR(npi,1,9)) {one character shorter)} to see if the npi # would appear when I opened notepad.[/code]
If the line is too long just by one char, and some value in some field must have become on char wider, then instead of inspecting notepad, you should inspect your data field via browse and see if the last char of npi came through to the fln1 field. If it's already missing there, you of course can do what you want in notepad, and removing a space and repositioning columns by one char this way helps, but what about enlarging the field fln1 and make it one char larger? Or making it a memo? In a memo fln1 can be as wide as you like, and also notepad has no practial line width limitation.

If the char is NOT missing in fln1, if it's really just missing in notepad, make your font setting one point lower than in win98. Win7 uses new fonts, also Aero windows style means wider borders and so the notepad window is a few pixels narrower in the same screen size. But if it would be that, then there wouldn't have been a binary difference in the file. So most probably it's just all about ALLTRIM() and one field having got one char wider data in it.

Bye, Olaf.

 

[Dan Freeman]

Here we go again. <chuckle>

Melody, I agree with everything Olaf said and I'll add some more that he undoubtedly thought about but got tired before mentioning it.

You show a REPLACE command. REPLACE does not create a text file. You do not show how the text file is created. If it's a COPY TO from a memo field, you could have suffered from "lucky data" (as Olaf mentioned) that suddenly got too wide to fit within SET MEMOWIDTH. Alltrim() can be really dicey in composing long strings for precisely this reason. You cannot control the ultimate length of the string.

Again, none of this has anything to do with Notepad or text files. It's data.

I'm afraid you'll be back at this some time soon when another field makes the string wider, and you'll still be chasing ghosts wondering what's wrong with Notepad when it has nothing whatsoever to do with Notepad.

 

[JRB-Bldr]

I've fixed it, it will be remapped and we'll go on.

That's great, but AS WE HAVE SAID OVER AND OVER ABOVE, the problem is not in Notepad nor in Windows.

Instead it is, and has always been, elsewhere and you have been determinedly focusing on the wrong symptom by looking at the issue in Notepad.

Some of us have suggested above that you look at the results, not in Notepad, but in some other text editor tool or in some other manner (such as in VFP Browse) so as to find find the REAL cause of the problem and thereby resolve it in the best and most effective manner.

Good Luck,
JRB-Bldr

 

[JRB-Bldr]

Now that I think about it...

it will be remapped and we'll go on.

If the data can be Re-Mapped successfully, that means that there was Never a problem there at all with the data itself - all of the data is still there.
If so, then the only problem was in how the data was perceived when displayed/viewed in Notepad.

Good Luck,
JRB-Bldr