Assuming you only need these actions to run during first time install, then why not use the "NOT Installed" condition on them?  Presumably you don't need them to run on uninstall either, but if you do, you could use NOT Installed OR REMOVE="ALL"

Currently the action in question is also nested in a NOT PATCH condition block as well. 

In short, I don't want the action to run during a patch or during repair install when a different user logs in to the application.  Will the NOT Installed condition meet this criteria?

The NOT Installed condition will only be true when the application is being installed for the first time. Any subsequent repair, maintenance or uninstall operations will always have NOT Installed resolving to false.

OK, I don't know if I should make this a separate post or not, but it ties into the NOT Installed condition as I'll have to condition the action I'm about to describe as such.

Let me give a little background first.  When a Standard User logs in after an Admin has installed our application, the app starts, then the repair starts, completes, and the app is then ready to go.  However, there's a sequence problem in that when the app actually starts, it tries to grab HKCU registry entries that are not there yet and won't be until the repair completes.

So, when the app continues after repair, some registry values that are displayed are actually blank, but they have been written by the repair properly.

What I was thinking of doing was somehow creating a custom action that would only run during repair that would detect the initiated app process, kill it, and restart it.

Is this doable with something in WiseScript.  Something tells me I have seen an end process action before.  My concern is that I won't have permissions on Win 7 to kill it, but if the Standard User initiated the process, hopefully the repair running for that user can kill my app.  ???

I was thinking of a .dll, but I guess I could just create an .exe if there's nothing in WiseScript that would do the trick.

Any further help appreciated.

Are your standard users starting the application from an advertised shortcut as in a 'normal' MSI ?
If that is the case, then key path checks and any required repairs will take place BEFORE the application is started. If you are getting a different sequence of events then something is not quite right.
Perhaps you should consider using Active Setup to kick off the repair rather than waiting until the user starts the application from a shortcut.

When the admin installs it places shortcuts to all users.  When the standard user logs in, they simply click the desktop shortcut to launch the application.

It appears that our application launches as you can see the load of the main form, then the repair begins.

Now, I think, in Wise, the advertise check option is unchecked for the shortcuts we create.  Should that be left as checked? 

Boy, it would be nice if that was the problem and I didn't have to add yet another custom action to fire only during repair.

Thanks for the info so far on this!!!

The MSI format allows for two types of shortcut - the fully advertised shortcuts and the command line shortcuts. Basically, if you check the shortcut properties in Explorer, and you can see the full path to the executable, then it is NOT an advertised shortcut.
Advertised shortcuts do not call the EXE directly, but are actually interfaced with the locally cached MSI, so that when the shortcut is triggered, a full check of all key path components is carried out BEFORE the executable is launched.
If you have non advertised shortcuts, then repair depends on another advertised entry point being triggered, such as:

Extensions and their icons specified in the ProgId Table.
Shell and command Verbs registered underneath the ProgId key.
CLSID contexts and InProcHandler.

So in your case it would seem that your application is being kicked off immediately by a non advertised shortcut, and the loading of a DLL or two is kicking off the repair due to a missing entry point, which is giving you a result you don't need.
I would definitely recommend trying with advertised shortcuts and seeing if that fixes the problem with no further coding.

I currently have the conditions for the actions that shouldn't run during a repair install as....

NOT REMOVE~="ALL" AND NOT Installed .

I can just make that NOT Installed right.  I'm not sure what the Installed property will be on removal.  I would think that when removing the Installed it true, but just want to be sure.

Installed is true until the end of the uninstall.