Portal Elevator Control.... NOT

[ron G]

This is genuinely weird.

 

I have a Members table that is the basis for Members form.  On the form is a separate TO of Members that lists, vertically, Member Names.  When a member's name is selected a GTRR runs which puts the member information in the main window.  This works.

 

The member portal (Navigation) shows just the Member names.  The portal shows a max of 28 names.  The problem is if I select member #47, the member is selected and then the elevator jumps to the top. 

 

 

I have tried to program for this:

 

 

And this code works .... As Long As I Am in Debug.  Huh?  When I run the code in development mode it frequently fails with a jump to the top.

 

Here is the portl setup:

 

 

Should this 'really' be this difficult?  Is there a work around?

 

Thanks for reading....

 

Ron

[ron G]

Hard to believe these is not a custom function or existing code that remedies this situation.  But, here is the 'current' version of my script. 

 

I am trying to get the script down to 'bare bones' functinality before I layer in more complexity.  But, even this does not work. 

 

[ron G]

In a continuing effort to 'get' what this situation has to teach, I have created an isolated portal script. 

When run, it produces this weird outcome? huh

[bruceR]

So where is your example file that contains these scripts so that people can actually help you?

[ron G]

Here it is simplified:

Script attached to a button that will move the selected portal row down by 10.

 

In the example below, I was on record 1 of 52 when I ran the script.  I am trying to move the activeportal row to 11.

 

The script:

 

When I uncheck the 'perform without dialog' box on the Go to Portal Row command I get this:

 

 

Why is FM trying to go to record 10 out of 4?

 

Plus the fact that when i step through this very simple script I get an error 101  --- Record is Missing.

 

 

[bruceR]

So where is your example file that contains these scripts so that people can actually help you?

[Josh Ormond]

Yes, please attach the actual file.  Somethings it's easier if we can see it...since there are so many other things that can affect it.

 

( make sure you zip the file first )
 

Here it is simplified:

Script attached to a button that will move the selected portal row down by 10.

 

In the example below, I was on record 1 of 52 when I ran the script.  I am trying to move the activeportal row to 11.

 

The script:

GotoRow1.jpg

 

When I uncheck the 'perform without dialog' box on the Go to Portal Row command I get this:

 

GotoPortalErr.jpg

 

Why is FM trying to go to record 10 out of 4?

 

Plus the fact that when i step through this very simple script I get an error 101  --- Record is Missing.

[ron G]

Ok.  Here is the quick an dirty sample file.  Note: even though 'reset scroll bar is ....' the scroll bar jumps to the top after the last record is selected?  Is that a 'feature'?

 

 

PortalNavNot.fmp12.zip

[Wim Decorte]

It looks like you are misunderstanding the "reset scroll bar" feature.  That is supposed to keep the current portal row active once you click outside the portal.  Anything else like navigating to another record, or going to the portal object itself will change the focus of the portal row record.

 

If you want to visually keep the active portal row AFTER you do anything that changes the focus then you will need to navigate to the portal row in your script.

 

Your "next 5" script will never do anything but go to the 5th one because the "goto object" gets rid of whatever portal row was active.  Since you capture the active portal row after that, it will always return 0.

[ron G]

Wim,

Thanks for the comments. 

 

You say "Your "next 5" script will never do anything but go to the 5th one because the "goto object" gets rid of whatever portal row was active.  Since you capture the active portal row after that, it will always return 0."

 

I thought using Set Variable $Position; get(ActivePortalRow) was supposed to capture the current, focused, portal row?

 

What code would you suggest to effectively allow the 'next 5' script to work?

[Wim Decorte]

You say "Your "next 5" script will never do anything but go to the 5th one because the "goto object" gets rid of whatever portal row was active.  Since you capture the active portal row after that, it will always return 0."

 

I thought using Set Variable $Position; get(ActivePortalRow) was supposed to capture the current, focused, portal row?

 

 

The first thing you do in your script is go away from any portal row by going to the portal in general so the first thing your script does is REMOVE focus on whatever portal row the user is.  Skip the "go to object" at the start of your script and that will leave the focus in place and "get(activeportalrow)" will be able to do its thing

[ron G]

Wim,

I 'get' the loss of focus and it's consequences.  So, I set a Global Variable $$Position when ever a user clicks on a new member.  Then IF they click the Next 2 button, the Next2 script creates $$Position=$$Position+2 so the new $$position is incremented.  This works.

 

Here is the outcome.    It works... kind of..

 

Using this script:

 

 

The problem is, once I get the row moved, it is highlighted but I can not get it to be conditionally formatted ('yellow highlighted') as a selected 'new row'.  I have tried: commit record, go to object etc... without success...

 

Your thoughts?

 

With appreciation

 

Ron

[ron G]

Got it to work.  All I needed to do was to use GTRR after moving to the 'new' portal row.

 

However, I notice that when the 'new' row is outside the visible portal window, I can go to new portal row, run gtrr which 'highlights the portal row'.... great .... but then the &*@*(&$^&@ elevator jumps back to the top making the 'new' portal row not visible (although it is still selected). 

[Wim Decorte]

Ultimately you are going to realize that portals are meant to display related child data from the parent record that you happen to be on, and not a "menu" or "navigation" device.

You can spend a lot of time trying to make it behave as such but that's not what is it there for... it is always going to be a struggle if you want to co-opt them as such.

 

Also realize that you may be forcing FM to load extra data for each record that you want to display just to make your "menu" work; it may not be very efficient to do it this way.

[Lee Smith]

[ron G]

I realize I may be pushing the design limits of FM.  But, it does seem strange that the functions, like get(ActivePortalRow) are available but when used they act unpredictably and with inconsistent results. 

[Wim Decorte]

I realize I may be pushing the design limits of FM.  But, it does seem strange that the functions, like get(ActivePortalRow) are available but when used they act unpredictably and with inconsistent results. 

 

They are very predictable and consistent, that's exactly what I meant.  They SEEM unpredictable to you because you approach them from an angle that is at odds with their intended use.

 

You are not close to pushing the design limits of FM, trust me

[ron G]

You say "They SEEM unpredictable to you because you approach them from an angle that is at odds with their intended use." 

This begs the question "Where can I get a 'listing' of the 'intended uses'?"  But, you also say "

You are not close to pushing the design limits of FM, trust me." 

 

So, my problem is that I am using FM functions outside the scope of their 'intended use' but I am *not* pushing the design limits... huh?

 

IMHO, it seems that my 'troubles' stem from the fact that FM's portal scroll bar 'insists' on resetting even after the "RESET SCROLL BAR..." is unchecked.   I think it would eliminate a lot of complex 'work around' coding using 'go to portal row' and 'get(activeportalrow) if FM would just change their function to allow the elevator to stay where it is when a user stays within the portal as well as when they change the focus outside the portal.      (This is probably a *lot* simpler said than done...)

 

But, judging by the number of other users who encounter this problem and the apparent lack of even Moderator's ability to address it, I think the problem is summarized with "... you can't get there from here." 

 

It was a good learning experience.  I appreciate your posts and efforts.  Thank you.

[bruceR]

That is correct. If you don't understand how something works that doesn't mean you're pushing design limits.

[Ocean West]

Hey Ron check this out http://www.modularfilemaker.org/2013/03/master-detail/

[ron G]

Hey Ocean,

Wow!   The MasterDetail does exactly what I am trying to do. 

 

This is going to be a fantastic learning opportunity. 

 

Good to know that someone has solved this problem.

 

Thank you *very much* for pointing me in the right direction.