Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Highlighted
LJorgensen Absent Member.
Absent Member.
786 views

I have a problem figuring out how to control threads.

Have 2 programs: Program1 should stay in control, program2 contains a window that the user may activate.

Summary of source:

---

Program1 (called from my main application):

display floating window, modeless

           bind to thread.

call thread "Program2".

display screen-1.

accept screen-1.

 ---

Program2:

display floating windows, modeless, bind to thread.

display screen-2

accept screen-2

---

My problem is that control is in Program2 and not in Program1 even if Program1 displays and accept screen-1. User has to click window in Program1 to make it active.

What do I do wrong?

0 Likes
1 Solution

Accepted Solutions
Chuck Edgin Absent Member.
Absent Member.

RE: threads

Jump to solution

Shjerpe's answer might work but if your Program2 needs any user interaction it also needs to be sitting on an ACCEPT.

You can set the active+current window using Format 10 of the SET verb. You would do this in Program2, after the DISPLAY but before the ACCEPT:  

SET I-O WINDOW TO Prog1-Win1

A few things you'll need to make this work:

  • Each window should have a handle. If you're not already setting a handle, you should do so in the "display floating window" statement:
Display floating window, modeless, bind to thread, HANDLE IN Prog1-Win1 ...
  • The window handles needs to be declared in Working-Storage of both programs and should be EXTERNAL so that, for instance, Program2 can refer to Program1's handle:
01  Win-Handle-Group External.
03 Main-Win usage is handle of window.
03 Prog1-Win1 usage is handle of window.
03 Prog1-Win2 usage is handle of window.
03 Prog2-Win1 usage is handle of window.
03 Prog2-Win2 usage is handle of window.

Also, consider using INDEPENDENT windows instead of FLOATING windows. In your example, if Program2's window is FLOATING but it intersects Program1's window, it will be "above" and therefore covering part of Program1's window, even when Program1's window is active. With INDEPENDENT windows, whichever window is active moves to the front. However, this affects the parent/child relationship, so when you close (or destroy) Program1's window, it won't necessarily close Program2's window.

View solution in original post

5 Replies
Micro Focus Expert
Micro Focus Expert

RE: threads

Jump to solution
Your call thread Program2 occurs before you display and accept screen-1 in Program1. The call should occur in Program1 accept, something alongs the lines of if someone choose a menu item or something then call thread Program2.
I'm not sure if you need Program1 to get information from Program2 or vice versa, but threading allows SEND and RECEIVE so that you can send messages along the thread.
0 Likes
LJorgensen Absent Member.
Absent Member.

RE: threads

Jump to solution
Thank you for answering.
The purpose of Program2 is to display additional customer information to Program1 (holding customer basic information) and should automatically appear showing this information while the user runs Program1. User may modify information in Program2, but this is normally not the case. As it is now, user has to click Program1 to focus there, which is annoying.
Maybe I’m using wrong features. How would you normally solve this scenario?
0 Likes
Micro Focus Expert
Micro Focus Expert

RE: threads

Jump to solution
display screen-1.
call thread "Program2".
accept screen-1.

When you call Program2, have it do the display screen-2 ... but hold off on the accept screen-2.

This way screen-1 is waiting on the accept with both screens displaying.

See forum post .. community.microfocus.com/.../thread and look at the code DMiller suggests.
0 Likes
Chuck Edgin Absent Member.
Absent Member.

RE: threads

Jump to solution

Shjerpe's answer might work but if your Program2 needs any user interaction it also needs to be sitting on an ACCEPT.

You can set the active+current window using Format 10 of the SET verb. You would do this in Program2, after the DISPLAY but before the ACCEPT:  

SET I-O WINDOW TO Prog1-Win1

A few things you'll need to make this work:

  • Each window should have a handle. If you're not already setting a handle, you should do so in the "display floating window" statement:
Display floating window, modeless, bind to thread, HANDLE IN Prog1-Win1 ...
  • The window handles needs to be declared in Working-Storage of both programs and should be EXTERNAL so that, for instance, Program2 can refer to Program1's handle:
01  Win-Handle-Group External.
03 Main-Win usage is handle of window.
03 Prog1-Win1 usage is handle of window.
03 Prog1-Win2 usage is handle of window.
03 Prog2-Win1 usage is handle of window.
03 Prog2-Win2 usage is handle of window.

Also, consider using INDEPENDENT windows instead of FLOATING windows. In your example, if Program2's window is FLOATING but it intersects Program1's window, it will be "above" and therefore covering part of Program1's window, even when Program1's window is active. With INDEPENDENT windows, whichever window is active moves to the front. However, this affects the parent/child relationship, so when you close (or destroy) Program1's window, it won't necessarily close Program2's window.

View solution in original post

LJorgensen Absent Member.
Absent Member.

RE: threads

Jump to solution
Thank you very much!
This was indeed what I needed. Programs are running perfectly now.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.