[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7] [ 8 ] [ 9 ]

The first time you run this Wizard, your results won't be too different from previous framwork applications. But you will now have editable versions of all the framework components for which you've specified components on the various pages. For instance, if you specify a template folder on the "Templates" page, you will get copies of all the non-OOP templates files in that location.

If you change the Parent VCX as suggested on the second page of the dialog, you can have one or more layers of superclasses between your application's subclasses of _FRAMEWK.VCX. You'll create team-specific enhancements in these layers.

This version of the Wizard will create the initial classes for you, as subclasses of the components in _FRAMEWK.VCX, if you specify a VCX name that does not exist. Later, you can create more layers of subclasses from the one the Wizard derived from _FRAMEWK.VCX, and designate your subclass layer in this dialog as appropriate. The VCX you designate on the second page of this dialog should always:

  • be the immediate superclasses (parent classes) of the application-specific VCX for this application, and
  • include all the required subclasses of _FRAMEWK.VCX, with the same names as the _FRAMEWK ancestor classes.

After you've designated positions for all your editable components, you won't need to do it every time you start this Wizard; it saves as much information as possible in special records of _FRAMEWK.DBF.

You can also affect the components used on a particular Wizard run by the list of preferences you give it in the second parameter you pass NEWAPPWIZ. To see a full list of possible preferences you can pass, as well as how you can create other subclasses, see the comments in NEWAPPWIZ.H.

You can also save different sets of preferences for use on different Wizard runs, and make these preferences available without directly calling NEWAPPWIZ.PRG. To do this, create different WIZARD.DBF entries with different preferences listed in each record's Parms field. This field equates to the second parameter the standard WIZARD.APP passes to each individual Wizard. When you pass a list of preferences to NEWAPPWIZ as its second parameter, you're doing the same thing that WIZARD.APP does without using WIZARD.DBF. Either way, the rules for passing the preferences is the same:

  • the full list of preferences, and the order of the possible entries in the list, is given in NEWAPPWIZ.H
  • you can delimit the entries either by commas or carriage returns.

New subclasses of the base Wizard class you'll find in NEWAPPWIZ.PRG will automatically show the user a MESSAGEBOX(), asking if they should be registered in WIZARD.DBF. If the answer is "yes", the new subclass gets its own record, with its Parms filled out with its default preference settings, in WIZARD.DBF.

You will find lots of ways you can build Application Wizard classes that modify the newly-generated project. The example shown here gives you some useful features, but others will occur to you once you have decide how your team will use the framework.

Project Hook and Builder-driven components:
documents and the metatable

As described in the section on document management above, the framework uses a table to drive its "knowledge" about the documents in an application.

This knowledge is exploited in various _documentpicker classes that allow users to pick forms, reports, and other types of files. Although such a table is not required, the extra information it can store about each document helps the framework customize documents for you.

If you use the default Application Builder to access the metatable, you should leave the metatable's name at its default (<projectname>_app.dbf), because the Builder doesn't support your changing this table's name, at least at this writing. However, the framework will allow any name for this table. If you edit the metatable directly instead of using the Builder, you can also change the name of the metatable. Just change your application's app object's cMetaTable property to point to the right table.

When your application starts up, the framework checks to see if a metatable is required by this application. If it is, the framework will validate the existence and appropriate structure of this table. However, it looks only for its own required fields and tags -- the metatable can have additional fields and tags if you want.

If you edit the metatable directly, not only can you access your additional fields, but also you can put in more sophisticated information than the Application Builder is able to support.

The following table will give you more complete information about the structure of the metatable and the use of its required fields within the framework. The "use" column to the right tells you what to put in these fields, when you want to add documents to your application manually. You will probably be most interested in the Doc_wrap and Alt_exec fields, which give you extra flexibility.

Regardless of how you use this table to store information about your documents, if you edit it manually, remember to add these documents into your Project, too, so the APP/EXE will have access to them at runtime. See the section on the importance of the APP or EXE to your framework app, above.

Table: The metatable structure

