automatic navigation between two portals???

[poly_paparas]

Hi guys

I need your expert advice again...

I am trying to build a patient database for my practice.

The database consists of a main patients' table with the basic data a related episodes table with all the episodes of care for each patient (consultations, operations and followups) and 4 studies tables for blood tests, imaging studies etc

Is it possible, if there are more than one portals on a layout, to select a specific portal and go to a specific row using a calculation or a script?

I have 5 portals on a layout, all of which are displaying tha various srudies for the specific patient.

Each portal is taking its data from a different table, all of which are related to the master patient's table via pt_id.

One of these tables is for imaging studies (xrays etc)and contains fields for date, description, result and a container with the relevant image.

I am trying to make a portal with all the data except the image (because either the portal will get to big or the images will be too small...) and have another portal next to this, referring to the same table, only displaying the image from the container field only. This portal can have the same size as the other one, but with only one row visible, giving adequate size to display the image.

At the moment I can browse through the rows in the first or the second portal but I would like to be able to have one portal to automatically go to the related record when I select a row on the other portal...

(Complicated!!!)

So if I select a row for one of the imaging studies I would like the relevant image to be the visible row on the other portal, and If I browse to one of the pictures on the right, I would like the other portal on the left to automatically display the row containing the related record.

Is that possible or am I asking to much???

Many thanks in advance for any advice offered

George

[Fenton]

Several questions here, from the simple to the complex. I'll start with simple.

To go to a particular portal when there are several (good idea even if there's one):

Go To Field ["portal relationship::field in the portal"]

You can then Go to Portal Row if needed.

As far as the "showing selected rows (records)," there are ways, but it gets more complicated. The basic rule is that a portal shows whatever records match its relationship. So, if you want to control what it shows, you have to control its left-hand key. You don't want to change real data for this, so you use a global field for the key, setting it to the appropriate key value when you click on a portal row's record, with a script. That's if you want to show the data in a portal (or related field) ON the same layout.

Because in 7 there is an additional option of popping up another small window to show the related data, which you can control the size and placement of. Then you do not need to change a global key; you can actually go to the related record, on a layout belonging to its table. The "going to" is simpler, but "window control" is needed. Sort of like the little pop up windows you get on the web. Can be done well, or can leave extra windows scattered all over the screen. I would think this might work well for the image, not really for others.

The main problem with the global keys and portals method is what to do when a new choice is made. A choice in the portals one "up" the relationship chain will change the value of its global key, hence change the portal immediately "down" from it. But changing a value two portals up will change the portal one down, but not the others further down. You end up with data down the line that is not correct. It is impossible to know what they should be, because there are multiple (to myriad) possibilities.

So, you have to wipe out the global keys of portals more than one relationship down from the clicked portal. If they click the "top" portal, then all portals below should be made to go blank. I like to put a field from the current choice in another global, at the top of each portal, "the current choice." It's a field, not usually the key, because the key should be an ID field, not word(s).

[poly_paparas]

Thanks Fenton,

I understand what you say, but what if you have two portals displaying data from the same table (different fields).

Go To Field ["portal relationship::field in the portal"] will probably just go to the first one of the two and try to display the field, which is not visible. I have a table with 5 fields

Pt_ID, date, dscription, result and image (container).

The first one is related to the main patient table

The next three are on the first portal

and the last one the image container is on the second portal

If I tell filemaker to Go To Field [portal relationship::imege container] it goes to the relevant record on the first portal. Or at least that was the impression I got last night when I was trying to do this.

How can I tell it to go to the second portal from the same table?

George

[RalphL]

I assume that if you have 2 portals each has its own relationship. When you do a go to field you specify the relationship. That can only take you to portal for that relationship.

If my assumption is wrong why do you have 2 portals?

[poly_paparas]

Sorry guys I did not realise that you were right and the actual thing was working with your advice!!!

I am attaching a file to see what I am trying to do and any new ideas are welcome

George

portals.zip

[RalphL]

You have 3 portals, 2 using the same relationship but displaying different data. Your scripts are working. Those 2 portals could be conbined into 1. The text data could be placed uner the picture.

[poly_paparas]

Thanks for the advice Ralph, but I am not sure I follow you...

The reason I am using 2 portals for the same table is to have the image show in larger size. If I combined the 2 as you suggest the portal row would have to have the size of the picture, and only one record would be visible...

Unless there is some other trick I don'y underdtand

George

[RalphL]

You would have to make the portal larger to show more than one row, but everything would be together. You might want to consider a backgroud color to show the protal row that matches the image. This could be a conainter field that holds a color for the selected portal row and is empty for the others.

[Ender]

Instead of using a second portal for the image, you could use a second relationship that's related by just the ID of the portal record that was selected, then drop the related image field on the layout. This would be much better anyways, because in your current system, if a user click out of the image portal, the image goes back to the first portal row.

So add a global gImageID in Patients. Then add a new table occurance of Imaging_Tests and relate them by Patients::gImageID = Imaging_Tests::img_ID. Then put the related image field (from this new relationship) on the Patients layout. Finally have your Goto Related Record script set the global from the record that was selected.

In implementing globals in your interface, it becomes important to control navigation between records with scripting, so you can clear or set the globals when the records change (You wouldn't want the wrong patient's image to show in the field.) Hmm, a little insurance here...If you edit the new relationship to also include Patients::ptID = Imaging_Test::pt_ID as an AND criteria, I think this would avoid the possibility of showing the wrong patient's image.

[poly_paparas]

Thanks Guys, I'll try this tonight and let you know what happened.

George

[poly_paparas]

I tried it and it works well.

Thanks for all the advice.

I am not sure how to implement this colouring thing that you suggested RalphL.

Would you mind explaining it to me in a bit more detail?

Many thanks again

George