It would be nice to be able to export or at least view on screen a current "dictionary" or key of all the Control IDs in use on a form. It would make building logic for forms significantly easier if you didn't have to constantly search for Control IDs controlling your different fields as well as Index#s by Session for ExecuteSQL.
Control ID/Index ID Dictionary
- Thread starter cjennings
- Start date
Yes!!!. We are working on some improvements in this area; one of which is to allow naming of controls to make it easier to identify. Allowing a full viewable list of current IDs is a good one also.
Phil Freed
New Member
I needed the same thing, so I am in the process of rolling my own using Perl. I would be willing to share the code if you are interested.
I wrote it for 10.3, and it may or may not work on other releases. For a specified session, it generates a list of fields, a list of controls, and a pretty-print the form logic. (Though "pretty" may be something of an exaggeration.) It knows the relationships between fields control IDs, which it uses to make the form-logic more readable. It is beginning to include information from the field definition tabs (like GoTo <control_ID>)
Perhaps most critically for me, the report catches some form logic errors -- like clicking on a control that's not a button, or referencing an ID that no longer exists. Little by little, I am adding features to the parser. I would welcome assistance (and to some extent, suggestions) from interested developers.
****
Caveats: THIS CODE IS COMPLETELY UNSUPPORTED BY TRACERPLUS; THEY HAVE NOTHING TO DO WITH IT. IT IS ALSO LARGELY UNSUPPORTED BY ME. IT MAY HAVE BUGS. IT MAY STOP WORKING WITH A NEW RELEASE OF TRACERPLUS. I MAY OR MAY NOT CHOOSE TO FIX IT IF IT BREAKS. IT MAY OR MAY NOT WORK ON YOUR VERSION OF TRACERPLUS. THE CODE IS INCOMPLETE, AND UGLY, AND DESPARATELY IN NEED OF A REWRITE.
Did I mention that this code didn't come from TracerPlus, and they don't support it?
When I told them I would be willing to share my code, they were (quite rightly) concerned that they would start getting bug reports and feature requests on it. If you have complaints, problems, or suggestions relating to this software, don't call them.
I wrote it for 10.3, and it may or may not work on other releases. For a specified session, it generates a list of fields, a list of controls, and a pretty-print the form logic. (Though "pretty" may be something of an exaggeration.) It knows the relationships between fields control IDs, which it uses to make the form-logic more readable. It is beginning to include information from the field definition tabs (like GoTo <control_ID>)
Perhaps most critically for me, the report catches some form logic errors -- like clicking on a control that's not a button, or referencing an ID that no longer exists. Little by little, I am adding features to the parser. I would welcome assistance (and to some extent, suggestions) from interested developers.
****
Caveats: THIS CODE IS COMPLETELY UNSUPPORTED BY TRACERPLUS; THEY HAVE NOTHING TO DO WITH IT. IT IS ALSO LARGELY UNSUPPORTED BY ME. IT MAY HAVE BUGS. IT MAY STOP WORKING WITH A NEW RELEASE OF TRACERPLUS. I MAY OR MAY NOT CHOOSE TO FIX IT IF IT BREAKS. IT MAY OR MAY NOT WORK ON YOUR VERSION OF TRACERPLUS. THE CODE IS INCOMPLETE, AND UGLY, AND DESPARATELY IN NEED OF A REWRITE.
Did I mention that this code didn't come from TracerPlus, and they don't support it?
When I told them I would be willing to share my code, they were (quite rightly) concerned that they would start getting bug reports and feature requests on it. If you have complaints, problems, or suggestions relating to this software, don't call them.Phil, I'm just seeing this now as I come back to see if this functionality has been developed over the last three years. It appears that it has not. I am not a developer, though I think I could still assist. Love that your code is looking for inconsistencies in your form logic!!!I needed the same thing, so I am in the process of rolling my own using Perl. I would be willing to share the code if you are interested.
I wrote it for 10.3, and it may or may not work on other releases. For a specified session, it generates a list of fields, a list of controls, and a pretty-print the form logic. (Though "pretty" may be something of an exaggeration.) It knows the relationships between fields control IDs, which it uses to make the form-logic more readable. It is beginning to include information from the field definition tabs (like GoTo <control_ID>)
Perhaps most critically for me, the report catches some form logic errors -- like clicking on a control that's not a button, or referencing an ID that no longer exists. Little by little, I am adding features to the parser. I would welcome assistance (and to some extent, suggestions) from interested developers.
****
Caveats: THIS CODE IS COMPLETELY UNSUPPORTED BY TRACERPLUS; THEY HAVE NOTHING TO DO WITH IT. IT IS ALSO LARGELY UNSUPPORTED BY ME. IT MAY HAVE BUGS. IT MAY STOP WORKING WITH A NEW RELEASE OF TRACERPLUS. I MAY OR MAY NOT CHOOSE TO FIX IT IF IT BREAKS. IT MAY OR MAY NOT WORK ON YOUR VERSION OF TRACERPLUS. THE CODE IS INCOMPLETE, AND UGLY, AND DESPARATELY IN NEED OF A REWRITE.
Did I mention that this code didn't come from TracerPlus, and they don't support it?
Are you still willing to share your code?
Dan, has this feature gotten anywhere? Or have you all published any "best practices" for working with large forms?