Skip to main content

Hello, I am working on several programs that call each other and I am having an issue with an ACCEPT in one program locking up the next program called. I am running Acu runtime 10.0.1 and working in AcuBench.

This issue only happens when running in the Thin Client/AcuConnect environment and in Non Debug mode. So if I run this in debug mode in Thin Client/AcuConnect, it works fine. Go Figure.

I have a program that have a series of fields on the screen that the user can default to a specific value. So each control is skipped but another program is called that displays a list box of data that the user can select. If all fields are defaulted in program 1, program 2 locks up on the display command that displays the graphical window. We put several DISPLAY MESSAGE BOX commands in the code to figure this out.

I have a feeling this has something to do with setting focus on an object in program 1 and not issuing an ACCEPT command before calling program 2. So how do I terminate the ACCEPT command in Program 1 before calling Program 2? I tried moving 0 to Accept-Control but that did not help. Or is there another issue that might be causing program 2 to lock up in Thin Client/AcuConnect? Any and all help would be very appreciated!

Now to clean the brick wall.

Thanks!

Hello, I am working on several programs that call each other and I am having an issue with an ACCEPT in one program locking up the next program called. I am running Acu runtime 10.0.1 and working in AcuBench.

This issue only happens when running in the Thin Client/AcuConnect environment and in Non Debug mode. So if I run this in debug mode in Thin Client/AcuConnect, it works fine. Go Figure.

I have a program that have a series of fields on the screen that the user can default to a specific value. So each control is skipped but another program is called that displays a list box of data that the user can select. If all fields are defaulted in program 1, program 2 locks up on the display command that displays the graphical window. We put several DISPLAY MESSAGE BOX commands in the code to figure this out.

I have a feeling this has something to do with setting focus on an object in program 1 and not issuing an ACCEPT command before calling program 2. So how do I terminate the ACCEPT command in Program 1 before calling Program 2? I tried moving 0 to Accept-Control but that did not help. Or is there another issue that might be causing program 2 to lock up in Thin Client/AcuConnect? Any and all help would be very appreciated!

Now to clean the brick wall.

Thanks!

Without a test case demonstrating what is happening it is difficult to say.  You might look at setting EVENT-ACTION.  The details for that are towards the bottom of this page:

documentation.microfocus.com/.../GUID-2829064C-6195-4AF2-BD2F-1F8F06237307.html

Hello, I am working on several programs that call each other and I am having an issue with an ACCEPT in one program locking up the next program called. I am running Acu runtime 10.0.1 and working in AcuBench.

This issue only happens when running in the Thin Client/AcuConnect environment and in Non Debug mode. So if I run this in debug mode in Thin Client/AcuConnect, it works fine. Go Figure.

I have a program that have a series of fields on the screen that the user can default to a specific value. So each control is skipped but another program is called that displays a list box of data that the user can select. If all fields are defaulted in program 1, program 2 locks up on the display command that displays the graphical window. We put several DISPLAY MESSAGE BOX commands in the code to figure this out.

I have a feeling this has something to do with setting focus on an object in program 1 and not issuing an ACCEPT command before calling program 2. So how do I terminate the ACCEPT command in Program 1 before calling Program 2? I tried moving 0 to Accept-Control but that did not help. Or is there another issue that might be causing program 2 to lock up in Thin Client/AcuConnect? Any and all help would be very appreciated!

Now to clean the brick wall.

Thanks!

I would have to set up a small test area in order to do that. Our system comprises of 100s of programs so it is not easy to whip up 2 or 3 programs to post. I would have to contact Micro Focus Support for that.

In the documentation you provided for me, I could SET EVENT-ACTION TO EVENT-ACTION-TERMINATE, would I need to do some sort of ACCEPT command in order for that to work before calling the next program?

Hello, I am working on several programs that call each other and I am having an issue with an ACCEPT in one program locking up the next program called. I am running Acu runtime 10.0.1 and working in AcuBench.

