Error, Output of Multiple Labels using .LBX

[iemx]

I'm having an issue where exactly 172 labels are being produced using a standard command LABEL FORM OUTPUT\LA400.LBX PREVIEW regardless if my cursor has 1-record, 2-records, 3-records etc. I have used .LBX FoxPro Label Format files for 15+ years and never had any issues before. Maybe. I'm getting old and forgetting something very simple. Help!

 

[Mike Lewis]

Let me get this right. The cursor that is driving the labels has a very small number of records (1, 2 or 3 - or "etc"). And yet 172 labels actually have something printed on them. Given that each record should print one label, the obvious question is: What is being printed on the labels beyond the first 1, 2 or 3 (if anything)?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[iemx]

That is correct... the Cursor that is driving the labels always has 1-record, 2-records, 3-records etc. Regardless of how many records the cursor has, I always get 172-consecutive labels, all duplicate. The program is very simple, it's from the order entry screen the user enters how many shipping labels are required. The user, for example, enters (3) and I append 3-records into the cursor. I've even entered a BROWSE statement to make sure there are only 3-records in the cursor just before I execute the LABEL command. I just don't get where the issue could possible be from. Is there any system variable in FoxPro that is a default for number of labels that I might of accidentally assigned in my code?

 

[iemx]

Here is the code I'm using if you want to try and duplicate it...

CREATE CURSOR detail1 (;
RPT100 C(50),;
RPT101 C(50),;
RPT102 C(50),;
RPT103 C(50),;
RPT104 C(50),;
RPT105 C(50),;
RPT106 C(50),;
RPT107 C(50),;
RPT108 C(17),;
RPT109 C(10),;
RPT110 C(20),;
RPT111 C(7),;
RPT112 N(5),;
RPT113 M) && Xtra Description

SELECT detail1
GO TOP
IF .NOT.EOF()
LABEL FORM OUTPUT\LA400.LBX PREVIEW
ENDIF

 

[Steve Meyerson]

Just some quick thoughts to narrow down the cause you may not have tried:

1. Add NEXT 3 to the LABEL FORM command.

2. Add blanks & bogus records to the cursor to see if/how the output changes.

3. What happens if more than 172 records are added to cursor?

4. Which record(s) is(are) being duplicated?

Steve

 

[iemx]

Statement LABEL FORM OUTPUT\LA400.LBX NEXT 3 PREVIEW works and only prints out 3-labels.

NOW, the issue is that it ONLY prints out 3-labels and on whatever current record no is being pointed to in the cursor. In other words, if I ask for 1-label and the program only creates 1-record in the cursor. When I execute a BROWSE and append 5+ records, whatever record is being pointed to prints 3-labels. All other records are being ignored. When I execute LABEL FORM OUTPUT\LA400.LBX NEXT 1000 PREVIEW then only 172-labels get produced, from that 1-record it is pointing to.

The issue must in the .LBT .LBX files or a system default variable. Your thoughts?

 

[Chris Miller]

The most straight forward reason is the report is driven by data in its private dataenvironment. And prints all records of a table that has 172 label records.

It would be the first thing I'd look for, whether your report driving cursor is actually driving the report.

And even when the lbx has no private data environment (don't confuse this with printer environment, by the way) the question is, whether the cursor you think drives the report is acutally the active workarea when the report really runs. A grid on a form can take precedence and make its rowsource the current workarea.

I was sure this bug ("by desgin") was mentioned on Fox Wikis, but I found something from Mike Lewis about it:

VFP reports not showing the same data as the preview

By Dan Macleod Has this happened to you? You preview a report in Visual FoxPro. Everything looks fine. You then print the report by clicki...

hexcentral.blogspot.com

Read it, even if you think of it as irrelevant by the title, this is not about preview pass vs final print pass, it can also effect the preview and happen without a preview.



Chriss

 

[iemx]

Chris, your suggestion worked. I would of never thought of this solution. Thanks!