Auto Entry-Last Visited Field

[bmohnsen]

I have a program that asks for the date when something occurs. Typically the date is the same for all records. I want the user to be able to enter the date for the first record and have it copied to all the other records. However, it needs to be editable since sometimes the date will be different- therefore a global field will not work.

I have tried defining the field - as auto entry-last visited field - but it doesn't work - or works only some times??? Any suggestions

[K1200]

I've experienced a similar problem when specifying Auto-Enter of a calculated value ($$CurrentText, a global variable). I, too, would like to understand what other factors are involved with Auto-Enter Upon Create Record. (I've walked through scripts using the Debug option and seen it fail.)

[Lee Smith]

Would the Get (CurrentDate) work in an Auto Enter Calculation and the "Do Not Replace Existing Values (if any) turn off, work?

Lee

[bmohnsen]

I don't think so - any other ideas?

[LaRetta]

Hi bmohnsen,

LastVisited only works sometimes because when a User first begins, they didn't HAVE a last visited record. And LastVisited in THIS window or THAT one? And which found set? What if records were omitted or deleted? What would be the LastVisited then? LastVisited works well but is very limited and should only be used for strict data-entry without a lot of layout jumping and so forth. But it DOES work but it can also 'default enter' an incorrect date - which is dangerous because your User will start depending that the date will be right (same as last) and they won't look at it until they have created 20 records! But there is more too it than that ... you also want the ability for the User to enter the date value which would then be replicated upon each subsequent new record, right?

You need to provide a global field to accept User data. That global (DATE) field will not interfer with other User choices and will remain in effect for the duration of the session. You can pre-fill the global in a startup script as starting default by Set Field [ gDate ; Get ( CurrentDate ). Let User click button CHANGE DATE' to jump to different date. Provide them with Custom Dialog to enter new date (and set global that way) or even a small window. Even better ... place gDate (with allow entry off) on the layout and make it 1 px high and about 85 px wide. It will disappear entirely. A User clicks the button, the global pops onto the layout (out of nowhere), User enters new global date and the field closes (and disappears). No Custom Dialog or window necessary. Script attached to button would be simple: Go To Field [ gDate ]. You will need to write a script and can't use Specify Button here (although I think they may have fixed this in 8.0v3).

So you will have gDate (global date) for User. Your trueDate field will have Auto-Enter calculation but do NOT uncheck 'Do Not Replace...'. The calc box would be: yourtable::gDate. In this way, new records will keep entering the global date but it can then be changed by User. The gDate can even be tucked under the button (I stole that idea from Comment) but why use Custom Dialog for quick User-entry when you can have the field there but never have it seen until needed? Oh God, I LIKE that idea for the invisible global for user input! ;-]

LaRetta :wink2:

Edited July 30, 2006 by Guest
Added idea ...

[bmohnsen]

thanks; however, it is not on new record creation - there are actually 20 date fields for 20 different dates. and say there are 100 records.

When the user selects the date for field date 1 for record 1 - I want date 1 to change to that date for all records. However, it may happen that that date 1 for a couple of records needs to be different.

[LaRetta]

Okay, the User needs to isolate the found set of records they need to change. Let them set the global and script would be:

Go To Record/Request/Page [ First ]

Loop

Set Field [ dateField ; gDate ]

Go To Record/Request/Page [ Exit After Last ; Next ]

End Loop

Or eliminte the global and let the User change the value in the first record. Button could then have script parameter of: dateField. This means it would use the current record to change the rest. Script would then simply substitute the Set Field step to: Set Field [ dateField ; Get ( ScriptParameter ) ].

Note: You can also use Replace Field Contents[] which I believe is quicker but it provides no protection in multi-user. I believe it still fails to produce error if record is locked. With script, you should add error trap.

Edited July 30, 2006 by Guest
Added Note

[LaRetta]

"there are actually 20 date fields for 20 different dates. and say there are 100 records."

Wait a minute ... do you have these 20 date fields within one record? If so, they should split into their own table. Next thing you will want is ability to search all 20 date fields. I see a train-wreck ahead ...