Report Crashes When Maximimized (Myform.Windowstate=2) ? 2

[Docpro777]

...Yes, everything was fine in VFP8 after all the VFP and XP-service packs and patches. Then this!:

The crash is the same for All my different computers with different printers and all those service packs updated, (even the one with windows 2000.)

Windows fatal errors take place only when windows are maximized (programatically or manually); this occurs consistently on the 3rd report preview/print (regardless of the report(s)).

Thanks in advance for any insight or ideas (to all):

Philip M. Traynor, DPM

http://www.doctorprofessional.com

 

[rgbean]

Philip,

Since I don't believe this is a widely reported problem, can you provide a simple reproduceable example? If you can, have you submitted it at the VFP bug reporting site?

http://support.microsoft.com/default.aspx?scid=/Support/vfoxpro/report/report.asp.

If you haven't reported it, but can put together a simple example, I'd be happy to pass it along to someone that might be able to help.

Rick

 

[rgbean]

Philip,

Maybe that's a clue. It's always very important that when you switch from one version to another, to recompile ALL the pieces (don't forget the Database Stored Procedures!) so that that the code will be properly rechecked for syntax differences and changes that may have come up in the VFP underlying pseudo code. It's even a good idea to do that for each new SP release.

Rick

 

[Docpro777]

Rick,

I'll certainly give your suggestions a try, to work out all the pieces. I'll let you know + or - shortly.


A side note ...: My VFP reports per se are truly quirky, especially report previews (for example):
1) While launching a preview, the report designer often appears to visibly 'jump in' ... just before the print-preview.
2) Reports appear maximized or normalized sporadically (probably due to foxuser.dbf memo fields).

Obviously I need to do a little more homework with report windows and such.

Thank you again for your thoughtful feedback.

Philip M. Traynor, DPM

http://www.doctorprofessional.com

 

[Docpro777]

I placed this command:

_screen.ActiveForm.windowstate=0

... just before the offensive report line (REPORT FORM (xreport) FOR &filt_expr PREVIEW)

This has worked around much of the crashing (for now).
Again, thanks for the logic.

Philip M. Traynor, DPM

http://www.doctorprofessional.com

 

[craigsboyd]

One other thing to try Doc...
just reading what you are posting here it sounds like something bad is building up as each successive report runs...issue SYS(1104) after (or before) the reports are run. I am curious if it has any effect on the problem you describe.

_{craig1442@mchsi.com}

"Whom computers would destroy, they must first drive mad." - Anon​

 

[Docpro777]

Very well Craig,

I'll try sys(1104) above and/or below the report command(s)

Thanks, Philip

Philip M. Traynor, DPM

http://www.doctorprofessional.com

 

[Docpro777]

Craig,

I tried sys(1104) (with and without '?' preceding) and to no avail.

Great idea purging the cache, albeit I'm running pretty high RAM these days (if that makes a difference)

Another side note: I've had to place WAIT commands to slow report processing down, i.e.:

WAIT window "" timeout 0.08

I'll see if purging the cache helps here (clear typeahead does not help)

Thanks for your great collaboration.

Philip

Philip M. Traynor, DPM

http://www.doctorprofessional.com

 

[craigsboyd]

To slow down processing, you may wish to use the INKEY() function or an API call to sleep. Either of them are more widely accepted means than using the wait window. Sorry, the other idea didn't make a dent on your problem.

_{craig1442@mchsi.com}

"Whom computers would destroy, they must first drive mad." - Anon​

 

[baltman]

To expand on Craig's sleep reference, the syntax is:

DECLARE Sleep IN Win32API INTEGER nMilliseconds
Sleep(1000)