August 1st, 2008 
FileMaker Pro to Revolution Part Two
Painlessly move from Filemaker to Revolution
Converting to Revolution
In the previous newsletter, we discussed collecting your information from Filemaker to convert your database to Revolution. In this article we will examine how to make that conversion.
Step 3 - Convert Database to Revolution
Click the Convert Database to Revolution button to start the process of converting the imported Layouts and ScriptMaker scripts to Revolution.
FmPro Migrator Developer Edition converts each FileMaker layout into a Revolution card, containing all of the fields, portals, text, images and buttons from the original layout. The converted layouts are placed into a new Revolution stack file having a Browse/Find status area, Calendar pop-up substack, utility handlers, converted handlers and stock graphics. The newly created stack file will be left open on the screen, and it will be possible to select each card from the Layout menu in the Status Area group at the left side of the card. The converted Layouts will be saved automatically into a file named Application.rev within the output directory.
FmPro Migrator Developer Edition converts each embedded image on a Layout, into a cross-platform compatible image within the Revolution stack card. If any images cannot be converted due to being corrupted, these images will be skipped, and will be listed in the file named FmPro Corrupted Images Report.txt within the output directory.
In addition to converting the FileMaker layouts, FmPro Migrator Developer Edition also converts each FileMaker ScriptMaker script into a handler within the new Revolution stack. These scripts will be placed into the FmPro_Scripts_btn on the Images card within the stack, and two output files will be written to the output directory:
FmPro Original Scripts.txt file - This is a text version of the original ScriptMaker scripts, and is made available for documentation purposes so that Revolution developers can review the original unconverted scripts.
FmPro Converted Scripts.txt - This text file contains the converted Revolution code. Any instructions which could not be converted will be commented and the original comments will be retained within the scripts.
The Template Stack
FmPro Migrator Developer Edition uses an internally-stored template file for the Revolution stack which it generates from the FileMaker Pro Layouts. This file is written to the output directory as a file named Application.rev at the start of the conversion process.
Revolution developers can supply their own stack in place of the Application.rev file, in order to make use of their own customized handlers and graphics. FmPro Migrator Developer Edition checks the output directory for a file named Application.rev, prior to writing out its own template stack. If a file having this name already exists in the output directory, it is not overwritten, and will be loaded and used by FmPro Migrator Developer Edition.
A replacement template stack should have the following features, in order to be compatible with FmPro
Migrator Developer Edition:
setLayoutList - stack-level handler - This handler puts the list of cards into the Layout list menus of the Browse and Find groups. If you don't want to have this feature, you can simply include a handler having this same name but containing no executable code.
displayCalendar - stack-level function - This handler displays the calendar pop-up menu within fields which have this feature configured within the original FileMaker Pro Layout. This function returns empty or the date picked by the user.
browserInit
browserGo
browserEnsure
browserFinalize
browserBack
browserForward
browserRefresh
browserStop
These stack-level handlers control one ore more revBrowser controls on a card. Each handler takes a parameter (pBrowserNum) as the number representing the revBrowser control, and is used to define its name on the card. There could be multiple FileMaker WebViewer objects on a single Layout, therefore each WebViewer will be converted into a separate Revolution revBrowser control having a different name on the card.
statusAreaWidth - stack-level customProperty - This custom property indicates the width of the Status Area at the left side of the window. The Layout_Objects_Group is automatically moved over to accomodate the width of the Status Area after all of the cards have been created. Set this custom property to 0 if you don't want to have a Status Area within your template stack.
templateStackName - stack-level customProperty - This custom property provides the name of the template stack file.
Supported FileMaker Pro Layout Object Types
The following FileMaker Pro Layout object types are currently supported by the conversion process:
Fields Portals Text Lines Rectangles Rounded Rectangles Ovals/Circles Grouped Objects Images Buttons WebViewer
Each FileMaker Pro layout object is re-created as an equivalent Revolution card object, using the formatting and style attributes of the original object.
Stylized FileMaker Pro layout text objects are converted into Revolution text labels, having the embedded text styles of the original object defined with the HTMLText property.
The supported field display options include Check Box Set, Radio Button Set, Pop-Up Menu, Drop Down List and Calendar. Pop-Up menus and Calendar objects are created with embedded Revolution script code to automatically populate the underlying field.
Unsupported FileMaker Pro Layout Object Types
The following FileMaker Pro Layout object types are not currently supported by the conversion process:
Tab Control Objects - FileMaker Pro includes a Tab Control object which looks like the Tab Panel in Revolution. But unlike Revolution, all of the objects for the main window and the Tab control objects are located on the same FileMaker Pro Layout. Within Revolution, this functionality would involve creating a separate card for each panel of the Tab Panel. To convert a FileMaker Pro Tab Object, move the objects within each tab onto a separate layout, having the same fields surrounding the Tab Control object and replacing the Tab Control with a graphic image. This is the same technique which was used with previous versions of FileMaker prior to the introduction of the Tab Control. None of the objects within a Tab Control are re-created within the Revolution stack.
Conditional Formatting - Conditional formatting can be used to automatically resize fields and change the appearance or color of field data based upon a calculation formula. The automated resizing or movement of objects can be done by using Revolution's Geometry Manager. Within Revolution, the movement of objects can even be made dependent upon the movement of other nearby objects, offering more control of objects than is available within FileMaker Pro.
Value Lists - Value Lists within FileMaker Pro can be implemented as either static or dynamic value lists. Static value lists are similar to pull down menus in Revolution populated with a static list of values. These static values need to be manually copied from the FileMaker Pro database. Dynamic value lists can be implemented in Revolution by running a handler to run a SQL query prior to displaying a menu. Revolution's Query Builder can also be used to implement dynamic value lists by retrieving data from SQL databases.
Cosmetic Changes Required - Example #1
In general, each created object within the Revolution stack will appear very similar to its counterpart in the original FileMaker Pro Layout. However, some changes may be required within the generated stack file. This image of a converted Revolution stack file shows 3 changes which should be made: 1) The Help button icon has been created, but the (?) image is sitting under the shadowed circle object. FmPro Migrator Developer Edition builds each layout object in the order it is found within the Layout XML file. Therefore some objects may be created in the wrong order for display purposes. The solution is to change the layer of each object so that they display properly. The shadowed circle object was also moved left by 1 pixel. 2) There is a button sitting under the graphic of the folder icon, and this button has its showName property enabled. Setting this property to false makes the button display more cleanly on the card. 3) The text of the 3 text buttons across the top of the card are displayed a little bit too high.
Cosmetic Changes Applied - Example #1
This image shows the stack after the 3 cosmetic changes were made.
Original FileMaker Pro Layout
And for comparison purposes, here is an image of the orignal FileMaker Pro Layout.
Cosmetic Changes Required - Example #2
Here is another converted Layout stack file which needs different cosmetic changes:
1) FmPro Migrator Developer Edition creates each Revolution field as an opaque field, in order to insure that fields having a background color are displayed properly. Text objects however, are created with their opaque property set to false, allowing other objects to show thru. But the dbMaintenanceMessage object shown on this layout is not a Text object, it is a field object, so it has been created to be opaque - thus hiding the text label which it overlaps. Therefore in this location, the dbMaintenanceMessage field should have its opaque property set to false. 2) This horizontal line is supposed to be colored green, but the correct color was not properly located within the original XML code. This same problem also occurs with the objects marked (4) and (5). However the remaining horizontal line objects on this same layout (not shown) did retain their correct colors. 3) These two text label buttons ended up wrapping within the field. Changing the text margin from 2 to 4 and widening the fields solved these issues.
Cosmetic Changes Applied - Example #2
This image shows the stack after the 5 cosmetic changes were made.
Layout XML Code
FmPro Migrator Developer Edition uses the XML code put onto the Clipboard by FileMaker Pro as its source for layout information. If you want to review the XML code defining the objects on a layout, just click the Export Layouts as XML button on the GUI tab. The layout XML code will be exported as individual text files within a folder named Layout_XML_Files, within the output directory. This XML info could be used by developers who want to perform additional analysis of the layouts converted into Revolution cards.
In the next newsletter we will wrap up with a look at the FMPro custom property set.