Suffice it to say that the company maintains 2 systems, one in 6i and a "mirror" system in 11g. Every time the 6i forms are changed, an 11g version must be created, then some 11g "tweaks" added. I am looking for ANY way to try and tame this leviathan, even a third party tool.
My thought was to maintain a set of text-based, 11g templates, containing the 11g tweaks, then once the 6i counterpart is converted to 11g, convert that to text, write a program to apply the templated tweaks to it, then reconvert back to FMB.
This is the system I am stuck with. I wish it was 6i OR 11g, but it's not.
Well, we were somehow in the same situation with 6i and 10g: we developed in the lowest version and deployed in the lowest *and* the highest version. Somehow we are now in the same situation with 10g and 11g as we still support 10g but as for now we have no version specific code in our forms.
What we did was to have a library where the version specific stuff was implemented; this library had a 6i and a 10g version. As we used e.g. the FBEAN package in our forms (which was not available) the 6i version had a dummy implementation of the FBEAN package containing null procedure bodys so we could use the FBEAN package in 6i and 10g (though it did nothing in 6i). We also had a function which told us which version was up at runtime, so we could implements all the version specific quirks in the form like
if is_10g then do_something_10g_specific; else do_something_6i_specific; end if;
Of course now that we don't support 6i anymore there is some dead code around, but we'll clean it up as we encounter it.
But if you know what must be done to your 11g forms why generate the whole form from a object list report? You could simply convert it into 11g and do all the 11g specific stuff on your form using the JDAPI in batch?