You are viewing limited content. For full access, please sign in.

Question

Question

Is there a way to call a function when a pagination tab gets focus?

asked on October 27, 2023 • Show version history

In version 11, is there a way to call a function when a pagination tab gets focus? So either when the tab it clicked or the buttons [Next] and [Prev] are clicked. 

EDIT: this is in the modern designer, not classic. 

I made a feature request based on this post: https://answers.laserfiche.com/questions/213018/Feature-Request-for-modern-designer-when-pagination-page-gets-focus-trigger-event

 

0 0

Replies

replied on October 27, 2023

Are you using the classic form designer or the forms layout designer?

1 0
replied on October 27, 2023

The new designer. I know how to do it in classic, but having issues with the new way. 

0 0
replied on October 27, 2023 • Show version history

I don't think this is currently possible.

The LFForm object has options for setting/changing the pagination button labels, but I don't see any event handlers related to page changes or the tabs.

The javascript on these forms is sandboxed so it can't interact directly with any form/page elements, only what is provided via the LFForm object.

2 0
replied on October 27, 2023

I was thinking that was going to be the case. It means I will just need to put up with the code running way more than it needs to instead of at the one point it is actually needed to run. Or add a button and make it so the user must click that button to be able to submit.... I don't think the button method will be the best way. 

 

1 0
replied on August 13 • Show version history

I agree. I would rather compile data into a table when the user goes to the next page rather than on field change of 18 different fields. 

1 0
replied on August 13

I ended up using a couple buttons on the tab that grouped data is needed and until they click the button they can't submit the form. (this is a simplified description) 

1 0
replied on August 14 • Show version history

Nice. I need that table summed up so they can sign off on it. So i can't trust the user to do it on their own.

I ended up just putting it on the other tab so they would never see the form jumping around every time they enter/delete data. Makes sense to separate the entry fields on one tab and the results on another. So far so good. Just not as efficient. I have noticed a trend in version 12 like that.

Oh, also I updated one of my environments to the latest Forms update. The fix to make modern designer collections load quicker actually slows it down. I have a conspiracy theory that LF dev is making on prem version worse and worse to nudge everyone to the cloud. Someone please prove me wrong.  



Ya no. Please, please, please try again. 

1 0
replied on August 14

hmm that may explain why one of my forms did not do well when trying to convert it from classic designer to modern. I might try again to see if this fix, well fixed whatever was going on.

0 0
replied on August 14 • Show version history

Could be. My scenario was that after 20 rows of a collection the form slows down significantly. Not sure if others reported the same thing but they filed it as a bug. So they could reproduce it in some capacity. Not sure if that particular bug would impact converting to the Modern Designer.... But there are quite a few other fixes that got rolled out in that update. I hope if goes well for you :) 

1 0
replied on August 18

Hi @████████,

The Bug 655949 you highlighted is only aimed to fix a performance issue for Classic form designer, but you mentioned "The fix to make modern designer collections load quicker actually slows it down.", could you tell us if you are still suffering with performance issue on the new designer, or the fix on classic designer does not work? Please share.

1 0
replied on August 19 • Show version history

sorry for the confusion, This was in the classic designer where the slowness still exists for me. I was referring to converting to modern designer as the next step, but there is a mountain of JQuery to convert to JavaScript which I was hoping to avoid. Also, it's not a guarantee. 

0 0
replied on August 19 • Show version history

@████████, you will most likely find that when you do the conversation that a lot of what you had to do in JQuery, is now available as rule settings or object/task options on the form. 

I hav a very heavy coded form go from 1500 lines of code down to just over 900, however a lot of my lines are comments/documentation explaining the code so my non-Comp Sci team members can decipher what I have the code doing. This way they can re-use the code to work on their processes or if I'm out and something needs changed ASAP they can do so.

0 0
replied on August 19

@████████

You mean the bug fix was not working for you still? This was verified internally to have fixed with your business process, but if you still feel it's not fixed, please open a support ticket to let us review your design and check potential issues.

0 0
replied on August 20

Well the form picked up just a little bit of speed after 20 rows. The problem is that the dropdown fields no longer load on the new collection rows. So it is unusable, therefore worse. Can you reproduce on your end? 

I have several projects with deadlines that need to get taken care of first. This makes a third support ticket for me to submit that I can't get to. Maybe in October if I'm lucky. I appreciate the follow up!

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.