This issue only happens when running in the Thin Client/AcuConnect environment and in Non Debug mode. So if I run this in debug mode in Thin Client/AcuConnect, it works fine. Go Figure.

I have a program that have a series of fields on the screen that the user can default to a specific value. So each control is skipped but another program is called that displays a list box of data that the user can select. If all fields are defaulted in program 1, program 2 locks up on the display command that displays the graphical window. We put several DISPLAY MESSAGE BOX commands in the code to figure this out.

I have a feeling this has something to do with setting focus on an object in program 1 and not issuing an ACCEPT command before calling program 2. So how do I terminate the ACCEPT command in Program 1 before calling Program 2? I tried moving 0 to Accept-Control but that did not help. Or is there another issue that might be causing program 2 to lock up in Thin Client/AcuConnect? Any and all help would be very appreciated!

Now to clean the brick wall.

Thanks!

I would have to set up a small test area in order to do that. Our system comprises of 100s of programs so it is not easy to whip up 2 or 3 programs to post. I would have to contact Micro Focus Support for that.

In the documentation you provided for me, I could SET EVENT-ACTION TO EVENT-ACTION-TERMINATE, would I need to do some sort of ACCEPT command in order for that to work before calling the next program?

Hello, I am working on several programs that call each other and I am having an issue with an ACCEPT in one program locking up the next program called. I am running Acu runtime 10.0.1 and working in AcuBench.

This issue only happens when running in the Thin Client/AcuConnect environment and in Non Debug mode. So if I run this in debug mode in Thin Client/AcuConnect, it works fine. Go Figure.

I have a program that have a series of fields on the screen that the user can default to a specific value. So each control is skipped but another program is called that displays a list box of data that the user can select. If all fields are defaulted in program 1, program 2 locks up on the display command that displays the graphical window. We put several DISPLAY MESSAGE BOX commands in the code to figure this out.

I have a feeling this has something to do with setting focus on an object in program 1 and not issuing an ACCEPT command before calling program 2. So how do I terminate the ACCEPT command in Program 1 before calling Program 2? I tried moving 0 to Accept-Control but that did not help. Or is there another issue that might be causing program 2 to lock up in Thin Client/AcuConnect? Any and all help would be very appreciated!

Now to clean the brick wall.

Thanks!

I would guess that the accept in Program 1 never gets completed. Here is the typical AcuBench code:

   PERFORM UNTIL Exit-Pushed

             ACCEPT Screen1  

                ON EXCEPTION PERFORM Acu-Screen1-Evaluate-Func

             END-ACCEPT

          END-PERFORM

You said that program 1 gets filled by defaults, does the call to Program 2 happen before this accept statement?

One other thing to check, are the screens and handles for this program1 and program2 unique? Stated another way, you don't have 2 ACCEPT Screen1   going on.

Hello, I am working on several programs that call each other and I am having an issue with an ACCEPT in one program locking up the next program called. I am running Acu runtime 10.0.1 and working in AcuBench.

This issue only happens when running in the Thin Client/AcuConnect environment and in Non Debug mode. So if I run this in debug mode in Thin Client/AcuConnect, it works fine. Go Figure.

I have a program that have a series of fields on the screen that the user can default to a specific value. So each control is skipped but another program is called that displays a list box of data that the user can select. If all fields are defaulted in program 1, program 2 locks up on the display command that displays the graphical window. We put several DISPLAY MESSAGE BOX commands in the code to figure this out.

I have a feeling this has something to do with setting focus on an object in program 1 and not issuing an ACCEPT command before calling program 2. So how do I terminate the ACCEPT command in Program 1 before calling Program 2? I tried moving 0 to Accept-Control but that did not help. Or is there another issue that might be causing program 2 to lock up in Thin Client/AcuConnect? Any and all help would be very appreciated!

Now to clean the brick wall.

Thanks!

One other question, since Program2 is displaying the list box to select an item for Screen 1 in program1, is the call, a call using threads?

