return the form to the PRG (PREVIEW CRYSTAL REPORT 10) em VFP

[PauloMelo]

Guys, everything tq?

I assembled a nice routine to preview the crystal report by VFP (including
already available in the community VFP).

However, now is giving some bugs, probably my razor slash.

Just the facts:

I call the form to preview the CR within a prg, through
a menu. If you call each report and close it to open another,
okay, but if I minimize a form and return to open the prg
begins to give another "stick" type lock.

+ are attached - the PRG and the form.

In the form I have only the object: "Crystal ActiveX Report Viewer Control 10.0 "
and of course bringing the codes parameters of the prg.

In prg (procedure main-POS) thesis:
- I open the desktop
- I call the menu options

My question is:

- the environment will be set wrong?
- Will loop back to the menu?
- Will read / clear events?

Atencipadamente appreciate the cooperation of you all.

Paul

 

[PauloMelo]

was missing from the compressed file, then follow ...

 

[Mike Lewis]

Paul,

I'm having some difficulty in understanding your question.

In particular, what do you mean by "if I minimize a form and return to open the prg begins to give another "stick" type lock."?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[PauloMelo]

Ok Mike.
Sorry about the placement of opaque question, but really quite understand the English coach.

In summary within the sample code I sent PRG can call any report in crystal report 10 passing only the parameters.

But suppose you need to open multiple reports at the same time for some analysis .... I have to leave the report open at the moment and return to Prague to open another and so on.

Anticipate the interest in helping me, but I hope it is a subject of interest by many, because with this I am opening a Crystal Report PREVIEW coming from VFP.

Grateful
Paul

 

[craigber]

The Init method of the form creates the Crystal Reports object every time. You should only create it once per application, and do it high up in the call hierarchy. Find the line

CRApplication = createobject("CrystalRuntime.Application.10")

and move it to the main.prg of your application so it gets created when you launch the program.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[PauloMelo]

Obrigado Craig

Thanks Craig

I tested with your suggestion, but did not change anything in relation to what happened before.

What do I need in fact: to minimize the report currently open, return to MAIN.PRG and when I call for new report, the MAIN.PRG crashes.

In the form I am using the method: MouseMove, and inserting the following:
ThisForm.WindowState = 1

This returns to MAIN.PRG would not have to do with the read / clear events?

Grateful
Paul

 

[Dan Freeman]

Craig (Mr. Crystal):

* Does CR even support multiple reports in preview at the same time?
* If so, the report preview can't be modal. Is this correct?

If the latter is true, then there isn't an issue of "returning" to a prg, because it returns right away, so the issue here is elsewhere.

I suspect the problem has been under-defined (owing to a language barrier). WindowState certainly shouldn't affect the normal flow of code execution. Window TYPE, sure, but not WindowState, but then we're back to the modal vs. non-modal question.

Paul, you say "the MAIN.PRG crashes". What is the error message? Note: please be accurate. VFP has many similar error messages with only small differences but widely differing meanings.

 

[craigber]

Dan,

CR does support multiple reports in the viewer at the same time and yes, to do that, you need to have a non-modal viewer form.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[PauloMelo]

I'm using is not modal.

Really debug and run the form automatically returns to "MAIN.PRG.

But since then the "MAIN.PRG" hangs (is without action).

Again I suspect the question read / clear events???...

 

[Dan Freeman]

It's sounding more and more like this is behavior by design.

Every VFP main program should have exactly one READ EVENTS. When no code is executing, the program waits for user input at READ EVENTS.

When a form runs, the form sets itself up and returns control to READ EVENTS waiting for user action.

Everything "returns to" READ EVENTS. Always.

It will look like nothing is happening because nothing is happening. Your program is waiting for user input in whatever form controls or menus you've provided to collect user input.