Portal and Go To Related Record

[Mandu]

Hi,

I have a traditional Invoice layout containing a portal that lists the Lineitems. Until now, line items are added/deleted/modified as portal rows. No problem.

Now I need to implement an edit that cannot reasonably be done by editing a field in a portal row. For this, I want to open a new window, show the LineItem record, allow the edit to be made, and close the window. I placed a button in the portal row layout, which runs a script that creates a new window and does a Go To Related Record (to display the LineItem record in question). The layout here contains about 30 checkboxes that set a multi-value field in the LineItem record.

It works, except on "new" portal rows. If I tab into, or click into, the blank row at the end of the portal, type into Field A (which triggers the portal row's auto-enter serial number to be assigned), and then click the button, I get the window with the 30 checkboxes, but clicking in them does not set the checkbox. I have to close the window, click outside the portal, and click the button again to get the checkboxes which now are clickable.

It sounded like a Commit problem but I tried running a Commit and it didn't fix it. Any ideas what's flakey about the new record in a portal?

Thanks,

Chap

[Fitch]

Run Commit at the beginning of the script, before you GTRR in the new window.

[Mandu]

I tried that, but then I ended up at the wrong "related record". Doesn't committing cause the "current record" to be forgotten?

[Mandu]

I got it working but I'm not confident this is the right way. I'm posting a sample. Open it, and click on the Edit button to get to the Meeting editor. You modify Meeting Flags by clicking in that field, which is a button that drives the "Go To MtgFlags" script. This pops up a small window with selectors for Meeting Flags. You can also use the portal to add meetings as well as modify them.

GTRR.fp7.zip

[comment]

I'm not confident it's the right way either, but it seems very similar to the way proposed here, and I don't recall seeing a better solution for this.

[Fitch]

That's true, you lose the current portal row when you commit. Capturing the current portal row with a script parameter works well, unless the portal has a sort order that might change the current row's position. When that's the case you can work around it by capturing the unique id of the related record and then looping through the portal until you hit the right row.

[mluka]

Hi, Mandu.

I have a very similar problem:

I have a traditional Invoice layout containing a portal that lists the Lineitems. [...snip...] Now I need to implement an edit that cannot reasonably be done by editing a field in a portal row.

[...snip...] For this, I want to open a new window, show the LineItem record, allow the edit to be made, and close the window

I have exactly the same setup, except that I'm trying to do the edit on the same layout, in the same window, using a second portal.

And I'm having the darndest time controlling which is the "selected portal" and the visual appearance (I don't necessarily want any field to be selected or highlighted).

I'm just about ready to give up and go the same route as you: open another window. But I'd rather avoid that.

Do you or anyone else know of a reliable way to control the navigation between portals on the same layout?

Thanks!

[comment]

What should the second portal show? (it doesn't seem at all similar)

[mluka]

Hi, Comment.

We're in the process of creating an order. The layout we're on displays records from Orders. We have all kinds of buttons, in a tab-control, to select items and their attributes.

The first portal displays records from OrderDetails. These records are being created by going (under script control) to the last row of the portal. It is setup to represent the body of the order we're building, pretty well as it will look once it gets printed (on 3-inch wide thermal paper, BTW). On each line, it displays the Quantity, 1st line of Description, Unit price and Extension.

Because of screen real estate limitations, those lines are fairly small and would not be practical for in-place editing. (Keep in mind that we're using touch screens.)

So I thought I would like to have a way to select one of the lines (a transparent button on top of the row) that, when pressed, would take me to a "magnified" view of that record (using a larger font), displaying the Quantity, the whole Description and the Unit price. There I could more easily select Quantity or Unit price (typically the fields that need to be edited) and edit them.

I figured the best way to do this was to create a second portal also displaying records from OrderDetails (from a second Table Occurence).

That's done and appears to be working fairly well, navigation wise. I can go from portal 1 to portal 2 and display the right record.

But problems started appearing when I started adding the logic to edit the fields in portal No. 2.

Now, when I pick a record for editing (a row in portal No. 1), I don't know if the user will want to edit the Quantity or the Unit price or the Description. So i don't want to just pick a field arbitrarily and highlight that!

Yet, the only way I've found so far to go from portal 1 to portal 2 is to use the "Go To Field [TableOccurence::Quantity]" script step, because that lets me specify the table name!

(BTW: yes, but doing this does NOT make portal No. 2 active! Go figure!)

But that "selects" the field.

So then I added a Go To Field [] step (which worked for me in another script and de-selected a selected field, under a frozen window). But that doesn't work here, because that instruction then selects the first field in the row I had selected, IN PORTAL NO. 1!!!

So, I'm thinking: maybe I should freeze window, go to a hidden field, etc...

But to tell you the truth, this is getting way too involved for my taste. That's when I started wondering if there wasn't an easier way to control navigation between portals on the same layout.

Hence my post/reply to Mandu. I was actually thinking of doing all this in a new window. when I found his post!

[in another environment, I would have copied the fields of the record I want to edit to variables, displayed those variables, let the user play all he wants with them, then copied the variables back to the record. FM doesn't allow us to display variables...

There again, I suppose I could create global_work_fields, etc... Maybe I should have a whole table of global_work_fields and use those as variables!]

Please excuse the long post!

[comment]

A portal is a device to show MULTIPLE related records (bar a few exceptions). It seems you want to display data from a SINGLE record, the one that was selected in "portal1". No portal is required for this - and this is the point where I lost you.

If all you want is a "magnified" view of the related record, it should be easy by going to the related record using a layout belonging to OrderItems.

[mluka]

[sigh...]

Hi, Comment.

Of course! ([More sighs...]

Why do it in a complicated way if you can do it in a simple way, eh?

Thanks a lot!