In testing GetFormAttrib, I think it will only pull metadata from forms that are published as a part of the current transaction - I tested this by using this script to grab a form attribute of a form in the same forms list as a form being published, but not a part of the current transaction. I did not get a result from the function. My best guess is the function will only grab metadata it can find in the polfile, meaning GenData (single step) would have to be in process. Hope that helps!
The form attributes and metadata are part of the content of the form resource stored in the library. The triggering process doesn't actually load the form resource from the library and therefore doesn't have access to content within the form. The normal process is that triggering decides to include the form based upon your extract data and then the form is loaded from the library. After you add the form, you can then check the attributes and metadata assigned to the form.
I suppose - with some enhancement - there could be certain attributes defined within the Form List (group) file for a given form that might be accessible during the triggering process, but as a general rule, no one wants the performance hit of loading forms from the library that may not become part of the transaction. Therefore, any attributes defined within the form itself will not be available prior to triggering it.
thanks ! Appears to be correct !
Still, I feel : The form attributes - most likely - may be more used to determine whether that form is eligible to get printed than it may be used for GENDATA processing .
I wish it is made available during the triggering.
Maybe there should be an option provided to "Load attributes during the formlist processing" so that it cannot affect the performance as well, when not used
Unfortunately, I don't think there would be a way to get the form data without actually loading the form from the library. So, without knowledge of whether you needed the information or not, it would end up loading every form - just in case you might want to reference data. And although you are specifically interested in a form attribute, what would stop the next person from saying "I need a section attribute", which would then require all sections to load too. That gets to be a lot of work for the few times this is the requirement. So, if anything is to be done, I would think all the "trigger" related information needs to be defined at the form list (group) level, which would already have been loaded at the point where triggering occurs. Going after library entries during the triggering process is a lot of overhead.