Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Printing from the preview
Message
De
03/06/1999 19:03:07
 
 
À
03/06/1999 18:50:01
Jorge Haro
Independent Consultant
Juarez, Mexique
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire de rapports & Rapports
Divers
Thread ID:
00226300
Message ID:
00226314
Vues:
27
>I'm having a wierd problem here, or maybe it's a known fact I'm missing. I had a similar problem before where I didn't get quite the same thing when I previewed a report and then printed it using the print icon on the preview toolbar, I use to get more records on paper than I did on the preview. Back then it was "solved", or more like walked around by printing directly (no preview).
>
>My report form statements use the for clause, this particular one:
>
>repo form nomina for cAnio+cPeriodo=oApp.GetPeriodoActivo() prev
>
>The preview comes out as expected but I get two different errors when I print FROM the preview:
>
>When running the compiled exe:
>
>"Operator/operand type mismatch" (wt..?)
>
>And from the command window:
>
>"Report contains nesting error"
>
>I would assume that if I'm seeing the report on screen, and if it does print when printed directly, which it does, there are no errors inside the report itself.
>
>But I noticed that when I do this from the command window, the command for direct print is autommatically typed in the command window like this:
>
>REPORT FORM c:\dev\nomina15\reportes\nomina.frx NOEJECT NOCONSOLE TO PRINTER
>
>ie, no FOR clause!!!!. I didn't know it was supposed to do this.
>
>If this is the case what am I supposed to do when I call my reports whith a FOR clause, which BTW I do a lot, my reports form has a group of checkboxes on the right with restrains for dates, control numbers, part numbers, etc. And my print method forms an expression based on them which in turn is used with a FOR clause in the REPORT FORM command, should I tell my client, "Oh, don't print from the preview, go back and print directly"???
>

Interesting. I don't know how to solve this, but I can suggest a workaround:

instead of using the FOR clause, set a filter on the table in question, and remove the filter after the report is run.

SET FILTER TO cAnio+cPeriodo=oApp.GetPeriodoActivo()

That way you don't need the FOR clause.

>Should I just switch to parameterized(I'm glad I don't have to pronnounce that) views instead of using actual tables in my reports?
>
>if you made it this far TIA
>
>Jorge Haro
Erik Moore
Clientelligence
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform