Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Featured Replies

Another effort to eliminate TO's and fields. Note that each parent retains its own selection.

ViewSelectedChild11.zip

I think it is very clever how you used the repetition ... yes I know, variables don't have repetitions ;-) to store the parentID. In this way, you can maintain each parent record's selected child as you scroll through the records instead of losing the value when you next select a different parent's child - you aren't overwriting the same global.

This is going to save everyone a lot of work (not to mention easing the stress on the graph)! BTW, is there a limit to the number of global variables one can use and is there a resource hit when using them? I envision storing 125,000 parent IDs using global reps as individual global variables (although I can't imagine why as of yet; one never knows). :smile2:

Edited by Guest
Added sentence

  • Author

Yes, I think this is the first time I found a good use for repeating variables.

I haven't tried declaring that many variables, but my uneducated guess would be that the only resource affected would be your RAM.

  • 3 months later...

FWIW, I asked on TechTalk yesterday and one person that in their experience replied a few hundred variables didn't affect performance, but a few thousand did.

I've implemented this now and it's working beautifully.

One further question: would there be any way to move down the rows in the Child portal using an arrow or tab key, rather than clicking from one to the next with the mouse?

Thanks!

OnLayoutKeystroke script triggers or custom menus are the way to implement this. Custom menus requires a keyboard shortcut (ctrl-arrow), while OnLayoutKeystroke can be any key.

  • Author

FWIW, I asked on TechTalk yesterday and one person that in their experience replied a few hundred variables didn't affect performance, but a few thousand did.

In what way does this "affect performance"?

5000var.zip

Thanks DJ -- I tried an OnObjectKeystroke script on the portal, and it almost works -- but what seems to happen is that when the down arrow sends the portal to the next row, the script triggers again and the highlight rolls on down till it hit s the bottom. I'm attaching a picture of my script (Is there no way to copy and paste scripts into a text window?

I must be missing one small step?

Rolling.jpg

  • Author

Try:


If [ Code ( Get ( TriggerKeystroke ) ) = 29 ] 

Go to Portal Row [ Select; Previous ] 

Exit Script [ Result: False ] 

Else If [ Code ( Get ( TriggerKeystroke ) ) = 31 ] 

Go to Portal Row [ Select; Next ] 

Exit Script [ Result: False ] 

End If

Note that just moving to another portal row does not modify the variable's value.

Is there no way to copy and paste scripts into a text window?

Print > Preview > Copy > Cancel

Hi Comment -- thanks very much!

If you have a moment, could you explain why/how this

Exit Script [ Result: False ]

... I mean the logic of it? I'm not at all clear what the "Result" is 'of' and why it's false or how that stops the trigger from repeating!

THanks for helping out a relative noob.

  • Author

A script triggered OnObjectKeystroke runs BEFORE the triggering event itself (i.e. the keystroke) has been processed. If the script returns False, the event that triggered the script is canceled. Otherwise the event will proceed AFTER the script has run.

To understand how this works, set up a layout with two fields and attach a script to Field A that goes to Field B when you press "a". You will see that when you type "a" into Field A the focus moves to Field B AND the "a" is typed there. Now, if you had a similar trigger attached to Field B, you would be caught in an endless loop.

A script trigger attached to a portal is attached to ALL portal rows; so when you press the down arrow key, the script runs and moves to the next portal row. Immediately after that, the keypress is executed - or rather tries to be executed, but instead it triggers the script again. Exiting the script with a False result cancels the keypress event, so nothing happens after the script has run.

Crystal Clear -- and an invaluable lesson that really adds to my sense of FMP concept. THanks very much!

Not clear here?

I have tried adding the corrected script as shown above that is triggered by an OnObjectKeystroke script, attached to the Child portal of the ViewSelectedChild11 file.

I am not able to get the function of the arrow keys to move up and down in the portal rows. I have been away from FM for quite a few months, and seem to be missing something here. :qwery:

Any help to understand what I have missed would be greatly appreciated.

Thanks

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.