Announcements
We have a custom form for which we have a requirement that tabbing through fields stops at that last field and does not go to the next line. We found a way to stop it from going to the next line, but if you continue tabbing the cursor jumps to other parts of the form outside of the scrolling window.
Any thoughts on how to limit tabbing to the current line or having it stop at the end of the line?
Thanks
*This post is locked for comments
Thanks everyone! Your combined answers all led me to a solution that works for us. Rather than trying to get around the tabbing functions, I set up conditions checking to see if specific fields were empty. If so I did not save the record. With that logic I can then go to the next line which is the expected navigation in these type of windows. I appreciate the help.
Leslie, I think the issue was found. There is a save table in the change event for the line. The person who coded it said that each line had to be saved individually since you can't save a set of lines at once. I think the problem is in when you assume the line has changed. I would think running any change event on a script for instance setting a date on a new line would cause the change event to fire.
If so then I think if I add a condition to the logic that I defines the string as empty and thus ignore the changes and don't save, I'll be set.
Do you agree? Or is there another concept we are missing in regards to saving perhaps multiple changes to multiple lines?
Can you try the below logic before saving (scrolling window details).
Say for example,
You have a table with the PK SOPNumber, SOPType and LineSeq. Check if all the details are not empty before saving.
Sample Code:
if not empty(SOPNumber of window ScrollingWindow) and not empty (SOPType of window ScrollingWindow) and not empty (LineSeq of window ScrollingWindow) then
{Code: Save}
end if;
Thanks,
Anvar
Leslie, may be all the fields on scrolling window are not required fields and the one like line item sequence and document number is hidden on scrolling window so when line change even occurs it save the line. It could only be clear by reviewing data on backend how is it saving, or checking the dex code.
Hi Leslie,
I have not yet tried Almas solution, but I think it might be what we need. The initial problem was that as the users tabbed through the line it would continue to the next line. On saving that seemed to create an extra blank record each time. So the developer changed it so that it would not start a new line. I think that is what caused it to jump around to the header (or the next available field on the form). I guess another solution would be to have it not create an empty record when saving.
Erick,
I read the following and am a bit confused:
"We found a way to stop it from going to the next line, but if you continue tabbing the cursor jumps to other parts of the form outside of the scrolling window." I'm not sure how you did it, but is the problem now that you don't want them to be able to navigate outside the scrolling window? I think Almas hinted at the solution. Through code, we simply wouldn't let them out of the scrolling window so long as the header has a record.
Kind regards,
Leslie
Scrolling window line change event occur when cursor gets tab out from the last field on the scrolling window, so you can force cursor to stay on same line by adding some code in your line change event. it would be a little tricky.
The requirement we have is that they don't want a new line created in the scrolling window when they tab past the end of the last populated line. There is nothing specific to share in this case just a general question about tab navigation in a scrolling window.
Why you want to stop it at the last field, are you doing so for doing any verification? if yes let me know what exactly you want to do.
and if possible, also share your code.
#1
Almas Mahfooz
3
User Group Leader
Share
Report
All responses (
Answers (
