VFP6 print fault when using Citrix

[UserNeil8994]

Our VFP app. uses @ SAY commands to let our customer create a complex "report" showing a road and its signs. The @ SAY column positions are data-driven to print bitmaps of road signs across the page according to their position on the road.

This has always worked well, even using NT Terminal Server. However, when the application was moved onto Citrix we noticed that when @ SAY was asked to position a bitmap half way across the landscape page it was positioning it 1 column too far right. At three-quarter way across it positioned 2 columns too far right. It still works OK if not on Citrix.

To test, we forced printing of an incrementing number (1,2,3,etc) in each column that didn't have a bitmap. We discovered that under Citrix gaps would appear, e.g. it would print 123456789012 45678etc.

This was the culprit. But how can we fix it apart from - horrors - using a parameter that says "when running on Citrix subtract 1-2 columns if the print position is more than half way across the page."

Suggestions welcome.

 

[Mike Gagnon]

UserNeil8994

Have you tried switching your font to a non-proportional font? Honestly I have worked with Citrix and I have never encountered this situation, since Citrix does not change neither font nor printer driver. Although the @1,1 say"" might also be a technique to revise.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[UserNeil8994]

Thanks Mike. I tried "resetting" the printhead position with @ SAY 0,0 before I printed a bitmap, but it didn't solve the problem.

I agree that proportional fonts affect the size of type on the page, but our problem isn't printing fonts, it's printing bitmaps. If our printing of items on a ROW includes printing bitmap(s), then under Citrix gaps appear in the column printing positions as we move across the page.

If I make the problem visible by printing numbers where I don't print bitmaps, it shows that the printhead is jumping a column. Even the pcol() positions aren't obeyed, for example, printing as follows....

12345678901234 567890123[bitmap]789etc.

In this example, the pcol() value for the printing of 5 is one greater than for 4, and yet it has jumped two columns.

This doesn't happen if I don't include bitmaps. And it works fine if not using Citrix.

I wonder if there is some sort of .ini file required when running VFP under Citrix, that might make printing behave better?

 

[Mike Gagnon]

UserNeil8994

As I suggested, you may want to reconsider your reporting techniques. The report designer has been around long enough that by VFP6.0 we have undertsood its shortcomings, but you reporting techniques are in the FPD (DOS) days.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[UserNeil8994]

I agree that using @ SAY is archaic. We use it because we found that the VFP reportwriter wouldn't behave itself printing bitmaps in data-driven positions on a page.

Maybe this aspect of the reportwriter has improved since we tried it, several VFP generations ago. However, our @ SAY report works well except for this Citrix issue.

The irony is that because VFP still contains old DOS commands it can be used to do things that modern visual objects can't do. In our case, VFP's heritage allows us to produce an .exe that can use data to draw graphical reports a drawing tool would be proud of.

Thanks for your help.

 

[Mike Gagnon]

UserNeil8994

I agree that using @ SAY is archaic. We use it because we found that the VFP reportwriter wouldn't behave itself printing bitmaps in data-driven positions on a page.

I would disagree with that statement. I have done many reports with bitmaps that came from general fields (or binary memo fields), that come out acceptably.
But don't forget also Citrix also add another layer to the problem and probably adds to the interpretation of what you are trying to do.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[UserNeil8994]

Mike

It's a few years since we tried to create this complex "report" using the reportwriter but I recall vaguely that the bitmaps always positioned themselves at the left margin rather than at the required column, when we supplied that column value not as an absolute number but as a parameter from the database. i.e. at design time the reportwriter would have no knowledge of where the bitmap would be placed. Runtime would supply that info.

It maybe that the reportwriter has improved but our "report" is massive so it's probably too late even then to change course.

Interestingly, I have had a comment on similar Citrix problems from another forum. It is below.

Thanks again for your help.



*******************************************
We had a similar problem with an @ SAY report that printed on a preprinted form. It happened when we upgraded our PC's to Win2K SP3. The SP3 machines would print an offset of one column - and sometimes it would not. We finally implemented an offset driven by the OS() function so that the SP3 machines would start one column over from the non-SP# machines. It worked OK, but since the offset was not consistent, there were still problems. We finally converted the report to a REPORT FORM and it works fine now.