List from which checkboxes were checked?

[ddreese]

My file "allegations" has many fields such as victim name, perpetrator name, incident date, etc. Also I have many fields that are checkboxes of what specific allegations the perpetrator has filed against him. For instance, there are fields such as... Fractures, Bruises, Poisoning, Sexual Assualt, Indecent Exposure, Prostitution, Failure to thrive, etc. etc.

What I need to do, on another layout is have each checkbox that was checked showing up seperately in a list. In this list, I have to be able to set the "status" of each allegation. For instance, if there was a "Burns/Scalding" allegation checked, it should show up in this list, and on this layout, I should be able to set the status of the allegation like "unfounded" or whatever as well as take some short notes on this. All this is needed for each allegation that was checked on the other layout.

I'm a little overwhelmed deciding how I'm going to get this done, please help! Thanks for reading.

[jasonwood]

Sounds like you want a separate "allegations" database, which can be viewed in a portal in your "perpetrators" database. The relationship between the two databases should be a unique identifier (eg. "perpetratorNumber")

"Perpetrators" should contain information about the perpetrator. The "Allegations" database contains a separate record for every allegation, and all the information you wish to record for each allegation.

[Lee Smith]

Hi ddreese,

I'm not sure if this is what you want, but you might want to take a look at a file called "One Line Value List Display" by Don Wieland at:

http://www.dwdataconcepts.com

HTH

Lee

[ddreese]

Sounds like you want a separate "allegations" database, which can be viewed in a portal in your "perpetrators" database. The relationship between the two databases should be a unique identifier (eg. "perpetratorNumber")

"Perpetrators" should contain information about the perpetrator. The "Allegations" database contains a separate record for every allegation, and all the information you wish to record for each allegation.

Actually I do have a seperate "allegation" and "perp" database. The perp and victim name fields in the allegation database are calculated fields from the client and perp master files. I also have a unique perp id linking the files.

The problem is, in each allegation there can be many "accusations", what the perp actually is accused of. These are checked off. I need it to generate a list of which "accusations" were checked, and for EACH "accusation" I need to fill out a "status" and "justification". Viewing the allegation through a portal will only show the "allegation" CASE, not each "accusation" per that case. I'm sorry if this is confusing, it is for me too, hehe...

Hi Lee, thanks for the post. That is sort of what I'm talking about, but I need to be able to select an individual item from one of those lists then bring up infomation based from the selection. It's a good start though, thanks very much! )

[Ugo DI LUCA]

What you need is a conditional value list that would allow you to filter the portal Jason is talking about.

Then, just create a g_Accusation field (global text) in the Perpdb.

Set a relationship from Perpdb to Allegation called "rfilterAllegations" using the following relationship

Allegation:g_Accusation ::Allegation::Accusation

Then go in the menu and create a new Value list called "lfilter Allegation".

Choose "Use values from" and select "Only values from"

This will drives you to the relationship setting menu.

Choose Filter Allegation relationship.

Choose the field Accusation (or what is its rela def in your file).

Still in the perp file.

Create a Portal using this relationship, and put the fields you want in it (except accusation).

Put your new field g_Accusation on the layout, just next the portal.

Go in the format setting for that field.

Check use value list, and choose the Value List lfilter Allegation

Et voila. You've got a conditional value list. The records will show up in the portal according to the value selected

[ddreese]

I'm sorry I'm such a noob, but I don't understand the relationship you told me to use:

"Allegation:g_Accusation :Allegation::Accusation"

