Alejandro,

I add *:RAW text fields to reports manually. I use your code (modified by Sergey B) for report field ordering before generating ascii file. I havent tried this.

It should be also simple to write a text report listener. VFP passes all report objects to listener and listener can create text file from this. I havent tried this.

I modified Doug's hyperlink report previewer code to provide copy/paste to Excel. In this case, I calculate number of tabs and emtpy lines to be added between report objects so that pasting to excel or notepad with monospace font produces layout similar to report preview. This can be also used to generate txt files.

>I wrote some code to insert the "*:RAW" string into the frx on the fly just before calling REPORT FORM ASCII. It works fine for me since I always use Lucida Console 10 or 7. I'd like to generalize it to make it useful to others, but that may have to be done by someone who has another situation. The key step is to determine what the "standard line" height is, given the frx font.
>
>Thank you very much for your help. It was truly useful.
>
>Alex
>
>>>Sounds like a good method, but I am not familiar with the "*:RAW directive". Where do you place the directive? How does it affect output?
>>
>>Meaning of this directive is defined by my postgrocessing routine I published.
>>*:RAW directive is placed in the begginnig of line in report designer.
>>It means that line will no more processed.
>>Usually there is nothing after *:RAW and thus empty line will appear in output.
>>You and use REPLICATE( '*:RAW'+chr(13), 10 ) expression to get 10 empty lines.
>>
>>>Thank you.
>>>
>>>Alex
>>>
>>>>Alejandro,
>>>>
>>>>I solved your problems.
>>>>
>>>>Disappeared rows: add a lot of empty space before and after each row, use small font.
>>>>
>>>>Extra blank lines: post process the generated text file by removing all empty lines.
>>>>If you want empty line to be appear, I use *:RAW directive which is contverted by blank line.
>>>>
>>>>I use also special directives to add spaces to end of line and to insert special characters during post processing.
>>>>
>>>>

>>>>PROCEDURE PostProcessReportToAsciiOutput( prmFN )
>>>>
>>>>LOCAL fp, vrida, outf, cFn
>>>>cFN = m.TEMPDIR + SYS(2015)+'.txt'
>>>>outf = fcreate( m.cFN )
>>>>if m.outf<0
>>>>  ERROR 'Cannot create file ' + m.cFN
>>>>  return
>>>>  endif
>>>>
>>>>fp = fopen( m.prmFN )
>>>>if fp<0
>>>>  ERROR 'Cannot open file ' + m.prmFN
>>>>  fclose( m.outf )
>>>>  dele file (m.cFN)
>>>>  return
>>>>  endif
>>>>
>>>>do while !feof( m.fp )
>>>>  vrida = fgets( m.fp, 8000 )
>>>>
>>>>  do case
>>>>    case '*:RAW' $ m.vrida  && output uncahnged
>>>>      fputs( m.outf, strt(m.vrida, '*:RAW', '') )
>>>>
>>>>    CASE LEFT(m.vrida,LEN('*:PADR') )='*:PADR'
>>>>
>>>>      * *:PADRnnn  padding
>>>>      fputs( m.outf, PADR( ConvertPercent( SUBSTR(m.vrida,LEN('*:PADR')+3+1) ), ;
>>>>         VAL(  SUBSTR(m.vrida,LEN('*:PADR')+1,3) ) ))
>>>>
>>>>    case !empty(m.vrida) and alltr(m.vrida)#chr(12)
>>>>        fputs( m.outf, ConvertPercent( chrt( m.vrida, chr(12), '' ) ) )
>>>>    endcase
>>>>  enddo
>>>>
>>>>fclose( m.outf )
>>>>fclose(m.fp)
>>>>dele file (m.prmFN)
>>>>rename (m.cFN) to (m.prmFN)
>>>>ENDPROC
>>>>
>>>>* convert hex codes to special characters
>>>>FUNCTION ConvertPercent( tcInput )
>>>>
>>>>LOCAL lnPcntPos, lcOutput
>>>>lcOutput=""
>>>>
>>>>DO WHILE !EMPTY( m.tcInput)
>>>>  lnPcntPos=AT("%%%", m.tcInput)
>>>>  IF lnPcntPos>0
>>>>    lcOutput= m.lcOutput+LEFT( m.tcInput, ;
>>>>          lnPcntPos-1)+CHR(EVAL('0x'+SUBSTR(m.tcInput,m.lnPcntPos+1+2,2)))
>>>>    tcInput=SUBSTR( m.tcInput, m.lnPcntPos+3+2)
>>>>   ELSE
>>>>    lcOutput= m.lcOutput+ m.tcInput
>>>>    tcInput=""
>>>>    ENDIF
>>>>  ENDDO
>>>>RETURN m.lcOutput
>>>>

>>>>
>>>>>Good catch, Andrus. What I found there serves to avoid whole columns of data that become blank if they are not saved in that order, especially after migrating reports from DOS which results in overlaping report fields.
>>>>>
>>>>>The last couple of days I have been working on disappearing rows or inserted blank lines. I am approaching it by searching for "magical numbers" as Naomi said. Specifically, by programmatically increasing the width of report bands by tiny amounts until the results are just right. I have had good results, but nothing generic, unfortunatelly.
>>>>>
>>>>>Alex
>>>>>
>>>>>>In the thread
>>>>>>
>>>>>>REPORT FORM TO FILE xxx ASCII discovery Alejandro Sosa 14/02/2006
>>>>>>Thread ID: 1096211 Message ID: 1096211
>>>>>>
>>>>>>you wrote:
>>>>>>
>>>>>>I think I found an answer to the age old problem of mangled columns
>>>>>>when using REPORT FORM TO FILE xxx ASCII.
>>>>>>
>>>>>>In summary, the fields have to be stored in FRX in right to left
>>>>>>order. Here is code to do that.
>>>>>>
>>>>>>I have found that this corrects report to asci issues.
>>>>>>What other issues do you have?
>>>>>>
>>>>>>

  SELECT *, ;
>>>>>>  	  ICASE( INLIST(ObjType,1,2,3,4,9,10), ;
>>>>>>	         '1'+TRANSFORM(RECNO(),'@L 999999'),;
>>>>>>	        INLIST(ObjType,5,6,7,8), ;
>>>>>>	          '2'+TRANSFORM(999999 - HPos,'@L 999999'), ;
>>>>>>			'3'+TRANSFORM(RECNO(),'@L 999999')) ;
>>>>>>				AS cOrder ;
>>>>>>    FROM oldreport.frx ;
>>>>>>    ORDER BY cOrder ;
>>>>>>    INTO TABLE newreport.frx ;
>>>>>>    WHERE platform='WINDOWS'
>>>>>>