FiveTech Software tech support forums

Dear All ,

May I know Report Preview how can be REPORT PREVIEW customized in which buttons and bar can be modifiable ? I am not sure whether this requirement is posted by others developer.

Thanks
Shridhar

Hello Shridhar,
preview is inside c:\fwh\source\classes\rpreview.prg.

I use different rpreview.prg for different tasks.

Best regards,
Otto

rpreview.prg is a CLASS. Because it is often upgraded, you can inherit it to your own class with the modifications. Thus if the preview class changes, you won't have to go back and modify the newer versions.

May I know Report Preview how can be REPORT PREVIEW customized in which buttons and bar can be modifiable ?

If we want some modifications to the existing buttonbar, we can use:

Code: Select all  Expand view

RPrevUserBtns( bNewUserBtns, nBarStyle, aSize )
 

Usage:

Code: Select all  Expand view

RPrevUserBtns( {|oPrev,oBar| ExtraBtns( oPrev, oBar ) }, ;
    nBarStyle, ; // 2007,2010,etc
    aSize ) // { width, height }
 

These new buttons will be insered after PrinterMenu button.
If this function returns .t., no more buttons will be added.
If returns .f., all other buttons like saveas, pdf, etc. will be added next to our new buttons.

In case we want to have a totally different buttonbar instead of the default buttonbar, we can use

Code: Select all  Expand view

TPreview():bButtonBar := { |oPrev, oWnd| MyCustomBar( oPrev, oWnd ) }

Please see the sample I posted in
viewtopic.php?f=3&t=43185

Now, let us consider the case we create a totally new class or our own for preview and use our class instead of the default TPreview class.

If we write our own RPreview.prg and link it with our application, the entire application uses our class only.
Instead, we recommend:

Code: Select all  Expand view

oOldClass := SetCustomPrintPreview( { |oDevice, oReport| TMyPreview():New( oDevice, oReport) }

Now all previews use our new class, instead of FWH TPreview class. This TMyPreview class may be a subclass of TPreview class or a totally independent class.

At anytime we can revert to the Default Preview in the same application by

Code: Select all  Expand view

SetCustomPreview( NIL )

This way we can use different Preview classes in the same application depending on the need.

Another way:
If for a particular Report we want to use a different Preview class of our own:

Code: Select all  Expand view

oReport:bPreview := { |oDevice,oReport| MyCustomPreview():New( oDevice, oReport ) }

For a sample, please see:
fwh\samples\ximage02.prg
This program demonstrates the power of TXImage to provide preview.

Hello Tim,
I just want to briefly comment on inheritance. I use it. I think concepts always need to be reevaluated over and over again.
The powerful editors with comparison functions (e.g., VS) make it very easy to compare different states of software.

There is also no general statement. But I think inheritance can also make things more complex. A custom preview might often be easier. For example,
I use a PDF printer driver instead of the built-in PDF functions. The whole code for PDF creation is unnecessary for me.
The classes are easier to read when there is less code in them. If we constantly inherit, then it becomes - like in daily life - more complex with each inheritance.

Sometimes the question arises whether Fivewin should only be for experts or also for dBASE users who want to quickly build a solution.

Best regards,
Otto

whether Fivewin should only be for experts or also for dBASE users who want to quickly build a solution

Definitely to be used by dummies like me with a very few lines of code and that too with simple commands.
And in fact FiveWin is made like that.
Even today, we can build a fivewin application with code no more complicated than what we were used to with Clipper, decades ago.

At the same time, experts can also use it the most complex way.
So FiveWin is for BOTH.

Dear Rao,

if you compare the contributions from the past to today, you will see that they have decreased significantly. One reason is that the demands from Fivetech are too high, and the source code - I mean within the classes - is too complex.

Practically, no one can contribute ideas or work together anymore.

But it's about the overall product and solutions.

For example, where should one start if they want to work on a flexible xBrowser row height?

But that's just my opinion.
Regards,
Otto

Otto,

You are correct. Five Win has become VERY complex. Also, because the parts are inter-related, and some classes draw from others, I prefer to not modify and link my own "alternatives". In the past, I did write an alternative rpreview, but every time an update came out, if there were any changes, I had to use a compare utility, and update, or re-write, my alternative.

Since then there have been some global commands that made it easy to keep consistent "alternatives" while using the updated commands. This was especially true for the button bar, and how email has been handled.

What I like about inheritance is that I can write my modifications and never touch the FW libraries when they are updated. For me it has worked very well, and it is very rare that I ever encounter a problem.

Perhaps one of the biggest problems is that we really do not have any reliable documentation. The included help files are out of date. To understand how any feature works, or to see it's current implementation, we have to do a forum search, a search of the "What's new" doc, check out the include files, and often go back to the actual source code. There are samples, but we don't have any description of what is included in them, and often I find the name given to a sample does not help in finding the right one to see how code should be implemented. In addition, some samples are so old they are irrelevant.

To me, the biggest frustration with Five Win is the lack of documentation. I realize today most companies don't put out much effort to document their offerings, but I'm old school, and so I really do like to seek a full understanding of the capabilities within the tools I use.