I have a patient db contains 4 fields among other fields: Surgery1 - Surgery4. All of them defined as value list (yes/no). When user add record and if yes is checked, two more fields (Surgery Date, procedure)should pop up to allow user to enter data.

I've been searched the solution for days, but cannot find one I can understand well. Can someone please give me some detail information. Thanks!

Hi new comer,

If I understand you, you want (when you click Surgery1), Surgery 1's SurgeryDate and Procedure fields to pop into view, otherwise they shouldn't show. I assume you want this with each of your four Surgery checkboxes or radio buttons. If so, this should work for you:

You can place your Surgery1

You can adapt this to your needs (I don't remember the origin). I've seen some more elsewhere.

Hi new comer,

The demo file mse attached is the same process I listed out for you. It will show you how it works (and you'll be able to tell if this is what you want) but I've found step-by-step directions are much easier for most people than trying to figure out how a demo works.

LaRetta

Thanks! LaRetta and mse. The pop up fields works with your helps.

mse: I like the simple file a lot. I will definitely keep it.

LaRetta: a related file is a good idea. But how should I design the uncertain space (b/c of the uncertain fields) in layout? Anyway, I will have a try.

Thanks again!!!

Hi new comer,

The portals can't overlap but they can be as small as the fields themselves. So you might try:

[radio]__Surgery 1__[surgeryDate]__[Procedure.........................]

[radio]__Surgery 2__[surgeryDate]__[Procedure.........................] etc.

You can even move them apart and have the Procedure two lines and even have a vertical scroll bar on it. But your Portal should be formatted to only 1 row (you can increase the row height by dragging it).

Just make sure that your fields are within the portal. If they don't display, it means that part of a field is touching (or outside) the portal somewhere.

The demo file that mse so nicely attached (MoreVis) is the second demo of John Osborne's, I believe. His first was called Visibility (I think). It's a useful technique, but tends to require quite a bit just to have a field disappear.

I use this visibility trick sparingly because it requires two calcs and a relationship for each portal. I hate using calcs unless necessary but it's sure nice when I do need it.

Many times, I'll just duplicate a layout WITH the fields and when User clicks radio, a script switches them to the other layout. They don't know they've been switched! It still looks like the fields suddenly appear. So many options with FM!!

Glad it worked for you!

LaRetta

Thanks for all the detail explanations!

LaRetta,

I tried to use related file (Surgery.fp5) as you mentioned before. the problem is when I clicked radio "No", the related fields still show up, although they are not editable.

Here is what I did

create a field SurgeryFlag(cal text) in patient.fp5.

SurgeryFlag=case(surger="Yes", patientID&"Yes", " ")

in Surgery.fp5 (fields: Flag, ID, date, procedure)

Flag (cal text)=ID&"Yes"

then I create a relationship SurgeryFlag::Flag

then put a portal in layout using this relationship

Did I miss something? Does visibility trick still work with related file?

PS. How can you trigger a script by click a radio?

Thanks in advance!

Hi new comer,

Changing your base structure basically changes ... well ... your structure.

I'll create a demo and instructions for you. I'm on a deadline and won't have it ready for you until tonight. Hang in there! There will be a few changes, but we can handle it.

And, truthfully, I'm glad you re-considered your base structure. Since you will have multiple surgeries for each Patient and sometimes more than four, your new structure will allow for it quite nicely.

I'll be in touch when I finish up with this. Please don't make any changes until I get back to you, or my work in creating a demo (and writing out the process for you) will be fruitless. If you receive other suggestions, that's great ... but don't proceed with changes just yet, okay?

And good for you in deciding to structure it right! I'll be in touch.

Cheers,

LaRetta

I dropped the ball! So sorry, New Comer.

When you changed your structure from one db with four surgery fields to a related surgery db, it complicated things. I planned to create a demo showing a few alternatives other than placing multiple visibility portals (as they each require two calcs and a relationship). And, since you may be adding multiple Surgery records (even 10 possibly or more?), I was hesitant to just explain how to correct so you could use visibility technique without considering all the factors involved.

I decided to put together a demo showing various ways you could handle this and then let you decide. Unfortunately, I'm backed up with current projects and just can't fit it in until at least Monday or Tuesday, so sorry.

I think you should just maintain your primary relationship, place your surgery portal with Surgery#, SurgeryDate and Procedure in the portal and let Users add or modify records from there. Or use Layout Switching - but, then again, you'd need a different layout for each surgery and you'd be having to add new layouts, etc.

You can't make a related portal field disappear (everyone please correct me if I'm wrong). When you click into a field in Main, the portal fields will outline-highlight unless you change their field format to not allow entry and change their properties to transparent, etc. This is because all fields for the existing Patient and all 'related' fields for that patient will 'light up.'

I could have explained that you could make them not allow entry into field, then use script, etc. but I just ran out of steam. I suggest you reconsider what you want to accomplish and why. Maybe repost your question now that you have your base structure in place, and then decide how you want to proceed.

Sorry I let you down on this. But I think that 10 calcs and 5 relationships is a bit much just to make 5 surgery records disappear individually. And since there are many techniques and explanations necessary to implement them, I guess I'll just need to put the ball back in your court.

You made the right decision on your structure and I'm glad you changed before much work was put into it.

LaRetta

LaRetta, I truly appreciate your helps. PLEASE concentrate on your project.

I will reconsider this whole thing, and hopefully can figure it out (actually I got some ideas now).

but please post the sample file whenever you get time