I created a global text in perp master (first time I've tried using a global). Still in the perp master, I create a new relationship with my allegation file. I get lost trying to interpret the relationship. From the best I can assume, I'm linking g_Accusation with what from the allegation file? The "accusation" field is supposed to be the field the value list uses? Is that right? Sorry, I'm just really new to file maker, I don't many of the things you guys talk about. Thanks for your help!

[CobaltSky]

Hi ddreese,

What you are trying to do is certainly possible, but will not lend itself readily to a comfortable solution with the existing two-file structure you have in place. I suspect that to handle this cleanly, you are actually going to require a third file.

You currently have Perpetrators in one file and Allegations in a second, which relates to the first on PerpetratorID. I'd suggest that you consider establishing a third file for 'Accusations', which relates to the Allegations file. The key that links the third file with the Allegations file should probably be a composite key made up of PerpetratorID, AllegationID and Accusation (separated by spaces).

To facilitate this, you will be able to establish a key field (eg called AccusationMultikey) in your allegations file which is generated automatically by calculation from the entries made on your value list field, using a formula such as:

PerpetratorID & " " & AllegationID & " " & Substitute(YourValueListField, "

[ddreese]

Cobalt, I can't thank you enough for taking the time to write all that out, I very much appreciate it. I too thought it would probably be best to have a third file for just the accusations, but being such a n00b to filemaker is difficult for me to impliment these things. But I guess that's why I'm here, right? Thank you again, I'm going to try and impliment your solution as best I can, I'll let you know how I do

[ddreese]

Well, I ran into my first snafu. Everything was going pretty well, and works for the most part. Somewhere in the script it's messing up, and sometimes it even gets caught in an infinate loop. The error message is "This field cannot be modified until "gAccusationKey" is given a valid value."

I wish I understood this stuff more so I could debug better, but a lot of the script I have to guess what it does.

[ddreese]

I've played around with it a little more, and it seems to be having problems with the loop iteration. If more than one allegation is selected, the record gets created fine, and the first record is correct. On the next record (second choice or more) it doesn't copy the perp id or allegation id over, just the actual allegation text itself.

[CobaltSky]

Hi,

Well, after seeing your earlier post in which you indicated that you were having problems. I took a few moments to put together a pair of test files along the lines indicated above to see if I could see what the problem might be.

However, my test files worked fine on over fifty test records I fed in, and with all the variations I've tried so far.

I wonder whether there may be a field type problem, or some minor error in the syntax of the version you have created? It's hard to tell what it might be from the description you've given, however.

On balance, I think the best thing is if I sent you the test files I knocked up and you can play with it and compare it to your version to see if you can spot the difference and get yours back onto the rails.

I'm therefore attaching a zipped copy of the example files to this posting (see above).

Allegations.zip

[Ugo DI LUCA]

Hi dreese,

Sorry I didn't answered, I just forgot about this post. There was an error in my post as you suspected. Yous should have had :

Perp:g_accusations::Allegation:Accusation. That is the way filtering portal works.

But as suggested, you should have a third file. The cleaner the better.

Now, for this loop problem, one way you could figure out what is messing up in a script is putting a Pause into it at each step.

A way to stop a script is to have at first step "Allow User Abort" set to yes.

Finally, I must tell you that being for a while now in that Forum and working on File Maker 5.0 for about 2 years now, I'm still impressed by Cobalt Sky answer and its curious calcs.

But as it always works, what could we say ?!?

[Lee Smith]

Oh, oh.

I just recreated ddreese error he sited using Ray's files.

Crashed FM5. Ray, is this because of a feature used that is not supported by 5 or do you need to hear the steps.

I believe that I went to about the 3rd record and click into the portal to see if I could add records, nothing happened, so I then went to the checkbox and check one, hit update and got the same message as ddreese.

Lee

p.s., excuse me for awhile while I now restart the machine to get FM back

[Ugo DI LUCA]

Damned. WHAT A GOOD CRASH TEST!!!

It did it with FM 5.5. Was going OK for a while, then I unchecked all boxes in a record, then re-checked one, click the update button and...Here I am...Crashed !

[CobaltSky]

Hi Lee,

OK, I was able to replicate the problem you encountered. It has nothing to do with version 5. Rather it has to do with the fact that you were in the portal immediately before running the script. FileMaker needs to exit the portal in order to update its indexes and count of related records.

However it doesn't crash anything on any of the systems here - just gets stuck in the loop until you press espape (or Command-period on MacOS) a few times.

The solution is simply to include an Exit Record/Request step at the start of the script to correct for the possibility that the user has been in the portal before the script runs.

Attached is a revised copy with the additional step in the script. I haven't found a way to break it here, but give it a spin and see if it behaves itself for you.

Allegations2.zip

[Ugo DI LUCA]

Hey Ray, I was just kidding about that Crash Test.

I re-downloaded the file, and put a Pause into each steps, then brought the g_accusation on to the layout to see the process of the script.

There were 5 pause script added, but it took me 12 click on "continue" to have updated record A0019, were I had kept only Bruise, Poisoning and Indecent Exposure checked.

I didn't go in the portal. It went Ok apart for these 12 steps...

Then without allow user abort, but still with pause script, I unchecked all boxes from that Record, then reset some of them, went in the portal, exited the field by clicking in the layout, and click update.

This time, I couldn't abort the script and it crashed again.

If that may help

[Lee Smith]

Hi Ray,

I thought I had hit cmd . , I ususally do oh well.

BTW, the forced quit corrupted the files.

I'll work the new file over and see what I can do

In the mean time, I have a question. Why did you have to exit record request here?

Is it because FileMaker was under some impression that I was telling it to do something by my movements?

TIA

Lee

[CobaltSky]

Hi Lee,

The issue you encountered has to do with the fact that you had been in the portal, and had not yet explicitly left the record when the script ran.

In this circumstance, the portal remained in a 'locked' state while the script ran (akin to record locking) and the Count(Accusations::Status) function, on which the Exit Loop If [ ] command depends, was not able to update to include the additional accusations records. Thus, after the records were created, the loop continued - and hence the error message.

Ie because there were no more values to populate the global field, it was set to null, yet the script dto attempt to create records based on it, the Exit loop If [ ] command having failed...

Inclusion of the Exit Record/Request command at the start of the script corrects for this condition by ensuring that the portal cannot be locked when the script runs - and thus that the Exit Loop If [ ] is valid for all cases.

[Lee Smith]

Thank you for the explanation I think I understand now. Maybe with one more follow up question I will.

I don't use a lot of scripts in my solutions, so this might be common knowledge to others, so please bare with me. Would it be a good idea to have an exit record request step in your script whenever you have portal present on the layout? Or was this unique to this situation?

TIA

Lee

[CobaltSky]

In 99.9% of cases, an exit is not a necessity when working with a portal, Lee. In fact, in a majority of cases, an Exit Record/Request would lose the association with a selected portal row, thus causing a portal-related script to fail.

I won't say that this occurrence was freakish, but the combination of factors was a little unusual. Bear in mind for instance, that although all of the functions and steps in the script were being applied (directly or indirectly) to the portal, but only one failed. In most cases, none would fail.

Even in this case, the step would not be required in most forms of normal operation, - and not at all if the portal and the update button/script were to be located on different layouts or (as may well be the case in ddreese's solution) in different files).

[ddreese]

Hey guys, I've been a little busy so I haven't been able to check on the thread. I really really appreciate everyone's involvement in this thread, there is no way I could have done it alone. Are there any books or anything that I can read up on all this stuff? I downloaded some PDFs from the site, but haven't gone too far through them. By the way, it's working well now, I just need to finish setting up relationships. Thank you all again!