INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

Tips -N- Tricks

How can a user modify a report without using the FoxPro report designer by ChrisRChamberlain
Posted: 24 Jul 00 (Edited 12 Dec 02)

The following does not include source code, but simply outlines the methodology which enables a user to interactively change the properties of a report at runtime.
 
From a developer's point of view, you will need to acquire some knowledge of FoxPro report files - I can recommend the  following:- Demystifying Visual FoxPro Report Files -- FoxTalk August 2000 http://www.foxtalknewsletter.com/FT/FTMag.nsf/0/F9FA874556FBE8768525692E007B8459
 
 
For simplicity, create a report, Report1, with a Detail band only.
 
Each report object will require identification, so right click on the object and sequentially enter the equivalent default FORM name in the comment field, ie textboxes become "Text1", "Text2", labels becomes "Label1", "Label2", images become "Image1", "Image2", lines becomes "Line1" etc.
 
Create a form and add the equivalent controls that exist in the report, using the default names, thus the REPORT textbox object with comment field "Text1" has the equivalent FORM textbox "Text1", etc. Select all controls and change the .Left property to 800, thus apparently giving you a blank form.
 
By scaling the form's properties, the central part of the form will become a WYSIWYG "view" of the whole report. In the .Init event of the form, the report Report1 is opened as a table ALIAS TEMPREPO, and the .Refresh event "reads" (SCAN..ENDSCAN) the table TEMPREPO, to determine the form's control's properties. Typical scaling factors are INT(TEMPREPO.Hpos / 300) and INT(TEMPREPO.FontSize / 2.65).
 
Scaling also enables the developer to add additional controls, such as grids, combos, lists etc to the left and right of the "view" which allows data to be drag and dropped onto the "view". You will need a Checkbox to turn the Textbox borders on and off to ensure the "view" is a genuine representation of the report.
 
You can compare the form's presentation to a graphics application, where the central portion is the pasteboard and the surrounding controls become the "palettes".
 
 

You will need a toolbar class with a considerable number of controls, which are .visible = .T./.F. according to which "view" control class has focus.
 
A typical minimum list showing for a textbox follows.
 
cboFonts - List of available fonts
spnFontSizes - Font sizes
spnLeft - Moves left position
spnTop - Moves top position
spnWidth - Changes texbox width
(Set Textbox.IntegralHeight = .T. for automatic height adjustment)
cmdForeColor - GETCOLOR()
cmdBackColor - GETCOLOR()
cmdDelete/Recall - Hides/Unhides the textbox
 
The following Checkboxes should be set to .Style = 1
chkTransparent - Set the backcolor to be transparent
chkBold - Bold
chkItalic - Italic
chkUnderscore - Underscore
chkStrikeThru - StrikeThru
chkLeft - Left text alignment in textbox
chkCentre - Centre text alignment in textbox
chkRight - Right text alignment in textbox
chkHorizontal - Centres textbox in report
 
In use, the user clicks on a WYSIWYG "view" control, the toolbar is refreshed with the control's relevant to the selected WYSIWYG "view" control,and then changes it's properties with the toolbar. The toolbar event's REPLACE TEMPREPO.field WITH data and the form's .Refresh event shows the scaled updated WYSIWYG "view".
 
Assuming drag and drop to be in use on the form between the various controls, moving a WYSIWYG "view" control by the spinners alone can be tedious. Dragging and dropping controls as well as data is confusing. An alternative is to create a "move mode" where the user clicks on a control, the cursor changes to a cross, the toolbar's spinners monitor the coordinates and the next click moves the control to the new coordinates.
 
You will certainly need a cmdButton, caption "Revert", to restore the original report properties.
 
The report can be saved as a record in a table called REPORTS with fields (title C(50),frx M,frt M) by APPE MEMO frx from Report1.frx, etc.
 
 

Cons?
 
There is no facilty to add report objects or to change a report object's .ControlSource.
 
Pros?
 
By saving the reports in a table, a user can create a library of reusable report styles.
 
The report can be run exactly as the client and the developer originally conceived it.
Alternatively a completly new and exciting dimension in user defined report presentation can be experienced.
 
The interface is intuitive as the toolbar will be familiar to anyone using Office or graphics applications. Providing the developer error traps illegal values, the user will have a hard job crashing or trashing the report, and you can safely let your user "loose" on it!
 
Being WYSIWYG, the user gets an immediate impression of the report without the necessity to preview.

Back to Microsoft: Visual FoxPro FAQ Index
Back to Microsoft: Visual FoxPro Forum

My Archive

Resources

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close