picture "@J" not working.

[newtofoxpro]

SET DEVICE TO print
SET PRINTER TO mytxt.txt
FOR cnt=1 TO 10
@ PROW(),$ say "abc1252.66 DB" picture "@J" size 1,20
ENDFOR
SET PRINTER to
SET DEVICE TO screen
modi comm mytxt.txt
RETURN

 

[Mike Lewis]

Works OK for me.

What are you expecting it to do? In what way doesn't it work?

Also, I assume you know that @ / SAY is no longer supported, and is not recommended.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[newtofoxpro]

picture "@J" size 1,20

It should print to file as Right-justifies text ("@J") within width 20.

Test1 : If I remove "SET PRINTER TO mytxt.txt" then works fine.

Test2 : If I remove "SET DEVICE TO print" and "SET PRINTER TO mytxt.txt" then also works fine.


I am trying to print grid. After user resizing or column swapping. This is a part of the full-code. Should I post complete code ?

SELECT GreedCursor
SCAN
@ PROW()+1,00 say ""
FOR ColPCnt=1 TO myForm.Greed1.ColumnCount
FOR ColCnt=1 TO myForm.Greed1.ColumnCount
IF myForm.Greed1.Columns(ColCnt).ColumnOrder=ColPCnt
myTitleField=myForm.Greed1.Columns(ColCnt).ControlSource
myTitlePicture=IIF(myForm.Greed1.Columns(ColCnt).Alignment=1,"@J","@K")
@ PROW(),$ say &myTitleField picture (myTitlePicture) size 1,(myForm.Greed1.Columns(ColCnt).Width/FONTMETRIC(6,"tahoma",10))
ENDIF
ENDFOR
ENDFOR
ENDSCAN

 

[Mike Lewis]

I don't know why it's not working for you. I suggest you leave out the PICTURE and SIZE clauses, and instead use PADL().

So, to print your string right-justified in a width of 20 characters, do this:

@ .., .. SAY PADL(MyString, 20)

But the best advice would be to abandon your entire @/SAY code. Instead, use the report designer to print your grid. I don't know the details of what you want to print, but I can assure you that you will find it easier to use the report designer.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

Mike, if the user is resizing and rearranging columns in the grid (as explained earlier) a report is going to have to be dynamically adjusted accordingly. I'm not sure that's easier.

 

[Olaf Doschke]

Dan, you are right, if thinking about normal reports with report control expressions set to field names. But you can also set the report field expression to

EVALUATE(lcField1) EVALUATE(lcField2) EVALUATE(lcField3)...

And then set lcField1, lcField2, lcField3 etc to field names or in general the expressions stored in grid.column.controlsource properties in the order the grid columns were moved. You can use Print When to print or not, add captions the same way via lcCaption1, lcCaption2 and so on.

Besides you can use the FRX table and set expressions on the fly, set widths, etc., a report in normal order is quite sufficient as a starter for modifications at runtime.

Printing a grid with PADL and PADR is limited to monospaced fonts and will never be able to compete with the design options you have with a FRX visual report.

Of course ther are moree report options, if you go visual anyway. Office Automation, Crystal, List&Label, FoxFire...

Bye, Olaf.

 

[newtofoxpro]

Thank you PADL & PADR working for me.


There is lot-off problems. While reports display & print on Laser/Dott-matrix printer. Should I list here ?

 

[Olaf Doschke]

No, you don't need to tell. But all these problems are because of embedded printer info. And it's easy to get rid of that, Now there even is a native feature for that in the VFP report designer, you don't need to clean the first record of such conflicting info. The conflicts simply arise, if developer has a printer the customer hasn't. And this is the normal case.

But there really is no FRX problem any more, if printers with a window GDI+ printer driver (the standard way of printer drivers today) is involved.

There still are two types of printers with and without such a printer driver. Label printers still rather come as COM serial printers you print to with control codes ESC+Printer command or pure ASCII, instead of USB plug&play driver driven printers, which you can address from any application including VFP with FRX reports.

Some people refuse the comfort and better possibilities of graphically designed reports.

I use FRX in my application using a wide variety of printers from laser, ink jet and dot matrix, in a large corp with hundreds of printers. And it works. All I offer the end user is SET PRINTER TO NAME (GETRINTER()) and that's it. And I make extensive use of on the fly FRX changes on the fly to allow font sizing, optional printing of fields, etc. It's cumbersome, sometimes, as the layout of report controls on top of each other isn't very comfortable, but it's not the range of different printers making this complicated. As long as a printer has a windows printer driver it works.

What I only partly understand is, if you have a USB/GDI plug and play printer and try to force the serial communication on it. You can recycle code. But I wouldn't write new code doing so, not even just out of habit.

Bye, Olaf.