Hello, I am working on several programs that call each other and I am having an issue with an ACCEPT in one program locking up the next program called. I am running Acu runtime 10.0.1 and working in AcuBench.

This issue only happens when running in the Thin Client/AcuConnect environment and in Non Debug mode. So if I run this in debug mode in Thin Client/AcuConnect, it works fine. Go Figure.

I have a program that have a series of fields on the screen that the user can default to a specific value. So each control is skipped but another program is called that displays a list box of data that the user can select. If all fields are defaulted in program 1, program 2 locks up on the display command that displays the graphical window. We put several DISPLAY MESSAGE BOX commands in the code to figure this out.

I have a feeling this has something to do with setting focus on an object in program 1 and not issuing an ACCEPT command before calling program 2. So how do I terminate the ACCEPT command in Program 1 before calling Program 2? I tried moving 0 to Accept-Control but that did not help. Or is there another issue that might be causing program 2 to lock up in Thin Client/AcuConnect? Any and all help would be very appreciated!

Now to clean the brick wall.

Thanks!

It is likely that your screen display contains code like this .. EVENT PROCEDURE Screen1-Event-Proc

I do not know if you are looking at screen events, or control events, but the biggest warning I can provide is that events do not terminate the accept. What is likely is that either is an after screen display or in the process of evaluating exceptions, or responding to control events, you're making the call to Prog2. If that is the case, consider using threads to make that call.

You are correct in that finding the event or finding the set of events where you would use SET EVENT-ACTION TO EVENT-ACTION-TERMINATE is difficult.

Hello, I am working on several programs that call each other and I am having an issue with an ACCEPT in one program locking up the next program called. I am running Acu runtime 10.0.1 and working in AcuBench.

This issue only happens when running in the Thin Client/AcuConnect environment and in Non Debug mode. So if I run this in debug mode in Thin Client/AcuConnect, it works fine. Go Figure.

I have a program that have a series of fields on the screen that the user can default to a specific value. So each control is skipped but another program is called that displays a list box of data that the user can select. If all fields are defaulted in program 1, program 2 locks up on the display command that displays the graphical window. We put several DISPLAY MESSAGE BOX commands in the code to figure this out.

I have a feeling this has something to do with setting focus on an object in program 1 and not issuing an ACCEPT command before calling program 2. So how do I terminate the ACCEPT command in Program 1 before calling Program 2? I tried moving 0 to Accept-Control but that did not help. Or is there another issue that might be causing program 2 to lock up in Thin Client/AcuConnect? Any and all help would be very appreciated!

Now to clean the brick wall.

Thanks!

shjerpe, sorry for the delay in replying, was out of the office the past week.

You are correct we are doing the PERFORM UNTIL Exit-Pushed routine.

Yes Program 2 is called before the Accept is executed.

Yes all screens and objects are unique.

Not using Threads to call Program 2.

Hello, I am working on several programs that call each other and I am having an issue with an ACCEPT in one program locking up the next program called. I am running Acu runtime 10.0.1 and working in AcuBench.

This issue only happens when running in the Thin Client/AcuConnect environment and in Non Debug mode. So if I run this in debug mode in Thin Client/AcuConnect, it works fine. Go Figure.

I have a program that have a series of fields on the screen that the user can default to a specific value. So each control is skipped but another program is called that displays a list box of data that the user can select. If all fields are defaulted in program 1, program 2 locks up on the display command that displays the graphical window. We put several DISPLAY MESSAGE BOX commands in the code to figure this out.

I have a feeling this has something to do with setting focus on an object in program 1 and not issuing an ACCEPT command before calling program 2. So how do I terminate the ACCEPT command in Program 1 before calling Program 2? I tried moving 0 to Accept-Control but that did not help. Or is there another issue that might be causing program 2 to lock up in Thin Client/AcuConnect? Any and all help would be very appreciated!

Now to clean the brick wall.

Thanks!

I will try using a Thread to call Program2 and I will let you know how it works.

Terms & ConditionsAccessibility statement