Fieldname Type Use
Doc_type C This field contains a character to distinguish between document types.  Currently, "F" is used for "forms" and "R" is used for "reports".  But this designation just determines how the document type is presented in the interface, not necessary what type of VFP source code file underlies the document.  See Alt_Exec and Doc_wrap fields, below. More document types may be added.  The framework already contains one extra type, "A", specifically reserved for you to add application information.  The framework will not use "A"-type metatable records in any way, so the reservation of this type simply allows you to use metatable records, or perhaps one metatable header record, as a convenient place for system storage.  In most cases, you would want to transfer the contents of such a record to application properties on startup.
Doc_descr C The “caption” or long description you want to show up in document picker lists.
Doc_exec M The name of the file to be executed, usually an SCX or FRX. In the case of a class to be instantiated, this is the VCX name. For Form-type documents, the file extension is assumed to be SCX unless this entry is marked “Doc_wrap” (see below) or the Doc_class field is filled out, in which case the extension is assumed to be VCX. For Report-type documents, the file extension will default to FRX unless this entry is marked “Doc_wrap”. If no FRX exists by that name, the application object looks for an LBX. In all cases, you may also fill out the file extension explicitly. In all cases, if you Include the file to be executed in the project, you do not need to use paths in this field. If you wish to Exclude the file from the project, you may use path information. Relative pathing should work, and is probably the best policy in this case! 
Doc_class M The class to be instanced, where the doc_exec is a VCX.
Doc_new L Mark this .T. for a Form-type document you wish to show up in the FileNew list. For a Report-type document, this field denotes an editable report (new report contents, or even a new report from a template). This capability isn’t implemented yet.
Doc_open L Mark this .T. for a Form-type document you wish to show up in the FileOpen list. For a Report-type document, this field denotes an runnable report or label and will place the item in the report picker list.
Doc_single L Mark this .T. for a Form-type document that is modeless but should only have one instance. The application object will bring it forward, rather than create a second instance, if the user chooses it a second time.
Doc_noshow L Mark this .T. for a Form-type document that you wish to .Show() yourself after additional manipulation, rather than allowing the DoForm() method to perform the .Show(). Note: you will have to manipulate the application’s form collection or the current _SCREEN.Forms() contents to get a reference to this form, so you can manipulate the form and then .Show it when you are ready. If you need this reference immediately, the best place to get it is probably the application's aForms[THIS.nFormCount]. You can see an example of this usage in the _application’s DoFormNoShow() method.  You can create Doc_Wrap-programs as described in the entry for the next field.  Your wrapper program can take advantage of the DoFormNoShow method, receive its return value (a reference to the form or formset object), and proceed to do whatever you want with it.
Doc_wrap L If this field is marked .T. indicating a “wrapped” document, the application’s DoProgram() method will execute instead of its DoReport()/DoLabel() or DoForm() method. If you omit the file extension, the DoProgram() method uses the standard VFP extension heirarchy to figure out what file you wish to execute (“.exe .app .fxp .prg”).
Doc_go L If this field is marked .T. and the document is “Form”-type, the form uses the framework’s standard Go context menu for navigation. The menu name is configurable using the application object’s cGoMenuFile property. This field is not used for report-type documents.
Doc_nav L If this field is marked .T. and the document is “Form”-type, the form uses the framework’s standard navigation toolbar for navigation.  The class is configurable using the application object’s cNavToolbarClass and cNavToolbarClassLib properties.  This field is not used for report-type documents.
Alt_exec M If this field is filled out, it takes precedence over the doc_exec field above. When the user makes a document choices, _documentpicker’s ExecDocument() method converts the contents of this field into a string and executes that string as a macro. Your alt_exec statement can be anything you choose, and it can use attributes of the metatable, including the Properties field (below) however you want. For example, you can choose to have the metatable editable (on disk) rather than Included in the APP/EXE, and you can place information in the Properties field dynamically at runtime. Your document would then be able to be “aware” of this information by examining the current contents of the Properties field.
Properties M This memo field is not used by the framework in any way. It’s for developer use, primarily in conjunction with the alt_exec field.
User_notes M This memo field is not used by the framework in any way. It can be used for notes that would be displayed as help text for a particular form or report, etc.

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7] [ 8 ] [ 9 ]