Source control and triggers. Problem

[jerrysvensson]

Hi all.

We have a problem with recreating Triggers on fields. When we try to recreate the application all field triggers are removed.

We are running v11 SR2, but I verified it on latest v11.2 SR3.

Are we doing something wrong?

Has anyone got Triggers working with Source control?

Steps:

Create an app with field event triggers.

Create the -prj catalog.

Open the app and save. Xml files are created.

Delete app and create a blank QV app with same name.

Open app and reload.

No triggers are left.

[magavi_framsteg]

Hi Jerry.

I've noticed about the same behavior in QV v9 SR2-7, but without the -prj source folder.

My steps to reproduce were:

- Create app

- Create data model with a few fields

- Create field event trigger on field X

- Remove field X

- Readd field X and the trigger is g0ne

Seems somehow related.

Field event triggers are lost when the field is removed.

How do other ppl do when using QV source files to recreate or deploy documents?

Is there another undocumented way of getting back the lost triggers?

Kind regards

Magnus Åvitsland

BI Architect Consultant

Framsteg Business Intelligence Corp.

[Anonymous]

Jerry

You mention Triggers disappearing after re-creating a qvw app from the -prj catalog.

Magnus mentions having seen this on removing and re-adding a field.

What I certainly know is that the -prj catalog does not contain any variables, so all variables are 'lost' on re-creating a qvw app from the -prj catalog.  To avoid this what one should do is create all variables in the load script, so that on reloading the qvw app the variables are re-created.

Could it be that your field event triggers are dependant on some 'lost' variables ?

If so then ensure you are creating all variables in the load script.

Best Regards,     Bill

[jerrysvensson]

Hi

It has nothing to do with variables.

The problem is that AllProperties.xml which contains the triggers gets overwritten and triggers removed when there is no data in the application.

[#5]

That's correct. A good workaround is to create a script (with Powershell or something similar) that scans through the AllProperties.xml file for the fields that you want to have triggers, and replaces the <OnSelectAction></OnSelectAction> node with one containing the correct syntax for the trigger you're after. For example, if I wanted to add a trigger to run a macro called 'MyMacro', it would look like the following:

    <OnSelectActionItems>

        <ActionItemDef>

          <Type>TYPE_MACRO</Type>

          <Parameters>

            <StringExpr>

              <v>MyMacro</v>

            </StringExpr>

          </Parameters>

          <StateName></StateName>

        </ActionItemDef>

      </OnSelectActionItems>

For other types of triggers, the best way to get the xml syntax correct is to recreate the trigger manually in the desktop client, save and exit, then search the xml file for the given field and make a note of how it is displayed.

My script contains a hashtable that pairs each Field name with the required xml that I need to insert. If you keep this updated every time you add a trigger, it should be easy to run and 'repair' your 'AllProperties.xml' if the triggers ever drop in future. Once the xml has had the triggers re-applied, you should find them there next time you open the qvw.

Hope this helps.
-James