Rotate Controls in Report (Not rotating)

[AlastairP]

I am using report listener.
In the repport designer, I use the advanced tab and select a rotation.
1. The control does not rotate in the report designer
2. The control does not rotate in the preview

Report Engine Behavior is set to 90 in the tools/options menu

LOCAL loPreview
loPreview = NULL
DO (_REPORTPREVIEW) WITH loPreview

loPreview.CanvasCount = 1
loPreview.ZoomLevel = 5 && 75%
loPreview.Width = 1200
loPreview.height = 900
loPreview.ToolbarIsVisible = .t.
loPreview.topform = .t.

loListener = CREATEOBJECT("ReportListener")
loListener.PreviewContainer = loPreview
lolistener.ListenerType = 1

REPORT FORM testhistory OBJECT loListener

 

[Olaf Doschke]

It's important you also provide the reportpreview.app and reportoutput.app with your exe, or the behaviour falls back to the legacy report engine in the vfp runtime.dlls, also in reportbehavior 90. Besides, what you set in options is not becoming set in an EXE, this your IDE setting, any environment setting has a default and you have to have SET REPORTBEHAVIOR 90 in code, not only in your IDE settings.

Bye, Olaf.

 

[AlastairP]

I have SET REPORTBEHAVIOR 90, it does not make a difference

 

[Olaf Doschke]

You said you only set this in the tools/options menu
Therefore I had to assume you only have it set there and not in your application code.

Fine, but this is still just one thing I said you miss the other, reread please.
Also, what do you get, if you MESSAGEBOX(_REPORTPREVIEW) when you execute this from the EXEcutable (not when doing this in the IDE command window).
I assume you haven't set system variables to the APP file location, this doesn't happen automatically.

Reapeat: Behaviour falls back to the legacy report engine in the vfp runtime.dlls, also in reportbehavior 90

Bye, Olaf.

PS: As far as I tested the reportpreview.app, reportoutput.app and reportbuilder.app files have to go to the runtime folder, the smae location as the vfp9r.dll is, and _REPORTPREVIEW, _REPORTOUTPU and _REPORTBUILDER are "magically" having this path in them without you setting it. But without them at all VFP reverts to default legacy report engine.

 

[Nigel Gomm]

does it work if you don't specify a listener? i.e.

report form testhistory next 1 preview


or instead of the createobject()

DO (_REPORTOUTPUT) WITH 1,"lolistener"

?

the rotate effect is, AIUI, built into the ffc listener which reportoutput.app will give you by default.

 

[AlastairP]

I will test and report back

 

[Olaf Doschke]

Actually you simnply DO REPORT FORM, as always, and to use reportlistener support you can do as suggested here:

https://msdn.microsoft.com/en-us/library/ms965281.aspx

LOCAL ox AS ReportListener

ox = CREATEOBJECT('ReportListener')
ox.AllowModalMessages = .t.
ox.DynamicLineHeight = .t.
ox.ListenerType = 0
ox.PrintJobName = 'My Special Report'
ox.QuietMode = .t.

REPORT FORM MyReport OBJECT ox

But you only do so with a specific reportlistener defining a new behaviour you want, you don't do this with the "naked" native base Rerportlistener class, as given there.

You don't DO _REPORTOUTPUT or any of the other apps, the system does that when you run a report, not you. The system knows how to parameterize these apps. Doing so yourself you have to dig into how this works, it's not recommendable. You simply use the new OBJECT clause of REPORT FOR, if at all.

Having designed a report in reportengine 90 mode, you can have rotated controls/labels and colored ones, etc and you don't change your repart calls at all, the base behaviour of SET REPORTBEHAVIOR 90 will do that, nothing else needed.

Bye, Olaf.

 

[AlastairP]

OK, its been a while but I have solved this issue. It also applies to an earlier closed thread: thread184-1755484

So to recap, dynamics and rotation don't work when I use a listener, but do when I use the native PREVIEW

For example:

WORKED:

REPORT FORM myreport PREVIEW

DID NOT WORK:

REPORT FORM myreport OBJECT rl

The answer was simple and not really well documented. Instead of creating a standard listener, I needed to created a fxListener.

I was using this:

loListener = CREATEOBJECT("ReportListener")

But instead I found that I needed to create a different listener:

rl = NewObject('fxListener', '_ReportListener.vcx')

Problem solved.

 

[dbMark]

CREATEOBJECT() does not have as many parameters (just the ClassName plus data for the object) and so assumes certain defaults. NEWOBJECT() has two additional parameters. In most cases CREATEOBJECT() is sufficient, here more information was needed.

 

[Olaf Doschke]

>So to recap, dynamics and rotation don't work when I use a listener, but do when I use the native PREVIEW

Nobody said you should use a listener. And if using a listener, then why use tha native Reportlistener class? It addds nothing special to the report preview/output, if you don't program something into its methods and evetns. The thing turning on dynamics like rotation is REPORTBEHAVIOR 90, REPORT FORM Then already is in the modern mode considering the dynymic report properties.

What you say is, that the native reportlistener suppresses the dyanmics, I have to test this, but assume not so. It really does nothing.

One thing is for sure, there are mainly three different reporting modes, leacy (REPORTBEHAVIOR 80), modern (REPORTBEHAVIOR 90) and when having set modern behavior, you can use reportlisteners, but you don't have to, they are optional but offer you ways to hook into events you can't via report band or control properties or other "events" happening via report variables and grouping.

Bye, Olaf.

 

[Olaf Doschke]

In more detail, see

http://doughennig.com/papers/Pub/VFP9ReportingRunTime.pdf

SET REPORTBEHAVIOR 90 turns on object-assisted reporting by default. This means the
REPORT command then behaves as if you’ve specified OBJECT TYPE 0 when you use the TO
PRINT clause or OBJECT TYPE 1 when you use the PREVIEW clause.

So in reportbehavior 90 you specify a default object type, which in detail means:

If you’d rather not instantiate a listener manually, you can have VFP do it for you automatically
by specifying a report type:
report form MyReport object type N
The defined types N are 0 for outputting to a printer, 1 for previewing, 2 for “page-at-a-time” mode
but not send the output to a printer, 3 for “all-pages-at-once” mode but not invoke the preview
window, 4 for XML output, and 5 for HTML output. Other, user-defined, types can also be used

You don't instanciate a reportlistener, unless you want to make use of even more advanced features. You simply keep it at legacy calls of REPORT FORM in modern mode, and VFP will translate your TO PRINTER or PREVIEW clause to object type 0 or 1 and instanciate a reportlistener itself, which is embedded within reportoutput.app.

If you instanciate any reportlistener, you get any behavior, some inherit rendering dynamics, some not. From what you did you can say the native reportlistener class does not. But why fiddle with this? You already get what you need with the listeners reportoutput.app has embedded.

Bye, Olaf.

 

[Olaf Doschke]

Most important: You get legacy reporting at runtime, even if you SET REPORTBEHAVIOR 90, if you don't have the reportoutput.app in the EXE folder, the modern report behavior is only partially defined in the VFP9r.DLL, most parts are written in VFP itself and compiled into this app file, you find sources of reportoutput.app (and also reportbuilder.app and reportpreview.app) in Xsource. Xsource.zip should be in HOME()+"Tools" or you get it from the product hmoepage downloads, if not from VFPX at codeplex. Just to say you could take a look at this code, not that you need it, VFP has the necessary APP files in Home() for redistribution of the new reporting features.

Bye, Olaf.

 

[AlastairP]

Thanks for your help.