OnObjectEnter not firing on popups

[djc728]

I have a simple field script for OnObjectEnter - which stores the initial value in a global variable. Then I have an OnObjectExit script that compares the initial value with the current value and if it changed I write the change to log table.

The script catches the initial value for regular edit fields but it won't fire the trigger on fields that use popups for data entry.

How can I capture the original value for the popup if I can't get the OnObjectEnter script to fire or am I just missing something?

Dom

[brian rich]

Hi djc728

Not sure about the problem you are describing, but If you need to keep track of changes to fields in your tables, Ray Cologon has a useful system based on a custom function and some supporting fields. See here:

http://www.nightwing...sX/demoX01.html

The changes are stored in a text field which remains with the record. It works without script triggers and updates whether field is changed by the user or by a script.

Once you set it up the first time, You can drop this logging system into any table in about 10 minutes.

HTH

Brian

[Lee Smith]

How can I capture the original value for the popup if I can't get the OnObjectEnter script to fire or am I just missing something?

If you just want to see the changes made, and by who, then I second the recommendation by brian. However, your description sounded a little different than that to me.

I haven't tried capturing field data like this, but have you tried using a copy of the field (non popup) in a different layout?

[LaRetta]

How can I capture the original value for the popup if I can't get the OnObjectEnter script to fire or am I just missing something?

Hi Dom,

Pop-up menu, checkbox and radio button do not fire trigger upon enter. Instead, capture the value in the script parameter using Get(ActiveFieldContents) and trigger OnObject Modify (or OnObjectExit).

If you do not wish for the change, set the field back to the prior value. Script might look something like pseudo-script:

If [ your test fails ]

Set Field [ (no field name selected because it will be the field you are in ; Get ( ScriptParameter ) ]

End If

[djc728]

LaRetta, Brian, Lee:

Thank you for your responses. LaRetta, I'm using your suggestion. Already tested it and it works fine. Thanks again.

Brian, the Ultra Log by Ray Cologon looks very good and I'm going to dissect it and use it in my applications moving forward. Always been a big fan of Ray's and you're right - that solution can be dropped into any application in 10 minutes. 15 minutes for us older developers like myself ( lol ).

Dom

[brian rich]

Hi Dom

Some suggestions for implementing Ultralog rapidly.

I always have a single record PREFs table in my databases, which I use to store persistent information and also store most of my global fields. The primary key of the PREFs table is linked with a Cartesian join to the primary key of each table you want to log. When setting up Ultralog, if you add a text field to this PREFS table for each table you are logging, you can drop a list of the field names into this text field, then reference this list when setting up the Log field in each table. Much easier to see and manage, as it is all on one place in the database.

There are several custom functions you can use to generate lists of fields from a layout, so you can quickly populate those tables.

Be careful not to log calculation or summary fields; although this does work, it slows the whole database down significantly since the logging activity forces calculation to log the result.

Being Windows based, I've also added a tweak so I can retrieve the Windows profile name from the workstation which helps tie down who did what.

I have only once implemented the part of Ray's system which strips and resets the log fields on a regular basis when the datbase manager wanted the ability to view change history on a field by field basis to see who did what when. We run a nightly script on the server to tidy up the log files, and this works reliably.

(Thanks Ray)

HTH

Brian

[djc728]

Brian:

What I'm not seeing in Ray's Solution is how is he setting the linking DATAID field in the Archive Log table. I see the script that sets this field but what I don't see is how it gets executed. What is the trigger that runs that script.

Dom

[brian rich]

Hi Dom

We run a script called Process Daily changes, which triggers two separate sub-scripts to reset the log files in two tables. These scripts step through each record in turn and resets the log field after extracting any new data - the dataid value corresponds to the unique key of the record being processed in the table and is set when the log record is created.

This script runs nightly at 2:00am using a scheduled script on the server. It runs after we take a 'snapshot' of the existing data, which allows the user to go back to any particular date and actually view state of data at the end of any particular day. In this 'analysis' mode, the user can click on any field and see the history of all changes - and who made them - back to the date he has selected.

HTH

Brian