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?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Setting text file parameters with Visual Fox Pro 5.0/Windows 7.0
- Thread starter njsandor
- Start date
which is then displayed in Notepad
Have you tried the suggestions above to see if the problems you are 'seeing' are merely about how Notepad is Displaying the text file?
Have you tried opening the Text file into some other application to see what it looks like?
Maybe try some Hex Editor? (I use 010 Editor
how do I change settings for report
Many of us have already told you that there are NO 'Settings' in a Text File - just Text.
I guess we are not clear about - How do you know that something is making file unusable as information is incomplete ?
Have you investigated the process that is Receiving the file and attempting to Process it?
That is where you can find out the Specifics of what is not working (if anything).
Good Luck,
JRB-Bldr
Have you tried the suggestions above to see if the problems you are 'seeing' are merely about how Notepad is Displaying the text file?
Have you tried opening the Text file into some other application to see what it looks like?
Maybe try some Hex Editor? (I use 010 Editor
how do I change settings for report
Many of us have already told you that there are NO 'Settings' in a Text File - just Text.
I guess we are not clear about - How do you know that something is making file unusable as information is incomplete ?
Have you investigated the process that is Receiving the file and attempting to Process it?
That is where you can find out the Specifics of what is not working (if anything).
Good Luck,
JRB-Bldr
Mike Lewis
Programmer
This is the first time you've mentioned a report.
A report is never displayed in Notepad. In VFP terms, a report is displayed within the app, either on the screen (in a preview window) or printed to paper. If you really have a VFP-style report, and given that you want to change the margins and font size, then the report is definitely the place to do it.
To achieve that, you need to open the report in the report designer, make the necessary changes, and save the report. Do you know how to do that? We can give you step-by-step instructions, but first let's establish that you really do have a report. If you're seeing the text in Notepad, then it is not a report, and the above is irrelevant.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Dan Freeman
Programmer
The print margin never displays. But it can affect line length until you've turned off wordwrap.
Dan Freeman
Programmer
njsandor said:
YOU ARE NOT LISTENING.
![[sadeyes]](/data/assets/smilies/sadeyes.gif "[sadeyes] [sadeyes]")
There is no formatting in a text file.
Now you're calling it a report. The word "report" has EXTREMELY specific meaning internally inside FoxPro and may or may not result in a text file.
If you were inaccurate in calling the file a text file, it would help explain why you feel there is formatting inside the file. There might be! But it wouldn't be a text file and everyone trying to help you with a text file is wasting their time.
If it IS a text file, please understand that it DOES NOT contain any formatting.
Now, is this really a "report" in the FoxPro sense or is it something your application calls a report that doesn't actually use a FoxPro report form?
Olaf Doschke
Programmer
Dan,
1. Thanks for pointing out the effect of margin settings to the text line length. I didn't know that feature of notepad.
2. "Now, is this really a "report" in the FoxPro sense or is it something your application calls a report that doesn't actually use a FoxPro report form?"
This is a very good question, i doubt though, that njsandor/Earl can tell that, even if he'd like to help us help him.
Earl, you could please clarify, what your application does, when you start a report:
Does it give a preview window and then when you press a print button creates a text file instead of printing it to a printer?
Does it create a text and opens it up in notepad? (that would be unusual, but possible)
Does it create a text file you open via Windows Explorer and view in notepad?
I can only repeat in all three cases, there is no formatting in text files, so notepad shows a text as is, unless either ine wrapping is turned on, or as I also learned just now from dan, margins affect the line length shown in the notepad window. All these effects are from notepad, and the only way to change it, and to change it permanently, is using the notepad menu items for font and print layout. Neither foxpro nor your application.
If you have a preview situation looking differently to the final text file you view in notepad, that's normal, because VFP reports show a print preview, which includes margins a printer would leave blank, while a notepad window does not show margins and shows the pure text portion, unless you print to a printer.
If you talk of files you view by clicking on them and even don't know the file extension is txt or something else, most probably your windows setting is at the default hiding the extensions like .txt from you, only showing an icon of the file type. Maybe you also have a wrong file extension mapping to notepad. Windows does that to protect users from changing the file extension, rendering a file useless, unless you know what you're doing, but in my opinion that's causing more trouble than it helps users. You can change folder display options to show file extensions and then can tell us, if it's really txt files.
Bye, Olaf.
1. Thanks for pointing out the effect of margin settings to the text line length. I didn't know that feature of notepad.
2. "Now, is this really a "report" in the FoxPro sense or is it something your application calls a report that doesn't actually use a FoxPro report form?"
This is a very good question, i doubt though, that njsandor/Earl can tell that, even if he'd like to help us help him.
Earl, you could please clarify, what your application does, when you start a report:
Does it give a preview window and then when you press a print button creates a text file instead of printing it to a printer?
Does it create a text and opens it up in notepad? (that would be unusual, but possible)
Does it create a text file you open via Windows Explorer and view in notepad?
I can only repeat in all three cases, there is no formatting in text files, so notepad shows a text as is, unless either ine wrapping is turned on, or as I also learned just now from dan, margins affect the line length shown in the notepad window. All these effects are from notepad, and the only way to change it, and to change it permanently, is using the notepad menu items for font and print layout. Neither foxpro nor your application.
If you have a preview situation looking differently to the final text file you view in notepad, that's normal, because VFP reports show a print preview, which includes margins a printer would leave blank, while a notepad window does not show margins and shows the pure text portion, unless you print to a printer.
If you talk of files you view by clicking on them and even don't know the file extension is txt or something else, most probably your windows setting is at the default hiding the extensions like .txt from you, only showing an icon of the file type. Maybe you also have a wrong file extension mapping to notepad. Windows does that to protect users from changing the file extension, rendering a file useless, unless you know what you're doing, but in my opinion that's causing more trouble than it helps users. You can change folder display options to show file extensions and then can tell us, if it's really txt files.
Bye, Olaf.
- Thread starter
- #26
Dear All,
Thank you for all your feedback. I'm Earl's wife, the programmer who wrote this application. Let me put this into database programming terms. Keep in mind that I haven't programmed in Foxpro for a while so any help you can provide is most appreciated. The office is running Professional VFP 5.0. It was running on a Dell system using Windows 98. We have moved the system to a new Dell running Windows 7.0. We're still running the program under the old system (Windows 98) until the report we're creating is correctly formatted in Windows 7.0.
In the VFP program I'm creating a report using the following code: Report Form "C:\VFP\Eyeteam\webhic.frx" NOCONSOLE TO FILE "C:\VFP\Eyeteam\fwebmd.txt" ASCII
I search for the report and open it and see that the font size under Windows 98 for this report is courier new regular 10. When I run the same program on Windows 7.0 the font size for this report is Lucida Console regular 10. Data from one of the lines in the report is being truncated under Windows 7.0.
So, I modified Foxpro in Windows 7.0 to run under compatibility mode 640 x 480 screen resolution. (I'm not an expert on compatibility mode but it looked like something good to try) I ran the program and opened the report, checked the font size and it says it's in courier new regular 10 (like the Windows 98 report). However, information is still being truncated in the report (using the Report Form code I listed above).
We transmit this report to a third party who mapped it years ago to allow them to apply each "field" of information on the report to the correct field in their data file.
I'm not sure why the report in Windows 7.0, running under compatibility mode 640 x 480 screen resolution is still truncating data since when I look at it it says the font size is courier new regular 10 (same as it is under Windows 98).
I'm trying to avoid going back into the Report Designer in VFP and reformatting this line and then asking our third party to remap the report. There is much data on the line being truncated. It's one big field that I've written data into.
I pulled out the VFP Developer's Manual and was going to look at the REPORT FORM command to see if there's some attribute I can use to prevent my data from being truncated under the new system.
Suggestions?
Melody
Thank you for all your feedback. I'm Earl's wife, the programmer who wrote this application. Let me put this into database programming terms. Keep in mind that I haven't programmed in Foxpro for a while so any help you can provide is most appreciated. The office is running Professional VFP 5.0. It was running on a Dell system using Windows 98. We have moved the system to a new Dell running Windows 7.0. We're still running the program under the old system (Windows 98) until the report we're creating is correctly formatted in Windows 7.0.
In the VFP program I'm creating a report using the following code: Report Form "C:\VFP\Eyeteam\webhic.frx" NOCONSOLE TO FILE "C:\VFP\Eyeteam\fwebmd.txt" ASCII
I search for the report and open it and see that the font size under Windows 98 for this report is courier new regular 10. When I run the same program on Windows 7.0 the font size for this report is Lucida Console regular 10. Data from one of the lines in the report is being truncated under Windows 7.0.
So, I modified Foxpro in Windows 7.0 to run under compatibility mode 640 x 480 screen resolution. (I'm not an expert on compatibility mode but it looked like something good to try) I ran the program and opened the report, checked the font size and it says it's in courier new regular 10 (like the Windows 98 report). However, information is still being truncated in the report (using the Report Form code I listed above).
We transmit this report to a third party who mapped it years ago to allow them to apply each "field" of information on the report to the correct field in their data file.
I'm not sure why the report in Windows 7.0, running under compatibility mode 640 x 480 screen resolution is still truncating data since when I look at it it says the font size is courier new regular 10 (same as it is under Windows 98).
I'm trying to avoid going back into the Report Designer in VFP and reformatting this line and then asking our third party to remap the report. There is much data on the line being truncated. It's one big field that I've written data into.
I pulled out the VFP Developer's Manual and was going to look at the REPORT FORM command to see if there's some attribute I can use to prevent my data from being truncated under the new system.
Suggestions?
Melody
Olaf Doschke
Programmer
Thanks Melody,
from what you say:
1. There is no font info embedded in fwebmd.txt (as we said many times)
2. All you need to change once and for all time is the font and margin settings of notepad to the same settings of the win98 PC.
Please, this is what several of us already said many times.
Simply change the notepad settings.
Bye, Olaf.
from what you say:
1. There is no font info embedded in fwebmd.txt (as we said many times)
2. All you need to change once and for all time is the font and margin settings of notepad to the same settings of the win98 PC.
Please, this is what several of us already said many times.
Simply change the notepad settings.
Bye, Olaf.
Simply change the notepad settings.
I would still like to understand SPECIFICALLY WHAT is not working and SPECIFICALLY WHY (as I asked above).
It will be fine to change Notepad so that the Text file displays differently and maybe as expected, but as we have said MANY times, that will NOT Change the Text File contents.
So if it is indeed the Text file contents that are not working in some recipient application, then has the detailed investigation been done is WHAT IS NOT WORKING in that Application?
Good Luck,
JRB-Bldr
I would still like to understand SPECIFICALLY WHAT is not working and SPECIFICALLY WHY (as I asked above).
It will be fine to change Notepad so that the Text file displays differently and maybe as expected, but as we have said MANY times, that will NOT Change the Text File contents.
So if it is indeed the Text file contents that are not working in some recipient application, then has the detailed investigation been done is WHAT IS NOT WORKING in that Application?
Good Luck,
JRB-Bldr
Dan Freeman
Programmer
njsandor said:
Cool. We know what we're dealing with: a pure text file with no formatting in it whatsoever.
njsandor said:
See above.
As Olaf says, what you're seeing is the default font for Notepad in Windows 7.0. Display actually has nothing to do with content. Change the font once and Notepad will remember it. (Until someone else changes it again, which is a good reason to IGNORE FORMATTING when you're dealing with text files.)
Mike Lewis
Programmer
Melody,
In an idle moment this morning, I thought I'd reproduce your problem. I created a report, and output it to an ASCII file, just as you did. I opened the file in Notepad, with the default font of Courier New. I then switched to Lucida Console. Several lines were truncated, just as you said.
So, the solution is clear: Within Notepad, switch the font back to Courier New, and everything will be fine. (Alternatively, increase the size of the Notepad window, if that's possible).
As everyone else has said, this is not a FoxPro problem, nor a reporting problem. It's not even a Windows 98 vs. Windows 7 problem. It's simply a question of which font you have chosen in Notepad. If you don't want the lines to be truncated, switch back to Courier New. You only have to do that once; Notepad will remember your setting.
Can you at least try that, and let us know if it solves the problem.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
In an idle moment this morning, I thought I'd reproduce your problem. I created a report, and output it to an ASCII file, just as you did. I opened the file in Notepad, with the default font of Courier New. I then switched to Lucida Console. Several lines were truncated, just as you said.
So, the solution is clear: Within Notepad, switch the font back to Courier New, and everything will be fine. (Alternatively, increase the size of the Notepad window, if that's possible).
As everyone else has said, this is not a FoxPro problem, nor a reporting problem. It's not even a Windows 98 vs. Windows 7 problem. It's simply a question of which font you have chosen in Notepad. If you don't want the lines to be truncated, switch back to Courier New. You only have to do that once; Notepad will remember your setting.
Can you at least try that, and let us know if it solves the problem.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Unless the application which receives the text file and which is NOT WORKING with your output files is NOTEPAD itself (Highly Un-likely), how it is Displayed there is of No Consequence.
It is only a visual representation of your file and another Text editor might display the same Text file differently depending on its own default settings.
It seems as though there has been too much emphasis on how the Text file visually appears in Notepad and not on the actual Real Problem - What is FAILING/NOT WORKING?
Good Luck,
JRB-Bldr
It is only a visual representation of your file and another Text editor might display the same Text file differently depending on its own default settings.
It seems as though there has been too much emphasis on how the Text file visually appears in Notepad and not on the actual Real Problem - What is FAILING/NOT WORKING?
Good Luck,
JRB-Bldr
Olaf Doschke
Programmer
Mike, as you checked, does an embedded Printer info influence the generated ASCII text file?
Eg if you define borders there, does that influence the line breaks? What if you use a report in Win98, which has a printer info embedded and then do REPORT FORM ... To FILE ... ASCII on another computer, not having that printer driver?
That's the only thing, which could have an influence on the result.
Let's inverse the question: As you stated earlier "As this file is used as a template for transmission", it seems you want to have control about the file layout. To do so, use a graphical report and don't print to ASCII file, print to PDF, for example, via a PDF printer driver like Bullzip PDF. Then you get a PDF file, that will look as it looks on any PC.
Also it's unclear what you mean by template. Is this is form to fill in something, when it's printed, later?
So far you have lived with a text file with no formatting and you only have a problem with the display in notepad, which has no influence whatsoever on the file, even if you change your notepad settings. So people receiving these files, which had no problem so far, will continue to have no problem.
You already had this problem in Win98, only YOU saw the file correctly under YOUR notepad Win98 settings, anyone you sent the text file to, has seen it with HIS notepad settings, there is nothing embedded in an ASCII text file.
If you want something over which you have control, switch to PDF now, for example. It depends on how end users should be able to read/write the file. PDFs are merely readonly documents, but they are in the page design you decided, with the fonts you configured in the foxpro FRX report, etc.
Bye, Olaf.
Eg if you define borders there, does that influence the line breaks? What if you use a report in Win98, which has a printer info embedded and then do REPORT FORM ... To FILE ... ASCII on another computer, not having that printer driver?
That's the only thing, which could have an influence on the result.
Let's inverse the question: As you stated earlier "As this file is used as a template for transmission", it seems you want to have control about the file layout. To do so, use a graphical report and don't print to ASCII file, print to PDF, for example, via a PDF printer driver like Bullzip PDF. Then you get a PDF file, that will look as it looks on any PC.
Also it's unclear what you mean by template. Is this is form to fill in something, when it's printed, later?
So far you have lived with a text file with no formatting and you only have a problem with the display in notepad, which has no influence whatsoever on the file, even if you change your notepad settings. So people receiving these files, which had no problem so far, will continue to have no problem.
You already had this problem in Win98, only YOU saw the file correctly under YOUR notepad Win98 settings, anyone you sent the text file to, has seen it with HIS notepad settings, there is nothing embedded in an ASCII text file.
If you want something over which you have control, switch to PDF now, for example. It depends on how end users should be able to read/write the file. PDFs are merely readonly documents, but they are in the page design you decided, with the fonts you configured in the foxpro FRX report, etc.
Bye, Olaf.
TamarGranor
Programmer
My impression is that the file here is being used as input to some kind of processing and thus needs to be text. But maybe that's my mental filters assuming this is about EDI.
Tamar
Tamar
Olaf Doschke
Programmer
If it's about EDI, I wonder why going through an FRX at all, you surely had STRTOFILE() back in VFP5, too. Also TEXT..ENDTEXT in conjunction with TEXTMERGE settings. Nothing is easier to use to write out text to a file.
Bye, Olaf.
Bye, Olaf.
Dan Freeman
Programmer
No, Strtofile() is more recent than VFP5. But yes, TEXT/ENDTEXZT would have existed.
The thing is, we've all been lead down a rabbit hole with "it doesn't work", but the only definition of "it doesn't work" is "fonts in a text file" which we all know cannot be the issue.
We really need a better explanation of what isn't working.
The thing is, we've all been lead down a rabbit hole with "it doesn't work", but the only definition of "it doesn't work" is "fonts in a text file" which we all know cannot be the issue.
We really need a better explanation of what isn't working.
Tamar - My impression is that the file here is being used as input to some kind of processing and thus needs to be text
From what was indicated at the beginning of this LONG thread, that is what I too believed (and I still believe since we have not had original poster response clarifying it).
That is why I mention that we should now quit focusing on how the file appears in Notepad (since that, by itself, quite likely has absolutely nothing to do with what is actually failing) and focus on getting specific details on what within the Recipient Processing Application is failing and why.
We now need Melody to come back with the details of the Actual Problem, not how the text file might appear.
Melody/Earl - Good Luck,
JRB-Bldr
From what was indicated at the beginning of this LONG thread, that is what I too believed (and I still believe since we have not had original poster response clarifying it).
That is why I mention that we should now quit focusing on how the file appears in Notepad (since that, by itself, quite likely has absolutely nothing to do with what is actually failing) and focus on getting specific details on what within the Recipient Processing Application is failing and why.
We now need Melody to come back with the details of the Actual Problem, not how the text file might appear.
Melody/Earl - Good Luck,
JRB-Bldr
Dan Freeman
Programmer
JRB-Bldr, you and I are on a similar page. The problem is that the OP never said "the other application isn't working". Just that the formatting in the text file was wrong. (And, of course, we know that's bogus.)
Reread the original post. It does not say that anything is broken except for formatting.
So, yes, we need to know what isn't working.
Reread the original post. It does not say that anything is broken except for formatting.
So, yes, we need to know what isn't working.
Dan
In Earl's (njsandor's) 3rd post on 5/14/13 he says:
The font is bigger and the lines on right margin are being lopped off, making file unusable as information is incomplete. The text file setup was used as a template by the third party and is now unrecognizable to them.
And then in Melody's posting she says:
We transmit this report to a third party who mapped it years ago to allow them to apply each "field" of information on the report to the correct field in their data file.
So it might seem as though the Recipient's Field Mapping is no longer working - however that is accomplished.
Dan - you and I and the other gurus here already know this but Field Mapping HAS NOTHING TO DO WITH NOTEPAD OR FONT SIZE. - unless, and it would be very unlikely, that the Recipients were using Image Processing and/or Optical Character Recognition (OCR) - especially unlikely on something as simple as a Text file.
So, once again, we need Melody to come back with her better understanding of the issues and provide us with the details of the Actual Problem as determined at the Recipient's end - not just the vague: "it no longer works".
Melody/Earl - Good Luck,
JRB-Bldr
In Earl's (njsandor's) 3rd post on 5/14/13 he says:
The font is bigger and the lines on right margin are being lopped off, making file unusable as information is incomplete. The text file setup was used as a template by the third party and is now unrecognizable to them.
And then in Melody's posting she says:
We transmit this report to a third party who mapped it years ago to allow them to apply each "field" of information on the report to the correct field in their data file.
So it might seem as though the Recipient's Field Mapping is no longer working - however that is accomplished.
Dan - you and I and the other gurus here already know this but Field Mapping HAS NOTHING TO DO WITH NOTEPAD OR FONT SIZE. - unless, and it would be very unlikely, that the Recipients were using Image Processing and/or Optical Character Recognition (OCR) - especially unlikely on something as simple as a Text file.
So, once again, we need Melody to come back with her better understanding of the issues and provide us with the details of the Actual Problem as determined at the Recipient's end - not just the vague: "it no longer works".
Melody/Earl - Good Luck,
JRB-Bldr
To change the default Notepad display font and size, modify the Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Notepad\DefaultFonts. Change the lfFacename keyword value to 'Courier New'. If you want to change the font size change the iPointsize keyword value.
Bye,
MM
Olaf Doschke
Programmer
Either Earl and Melody already found a solution, or the problem turned out to be just visually looking as if.
The font is bigger and the lines on right margin are being lopped off
That could simply mean the notepad window isn't wide enough, not text really being lopped off.
The text file setup was used as a template by the third party and is now unrecognizable to them.
If their judgement about the file being unrecognizable, too just was made by visual inspection, then perhaps there never was a real problem.
If data needed to be at certain line/col positions and that changed, then really the content of the output text file changed somehow. So my question about the influence of embedded printer info in an FRX towards ASCII output would be the only thing that matter.
Now I simply glimpsed into the help file on REPORT FORM. the "TO Outputdestination" is explainied in detail in the last third of the help topic. [FILE] FileName2 [[ADDITIVE] ASCII] is one possible Outputdestination, and the ASCII clause is described as:
That still doesn't say if margin settings of printer info influence line width, but you have two system variables _ASCIICOLS and _ASCIIROWS.
The help on _ASCIICOLS says a default for it is 80, the OS does not define it, eg it's a VFP system variable, not a OS environment variable.
So if no printer page setup info embedded in the FRX would influence output to ASCII, there is no OS influence at all and it merely was the visual inspection with notepad, which was not looking the same was as on Win98. You could double check that by moving a new file to the old system and opening it there. Then there was no problem at all.
Bye, Olaf.
The font is bigger and the lines on right margin are being lopped off
That could simply mean the notepad window isn't wide enough, not text really being lopped off.
The text file setup was used as a template by the third party and is now unrecognizable to them.
If their judgement about the file being unrecognizable, too just was made by visual inspection, then perhaps there never was a real problem.
If data needed to be at certain line/col positions and that changed, then really the content of the output text file changed somehow. So my question about the influence of embedded printer info in an FRX towards ASCII output would be the only thing that matter.
Now I simply glimpsed into the help file on REPORT FORM. the "TO Outputdestination" is explainied in detail in the last third of the help topic. [FILE] FileName2 [[ADDITIVE] ASCII] is one possible Outputdestination, and the ASCII clause is described as:
VFP help topic REPORT FORM said:
That still doesn't say if margin settings of printer info influence line width, but you have two system variables _ASCIICOLS and _ASCIIROWS.
The help on _ASCIICOLS says a default for it is 80, the OS does not define it, eg it's a VFP system variable, not a OS environment variable.
So if no printer page setup info embedded in the FRX would influence output to ASCII, there is no OS influence at all and it merely was the visual inspection with notepad, which was not looking the same was as on Win98. You could double check that by moving a new file to the old system and opening it there. Then there was no problem at all.
Bye, Olaf.
- Status
