Display 'loading' screen
-
- New User
- Posts: 12
- Joined: Mon Aug 24, 2020 2:57 pm
- First Name: David
- Last Name: Miller
- Company Name: Marathon Resources, LLC
- City: Wichita
- State / Province: Kansas
- Country: United States
- Contact:
Display 'loading' screen
I am trying to display a window with the 'spinner' graphic shown while the user is waiting for real screen to load.
I found a topic saying that I can't just write the format so I'm using 'exfmt' and I've got 'pui.click();' in the onLoad event for that format so the user doesn't have to press <enter>. The spinner window displays as expected but after the data screen is shown the program continues as if the <enter> key was pressed again even though it hasn't. I only have 'pui.click();' on the one format. Right now the program is in an endless loop of loading the data and showing the screen. Why would the 2nd screen not wait for user interaction?
EDIT: The problem appears to only occur when the spinner window is the first screen. I modified the program to display the main screen first and only display the spinner window when a button is pressed. The modified program displays the main screen as expected for both the initial display and after the spinner window is shown. Could there be an initialization issue in the handler?
I found a topic saying that I can't just write the format so I'm using 'exfmt' and I've got 'pui.click();' in the onLoad event for that format so the user doesn't have to press <enter>. The spinner window displays as expected but after the data screen is shown the program continues as if the <enter> key was pressed again even though it hasn't. I only have 'pui.click();' on the one format. Right now the program is in an endless loop of loading the data and showing the screen. Why would the 2nd screen not wait for user interaction?
EDIT: The problem appears to only occur when the spinner window is the first screen. I modified the program to display the main screen first and only display the spinner window when a button is pressed. The modified program displays the main screen as expected for both the initial display and after the spinner window is shown. Could there be an initialization issue in the handler?
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: Display 'loading' screen
Since I haven't seen the screen, I can only take guesses.
Is it possible that you are overlaying the other screen? therefore, the pui.click() still occurs because it's on that screen? Or maybe the user is pressing enter, and its carrying over to the next screen?
Is it possible that you are overlaying the other screen? therefore, the pui.click() still occurs because it's on that screen? Or maybe the user is pressing enter, and its carrying over to the next screen?
-
- New User
- Posts: 12
- Joined: Mon Aug 24, 2020 2:57 pm
- First Name: David
- Last Name: Miller
- Company Name: Marathon Resources, LLC
- City: Wichita
- State / Province: Kansas
- Country: United States
- Contact:
Re: Display 'loading' screen
No, I'm just working on developing the program so no other user involved. I wondered if I was doing something odd but don't believe that to be the case. I've stepped thru the program via debug and it's doing it all on it's own. At one point I wondered if there was an issue with RDi/ debug adding something so I put a 'return' in the RPG code to keep from having the endless loop. The spinner would show, then the other screen would flash and the program ended. I'm confident that I'm not double-clicking, pressing <enter> or introducing any other response... especially since displaying the main screen first got rid of the issue. Unfortunately that isn't the resolution since the user would have to wait during the initial program load with no spinner.
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: Display 'loading' screen
After it has done one automatic refresh that you didn't want, use a breakpoint in the debugger to stop the RPG program. then, in the browser press ctrl-f9, this will download a dump of json data that was sent from the IBM i to the browser. Post that here, and I'll see if I can spot anything obvious.
-
- New User
- Posts: 12
- Joined: Mon Aug 24, 2020 2:57 pm
- First Name: David
- Last Name: Miller
- Company Name: Marathon Resources, LLC
- City: Wichita
- State / Province: Kansas
- Country: United States
- Contact:
Re: Display 'loading' screen
JSON dump is attached. Thanks.
[Attachment removed.]
[Attachment removed.]
Last edited by xrunner on Tue Sep 22, 2020 4:52 pm, edited 1 time in total.
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: Display 'loading' screen
So you have 3 screens that are overlaying each other:
Since the 2nd screen (SCRNLOAD) is being re-drawn, the code in its onload is being executed again, thus the pui.click() is being re-run and submitting the screen.
I wonder why the 3rd screen (named CTL from file REVPLAN30D) is used as a "window", and therefore, overlays the others? Is that intentional or accidental?
- REVPLAN10D, CTL (with SFL5)
- REVPLAN30D, SCRNLOAD
- REVPLAN30D, CTL (with SFL)
Since the 2nd screen (SCRNLOAD) is being re-drawn, the code in its onload is being executed again, thus the pui.click() is being re-run and submitting the screen.
I wonder why the 3rd screen (named CTL from file REVPLAN30D) is used as a "window", and therefore, overlays the others? Is that intentional or accidental?
-
- New User
- Posts: 12
- Joined: Mon Aug 24, 2020 2:57 pm
- First Name: David
- Last Name: Miller
- Company Name: Marathon Resources, LLC
- City: Wichita
- State / Province: Kansas
- Country: United States
- Contact:
Re: Display 'loading' screen
REVPLAN10D is the screen from the calling program. REVPLAN30 immediately exfmt's SCRNLOAD and then runs the load process for CTL/SFL and then displays them. They are all windows by design.
So from what you're saying about EXFMT is it the CTL/SFL display that would force SCRNLOAD to get executed again? The CTL/SFL wouldn't have to be a window. Would there be a way to conditionally run the pui.click() so I can control when it runs?
So from what you're saying about EXFMT is it the CTL/SFL display that would force SCRNLOAD to get executed again? The CTL/SFL wouldn't have to be a window. Would there be a way to conditionally run the pui.click() so I can control when it runs?
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: Display 'loading' screen
There seem to be some words missing from the above sentence, so I may be missing some nuance... but, yes, SCRNLOAD is executed again. This is the problem.xrunner wrote:So from what you're saying about EXFMT is it the CTL/SFL display that would force SCRNLOAD to get executed again?
If you change it so that its not a window, the problem should go away since it's not overlaying SCRNLOAD anymore.xrunner wrote:The CTL/SFL wouldn't have to be a window.
Yes, you can use any sort of JavaScript statements in your onload, so it's certainly possible to code an 'if' statement around your pui.click(). but, what would you check for?xrunner wrote:Would there be a way to conditionally run the pui.click() so I can control when it runs?
Personally, I would opt for changing CTL/SFL so that it isn't a window. Not only would this be easier, but it'd also perform better.
-
- New User
- Posts: 12
- Joined: Mon Aug 24, 2020 2:57 pm
- First Name: David
- Last Name: Miller
- Company Name: Marathon Resources, LLC
- City: Wichita
- State / Province: Kansas
- Country: United States
- Contact:
Re: Display 'loading' screen
I agree with everything you've said, tested it and it works as you said it would. The only exception is that if the spinner window isn't shown first.
1. REVPLAN10 calls REVPLAN30
2. REVPLAN30 exfmt CTL/SFL
3. User presses Search button
4. REVPLAN30 exfmt SCRNLOAD
5. REVPLAN30 exfmt CTL/SFL
No looping problem. It only seems to be a problem when SCRNLOAD is the first window written in REVPLAN30.
I appreciate your time on this. Your insights keep me humble.
[EDIT]
If I think about it as a stack- instead of just that SCRNLOAD has been displayed- is that the difference?
ie: Because CTL/SFL is lower in the stack SCRNLOAD doesn't get rewritten? Is SCRNLOAD essentially removed from the stack?
1. REVPLAN10 calls REVPLAN30
2. REVPLAN30 exfmt CTL/SFL
3. User presses Search button
4. REVPLAN30 exfmt SCRNLOAD
5. REVPLAN30 exfmt CTL/SFL
No looping problem. It only seems to be a problem when SCRNLOAD is the first window written in REVPLAN30.
I appreciate your time on this. Your insights keep me humble.
[EDIT]
If I think about it as a stack- instead of just that SCRNLOAD has been displayed- is that the difference?
ie: Because CTL/SFL is lower in the stack SCRNLOAD doesn't get rewritten? Is SCRNLOAD essentially removed from the stack?
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: Display 'loading' screen
Yes, think of it as a stack... except, the stack is wiped out when you display a screen that doesn't overlay the previous ones.
So REVPLAN10's output puts a screen on the stack
REVPLAN30 EXFMT CTL/SFL would wipe out the stack (assuming you changed that to stop overlaying), so only CTL/SFL is on the stack
REVPLAN30 SCRNLOAD overlays the previous screen, so now CTL/SFL and SCRNLOAD are on the stack
REVPLAN30 CTL/SFL again wipes the stack out, so just CTL/SFL are on the stack again.
So REVPLAN10's output puts a screen on the stack
REVPLAN30 EXFMT CTL/SFL would wipe out the stack (assuming you changed that to stop overlaying), so only CTL/SFL is on the stack
REVPLAN30 SCRNLOAD overlays the previous screen, so now CTL/SFL and SCRNLOAD are on the stack
REVPLAN30 CTL/SFL again wipes the stack out, so just CTL/SFL are on the stack again.
Who is online
Users browsing this forum: No registered users and 1 guest