Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 8619 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I've got 2 files in FM 5 that are joined thru a join relationship: File A contains the data records, and File B is a mini calendar that pops up on top of a File A layout through the use of a couple of scripts. The user clicks on the mini calendar which sets a global date field in File A to the date the user selected. I then run a script located in File A (while still in File ??? to copy the date into the appropriate field in the current record.

This seems to work fine, but I would like to move all of the involved scripts in File A into the File B mini-calendar. Since the files are joined, I tried the following which does not work:

In File B:

"SetField(File A::Date1,File A::Global Date)"

The Current record field Date1 never gets changed. I do know that the global definately has the new date value. I've got nearly 250 date scripts and would like to move them out of my main file as much as possible. Thanks for any suggestions.

Note to Moderators: Two colons together cause one of those silly graemlins to be inserted above. Can you guys fix this? That should read Date1!!!!

Steve: If you turn off Smiles in the post, the problem will be fixed. -bd

[ April 23, 2001: Message edited by: LiveOak ]

Posted

If the files are related, you shouldn't have to use copy and pastesor scripts to move data around, just use related fields.

Of course, it depends upon how you have set up the relationship... in a calendar program I fiddle with when I've got nothing else to do* the relationship is based on the day of year and year (doy&year) so the match value for February 1 2002 would be 322002. When the user clicks on the day, a script changes layout to one with the related fields on it -- no changing of databases or anything.

Vaughan

* No comments about "too much time on my hands" please! Edward Weston photographed peppers/capsicums for years, the image "Pepper #38" is quite famous. I dunno about the other 37 though... <g>

Posted

Vaughn, I don't really understand your comments. I've got a calendar that gets popped up by 250 fields, in another file. How could I make that work without scripts and setfields?

Posted

My calendar has two files: one is the "calendar" itself, where each record is a day of the year so there are 366 records (plus 6 extra before 1/1 when New Years day starts on a saturday). The other file is "events" that occur each day. They are related by "day of year & year" (see post above). Entry into the events records are done through related fields and portals. very simple data design: each day can have more than one event, but an event can only have one day.

My solution does have a lot of scripts, but that's to generate the calendar display.

BTW what are the 250 fields for?

Posted

Vaughan, the product is meant for real estate agents. They have different activities and document requirements before a sale can close. Each document or activitity has a status (completed, ordered, pending, etc.) and an associated date field. I already have 250 scripts devoted to poping up a calendar plugin, which works fine. But the plugin developer wants $900 for a developer license which I'd rather not spend if I can avoid it.

What I'm confused about is why I can't transfer values that I know exist from a script running in File B directly, but I can transfer the values by executing a File A script while still in File B. The fields are available from the file list in File B, but the SetField doesn't do anything.

I would appreciate any suggestions. Thanks, Steve.

This topic is 8619 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.