The editor for VCX/SCX edits directly the form/visual class files. I open the files as a standard table (USE myform.scx AS editscx IN 0) and then read the table and parse the objects (form controls and tables), properties, and methods. I also open any class references in order to also parse the properties for those. As I read the VCX/SCX table, I create my own cursor to hold the objects (form controls and data environment), methods, and properties to be edited. On save I write the contents of the cursor back to the original VCX/SCX file in a BEGIN TRANSACTION - END TRANSACTION so if a problem is detected I can roll-back. I also have the option to save the original VCX/SCX files with a .bak extension added; i.e., myform.scx.bak and myform.sct.bak. This gives a full backup after the edit save.

So there is not any use of a middle conversion program to translate to a PRG to edit -- the VCX/SCX files are edited directly. So technically I hack the VCX/SCX and MNX files to edit them. The PRG is a direct edit and save (it is an ASCII text file so it is easy...

I began writing the editors back around 2004 mainly because I wanted to see the line numbers in the editor and these have grown since then. One of the limitations in the standard (shipped) VFP design-time editors is that you cannot edit a visual class while it is being referenced in a form that is being edited. For instance, if you have a form that uses a visual class button definition and you then open the form for edit, you cannot also open the button visual class for edit at the same time -- VFP will give you an error message that you cannot edit a visual class that is in use. My editors do not have this limitation -- you can edit both at the same time. The editors support multiple monitors which VFP does not. Each of the editors run as a "As Top-Level" form so they can be positioned anywhere outside of the VFP main window. I do not use modal forms in order to allow one editor to be waiting for input and then to be able to switch to another editor or to the main VFP window; I do this with what I refer to as semi-modal forms. The semi-modal form is actually a modeless form but I use a "shadow-box" to dim the main form before calling the child form. Values are then passed via a RAISEEVENT command back to the main form, with the child form then being destroyed and the shadow-box set to Visible=False. So there are very limited modal forms as this would affect the entire VFP session as these editors are executed from within VFP design-time (they are APP files). They would possibly have some run-time errors (I have not tried) if compiled to an EXE and executed outside of VFP since I use some commands that are not allowed in run-time outside of VFP design-time by VFP (these are mainly commands for parsing the properties).

I also have a Table Editor replacement, a Table Browser (to allow for the table to be viewed and moved to any monitor), and a full replacement for the Project Manager. The replacement Project Manager is integrated with the editors so that these are called from it (you can also call the standard VFP editors as well). The Table Editor allows for modeless edit of tables (fields, properties, and indexes) but there is not any 'hacking' -- the changes are applied via standard VFP table edit commands. The replacement Project Manager reads the PRJ file and then creates its own file type (GKK) for its project table. The standard PRJ file is updated during the build process via standard VFP commands (no hacking) as the PRJ is required to execute the BUILD command. The Table Browser opens the tables and displays in a MDI form view.

If you are interested (or anyone else) I am willing to provide the editors with full VFP source code. The editors use two ActiveX controls - CodeMax (editor component which is licensed and can only be used with these editors) and UltimateGrid (open source via The Code Project -- used for the property editor interface).

Greg