Re: Strings in compiled forms

In article <jolomoCM06xG.37y@netcom.com> jolomo@netcom.com (Joe Morris) writes: >Hello, > My site uses sccs for our version control and I'm forcing everyone >to embed string commands in their 4gls so that the 'what' command >will tell me which versions of the 4gls are in a compiled 4ge. > Does anyone know of a good way to implement this in forms? We also use SCCS and have this same requirement, but I have yet to come up with any solutions I'm completely satisfied with. When you say that you don't want to place the SCCS info in "the" screen section, do you mean the one that 4GL users see, or *any* screen section in the form? form4gl will compile a multi-screen form, so you can define a dummy second screen with the SCCS string in it. It will be placed in the ".frm" file, but the 4GL program won't use it. The drawback to this approach is that form4gl will create a ".err" file, issue a warning, and exit with a non-zero status. This is kind of a hassle when you're using make. Another idea I had recently was to use an INSTRUCTIONS section, again like an sperform form. form4gl will allow many of the instructions that sformbld recognizes like "after editadd", etc. You might try something like: instructions after editadd of your_column if your_tag = "some_impossible_value" then let your_tag = "%Z% %M% %I% %G% %U%" form4gl compiles this quietly with no .err file and a zero exit status. There might be a more clever way to do this than the above, but you probably get the idea. The potential problem with both of these schemes is that they depend on form4gl's continuing to be essentially the same program as sformbld. I'm not sure I'd want to bank on that if I was looking at maintaining 100's of form source files. In fact, I'm sure I wouldn't. We use an approach here that gives us almost the same information. We have a home-grown utility that is basically a table-driven front-end to the install command. Our utility allows us to do a binary compare with cmp(1) of a newly created binary with it's installed counterpart rather than overwrite it. Since form compilation is relatively quick and the resulting files small, we can easily check out and "what" the source, then compile and compare the binaries. This has been good enough for us. Hope this helps, Walt. -- Walt Hultgren Internet: walt@rmy.emory.edu (IP 128.140.8.1) Emory University UUCP: {...,gatech,rutgers,uunet}!emory!rmy!walt 954 Gatewood Road, NE BITNET: walt@EMORY Atlanta, GA 30329 USA Voice: +1 404 727 0648