[archive] Multi-Thread application help

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Hi,

I have exactly what you need, and it uses menu data files that the user can define/modify for themselves. It can be used to launch AcuGT programs as well as Windows programs or URLs.

How much info do you need? Are you just after guidance or do you want a full working copy (this is our proprietary software so I'm not sure I could send it all without an accompanying invoice :( )?

What have you tried so far? Some tricks I've found include:-

1. All of the programs that you call from the menu need to have "LINK TO THREAD" in the DISPLAY {GRAPHICAL} WINDOW statement.
   
2. Threads are a bugger to debug :(
   
3. All of the programs that you call from the menu should use STOP THREAD rather than STOP RUN. This prevents one aborting program from killing every other program that your menu has launched.
   
4. Threads are a bugger to debug :(
   
5. I found it useful in the menu program to keep track of the number of threads that have been started and ended, so that when you close the menu program itself, you can query the user if there are some threads still running. It might not be a good idea to kill the menu when an important update program is still running.
   
6. Threads are a bugger to debug :(
   
7. ...but they're worth it in the end :)

The threading syntax isn't that hard:-**AcuBench Column Block**
PERFORM IN THREAD               
    5000-CALL-MENU-OPTION       
    HANDLE IN WS-THREAD-HANDLE

Ian

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Hi,

I have exactly what you need, and it uses menu data files that the user can define/modify for themselves. It can be used to launch AcuGT programs as well as Windows programs or URLs.

How much info do you need? Are you just after guidance or do you want a full working copy (this is our proprietary software so I'm not sure I could send it all without an accompanying invoice :( )?

What have you tried so far? Some tricks I've found include:-

1. All of the programs that you call from the menu need to have "LINK TO THREAD" in the DISPLAY {GRAPHICAL} WINDOW statement.
   
2. Threads are a bugger to debug :(
   
3. All of the programs that you call from the menu should use STOP THREAD rather than STOP RUN. This prevents one aborting program from killing every other program that your menu has launched.
   
4. Threads are a bugger to debug :(
   
5. I found it useful in the menu program to keep track of the number of threads that have been started and ended, so that when you close the menu program itself, you can query the user if there are some threads still running. It might not be a good idea to kill the menu when an important update program is still running.
   
6. Threads are a bugger to debug :(
   
7. ...but they're worth it in the end :)

The threading syntax isn't that hard:-**AcuBench Column Block**
PERFORM IN THREAD               
    5000-CALL-MENU-OPTION       
    HANDLE IN WS-THREAD-HANDLE

Ian

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

I tend to agree with these comments, threads really are a bugger to debug.
We use threads significantly for pop-up diaries and so on, we can implement it at the menu selection level as you seem to want to do, but have withdrawn it for now as controlling how many threads have been started and memory issues have not really been solved.
Good luck anyway - if you are just starting to use threads then you may need it for a while! It gave me some new grey hair at the beginning - but the results are worth it.

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

I tend to agree with these comments, threads really are a bugger to debug.
We use threads significantly for pop-up diaries and so on, we can implement it at the menu selection level as you seem to want to do, but have withdrawn it for now as controlling how many threads have been started and memory issues have not really been solved.
Good luck anyway - if you are just starting to use threads then you may need it for a while! It gave me some new grey hair at the beginning - but the results are worth it.

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Thanks guys for the help. Sounds like we are in for some fun times with threads. Looks like what we have been working with is close we just need to keep working with it to make it function the way we want. Blacky the bit about "Stop Thread" vs "Stop Run" is probably the biggest clue. We are using "CALL" commands to call our old character based programs inside Graphical windows and most of the old code has "Stop Run" or "Exit Program" commands at the end.

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Thanks guys for the help. Sounds like we are in for some fun times with threads. Looks like what we have been working with is close we just need to keep working with it to make it function the way we want. Blacky the bit about "Stop Thread" vs "Stop Run" is probably the biggest clue. We are using "CALL" commands to call our old character based programs inside Graphical windows and most of the old code has "Stop Run" or "Exit Program" commands at the end.

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Thanks guys for the help. Sounds like we are in for some fun times with threads. Looks like what we have been working with is close we just need to keep working with it to make it function the way we want. Blacky the bit about "Stop Thread" vs "Stop Run" is probably the biggest clue. We are using "CALL" commands to call our old character based programs inside Graphical windows and most of the old code has "Stop Run" or "Exit Program" commands at the end.

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Happy to share some details of our application if it helps you.
The EXIT PROGRAM seems fine by the way, thats what we do. Just don't do STOP RUN.


Basically the user clicks options from the left side of the screen which are populated from a menu maintenance file.
This loads or reloads the grid in the middle with options depending on security etc.
We also added the favourites on the right for ease of use/faster access.

The following code happens to call the program you've clicked on

           CALL THREAD VDU-PROG-NAME HANDLE WS-THREAD
                                     USING LINKAGE-SECTION-RECORD
                ON EXCEPTION
                      MOVE 0065 TO MSG-KEY
                      PERFORM DISPLAY-MSG-GUI
           END-CALL


We also allow message to be received into the menu program.
e.g. all our programs firstly check to see if you're actually licensed to run it or not, and if not then the security routine sends back a message to the menu with a reason code as to why it refused to run.

The forum is quite a good information source, i've certainly gained from it and hopefully you will too.

Shaun

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Happy to share some details of our application if it helps you.
The EXIT PROGRAM seems fine by the way, thats what we do. Just don't do STOP RUN.


Basically the user clicks options from the left side of the screen which are populated from a menu maintenance file.
This loads or reloads the grid in the middle with options depending on security etc.
We also added the favourites on the right for ease of use/faster access.

The following code happens to call the program you've clicked on

           CALL THREAD VDU-PROG-NAME HANDLE WS-THREAD
                                     USING LINKAGE-SECTION-RECORD
                ON EXCEPTION
                      MOVE 0065 TO MSG-KEY
                      PERFORM DISPLAY-MSG-GUI
           END-CALL


We also allow message to be received into the menu program.
e.g. all our programs firstly check to see if you're actually licensed to run it or not, and if not then the security routine sends back a message to the menu with a reason code as to why it refused to run.

The forum is quite a good information source, i've certainly gained from it and hopefully you will too.

Shaun

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

1. All of the programs that you call from the menu need to have "LINK TO THREAD" in the DISPLAY {GRAPHICAL} WINDOW statement.
   
2. Threads are a bugger to debug :(
   
3. All of the programs that you call from the menu should use STOP THREAD rather than STOP RUN. This prevents one aborting program from killing every other program that your menu has launched.
   
4. Threads are a bugger to debug :(
   
5. I found it useful in the menu program to keep track of the number of threads that have been started and ended, so that when you close the menu program itself, you can query the user if there are some threads still running. It might not be a good idea to kill the menu when an important update program is still running.
   
6. Threads are a bugger to debug :(
   
7. ...but they're worth it in the end :)

Hi Ian,

We use threads in our application, and 99% of the time everything is great.
But we have 1 large site (approx 75 users) who probably get a memory access violation or remote host is not responding on average once per day.

May I ask a few questions please?

You say all programs called from the main thread need to have LINK TO THREAD.
It was recommended to me by Acucorp UK to use BIND TO THREAD.
I can't understand the difference, could you maybe shed some more light on this for me?

The STOP THREAD vs STOP RUN.
We use EXIT PROGRAM, again wondering what the difference might be?

Agreed 100%, keep track of threads, we do this too so that programs cant be shut down until the users finishes with them.

The remote hosts issues I understand are usually because of looping code, but in the cases we sometimes get and based on information from users it seems to happen when they're switching between threads or switching to outlook or other applications.

The memory access violations when we get details usually refer to the .prd file and point to the line which is displaying the screen.
We use AcuBench to design all screens.

Im just wondering if setting the BIND TO THREAD & LINK TO THREAD
And if the STOP THREAD instead of EXIT PROGRAM might make a difference.

We're running on this particular site V7.2 on Sco Openserver with V7.2 clients running a mixture of XP with W2K

Many thanks,

Shaun

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

1. All of the programs that you call from the menu need to have "LINK TO THREAD" in the DISPLAY {GRAPHICAL} WINDOW statement.
   
2. Threads are a bugger to debug :(
   
3. All of the programs that you call from the menu should use STOP THREAD rather than STOP RUN. This prevents one aborting program from killing every other program that your menu has launched.
   
4. Threads are a bugger to debug :(
   
5. I found it useful in the menu program to keep track of the number of threads that have been started and ended, so that when you close the menu program itself, you can query the user if there are some threads still running. It might not be a good idea to kill the menu when an important update program is still running.
   
6. Threads are a bugger to debug :(
   
7. ...but they're worth it in the end :)

Hi Ian,

We use threads in our application, and 99% of the time everything is great.
But we have 1 large site (approx 75 users) who probably get a memory access violation or remote host is not responding on average once per day.

May I ask a few questions please?

You say all programs called from the main thread need to have LINK TO THREAD.
It was recommended to me by Acucorp UK to use BIND TO THREAD.
I can't understand the difference, could you maybe shed some more light on this for me?

The STOP THREAD vs STOP RUN.
We use EXIT PROGRAM, again wondering what the difference might be?

Agreed 100%, keep track of threads, we do this too so that programs cant be shut down until the users finishes with them.

The remote hosts issues I understand are usually because of looping code, but in the cases we sometimes get and based on information from users it seems to happen when they're switching between threads or switching to outlook or other applications.

The memory access violations when we get details usually refer to the .prd file and point to the line which is displaying the screen.
We use AcuBench to design all screens.

Im just wondering if setting the BIND TO THREAD & LINK TO THREAD
And if the STOP THREAD instead of EXIT PROGRAM might make a difference.

We're running on this particular site V7.2 on Sco Openserver with V7.2 clients running a mixture of XP with W2K

Many thanks,

Shaun

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Hi Ian,

You're LINK TO THREAD has got me thinking.
OK, as mentioned we use Acubench to create our screens, and as mentioned we're using BIND TO THREAD

Here's the code which acubench has generated for 1 particular screen.
       
       Acu-Screen1-Create-Win.
      *    Before-Create
      * display screen
              DISPLAY Independent GRAPHICAL WINDOW
                 LINES 29.04, SIZE 100.00, CELL HEIGHT 23,
                 CELL WIDTH 7, AUTO-MINIMIZE, COLOR IS 65793,
                 CONTROL FONT Small-Font, ERASE, LABEL-OFFSET 0,
                 RESIZABLE, WITH SYSTEM MENU, TITLE WS-TITLE-DESC,
                 TITLE-BAR, USER-GRAY, USER-WHITE,
                 HANDLE IS Screen1-Handle

Now maybe its just me, but I don't see anywhere it mentioned the BIND TO THREAD.

So, I then also add set the LINK TO THREAD via acubench, and heres the same code.

       Acu-Screen1-Create-Win.
      *    Before-Create
      * display screen
              DISPLAY Independent GRAPHICAL WINDOW
                 LINES 29.04, SIZE 100.00, CELL HEIGHT 23,
                 CELL WIDTH 7, AUTO-MINIMIZE, COLOR IS 65793,
                 CONTROL FONT Small-Font, ERASE, LABEL-OFFSET 0,
                 LINK TO THREAD, RESIZABLE, WITH SYSTEM MENU,
                 TITLE WS-TITLE-DESC, TITLE-BAR, USER-GRAY, USER-WHITE,
                 HANDLE IS Screen1-Handle

the LINK TO THREAD is there.

I'm going to raise with tech support.

But i'd really appreciate you're thoughts on this please - if you can spare the time of course.

Thanks,

Shaun

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Hi Ian,

You're LINK TO THREAD has got me thinking.
OK, as mentioned we use Acubench to create our screens, and as mentioned we're using BIND TO THREAD

Here's the code which acubench has generated for 1 particular screen.
       
       Acu-Screen1-Create-Win.
      *    Before-Create
      * display screen
              DISPLAY Independent GRAPHICAL WINDOW
                 LINES 29.04, SIZE 100.00, CELL HEIGHT 23,
                 CELL WIDTH 7, AUTO-MINIMIZE, COLOR IS 65793,
                 CONTROL FONT Small-Font, ERASE, LABEL-OFFSET 0,
                 RESIZABLE, WITH SYSTEM MENU, TITLE WS-TITLE-DESC,
                 TITLE-BAR, USER-GRAY, USER-WHITE,
                 HANDLE IS Screen1-Handle

Now maybe its just me, but I don't see anywhere it mentioned the BIND TO THREAD.

So, I then also add set the LINK TO THREAD via acubench, and heres the same code.

       Acu-Screen1-Create-Win.
      *    Before-Create
      * display screen
              DISPLAY Independent GRAPHICAL WINDOW
                 LINES 29.04, SIZE 100.00, CELL HEIGHT 23,
                 CELL WIDTH 7, AUTO-MINIMIZE, COLOR IS 65793,
                 CONTROL FONT Small-Font, ERASE, LABEL-OFFSET 0,
                 LINK TO THREAD, RESIZABLE, WITH SYSTEM MENU,
                 TITLE WS-TITLE-DESC, TITLE-BAR, USER-GRAY, USER-WHITE,
                 HANDLE IS Screen1-Handle

the LINK TO THREAD is there.

I'm going to raise with tech support.

But i'd really appreciate you're thoughts on this please - if you can spare the time of course.

Thanks,

Shaun

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Hi Ian,

You're LINK TO THREAD has got me thinking.
OK, as mentioned we use Acubench to create our screens, and as mentioned we're using BIND TO THREAD

Here's the code which acubench has generated for 1 particular screen.
       
       Acu-Screen1-Create-Win.
      *    Before-Create
      * display screen
              DISPLAY Independent GRAPHICAL WINDOW
                 LINES 29.04, SIZE 100.00, CELL HEIGHT 23,
                 CELL WIDTH 7, AUTO-MINIMIZE, COLOR IS 65793,
                 CONTROL FONT Small-Font, ERASE, LABEL-OFFSET 0,
                 RESIZABLE, WITH SYSTEM MENU, TITLE WS-TITLE-DESC,
                 TITLE-BAR, USER-GRAY, USER-WHITE,
                 HANDLE IS Screen1-Handle

Now maybe its just me, but I don't see anywhere it mentioned the BIND TO THREAD.

So, I then also add set the LINK TO THREAD via acubench, and heres the same code.

       Acu-Screen1-Create-Win.
      *    Before-Create
      * display screen
              DISPLAY Independent GRAPHICAL WINDOW
                 LINES 29.04, SIZE 100.00, CELL HEIGHT 23,
                 CELL WIDTH 7, AUTO-MINIMIZE, COLOR IS 65793,
                 CONTROL FONT Small-Font, ERASE, LABEL-OFFSET 0,
                 LINK TO THREAD, RESIZABLE, WITH SYSTEM MENU,
                 TITLE WS-TITLE-DESC, TITLE-BAR, USER-GRAY, USER-WHITE,
                 HANDLE IS Screen1-Handle

the LINK TO THREAD is there.

I'm going to raise with tech support.

But i'd really appreciate you're thoughts on this please - if you can spare the time of course.

Thanks,

Shaun

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Hi Shaun,

As far as I know, LINK TO THREAD and BIND TO THREAD mean the same thing.

To use this option you code your program in such a way that each modeless window runs in a separate thread, and you use the phrase LINK TO THREAD or BIND TO THREAD when you create each window. This phrase instructs the runtime to handle the CMD-ACTIVATE events on its own. In this arrangement, when a CMD-ACTIVATE event occurs, the runtime suspends the current thread and activates the new window. The thread controlling the newly active window then resumes execution.

From "6.8.5 Threading Rules That Affect Windows and ACCEPT Statements" of the User Guide.

As far as STOP THREAD, STOP RUN and EXIT PROGRAM, we changed all of our STOP RUN statements with STOP THREAD. In the majority of cases we have EXIT PROGRAM followed by STOP THREAD. This helps when the program is run stand-alone. In the case of a hard programmed abort, we now just use STOP THREAD (which was previously STOP RUN).

We haven't really had any trouble with memory violations, so you might have to contact support about that one. I think they've got a document that you can work through to help find the cause.

Let me know if I can help some more :)

Ian

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Hi Shaun,

As far as I know, LINK TO THREAD and BIND TO THREAD mean the same thing.

To use this option you code your program in such a way that each modeless window runs in a separate thread, and you use the phrase LINK TO THREAD or BIND TO THREAD when you create each window. This phrase instructs the runtime to handle the CMD-ACTIVATE events on its own. In this arrangement, when a CMD-ACTIVATE event occurs, the runtime suspends the current thread and activates the new window. The thread controlling the newly active window then resumes execution.

From "6.8.5 Threading Rules That Affect Windows and ACCEPT Statements" of the User Guide.

As far as STOP THREAD, STOP RUN and EXIT PROGRAM, we changed all of our STOP RUN statements with STOP THREAD. In the majority of cases we have EXIT PROGRAM followed by STOP THREAD. This helps when the program is run stand-alone. In the case of a hard programmed abort, we now just use STOP THREAD (which was previously STOP RUN).

We haven't really had any trouble with memory violations, so you might have to contact support about that one. I think they've got a document that you can work through to help find the cause.

Let me know if I can help some more :)

Ian

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

I have certainly seen memory violations when a thread is left running when the program that started that thread terminates.

We use exit program for called programs in all instances - we stop the thread before the program that started the thread terminates - this stopped the memory violations.

There are still rare instances where the thread without focus somehow recevies the user input - am still investigating this and have no solution at present.

Keith

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

I have certainly seen memory violations when a thread is left running when the program that started that thread terminates.

We use exit program for called programs in all instances - we stop the thread before the program that started the thread terminates - this stopped the memory violations.

There are still rare instances where the thread without focus somehow recevies the user input - am still investigating this and have no solution at present.

Keith

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Thanks Kieth,

So, does that mean that you do a STOP THREAD and an EXIT PROGRAM afterwards?


Shaun

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Thanks Kieth,

So, does that mean that you do a STOP THREAD and an EXIT PROGRAM afterwards?


Shaun

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

Thanks Kieth,

So, does that mean that you do a STOP THREAD and an EXIT PROGRAM afterwards?


Shaun

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

No - I do a 'STOP THREAD HANDLE-THREAD' in the program that initiated the thread in the first place.

I keep a common data field that is set when the thread is initiated, and the program running in the thread unsets this prior to an EXIT PROGRAM, telling the initiating program to issue the stop the thread and destroy it.

[Migrated content. Thread originally posted on 14 September 2007]

I am trying to prove a concept to our customers and am having a tough time with the process. Can someone please create a very simple project that does the following and email it to me?

Create a screen with nothing but a menu, once the user selects an item from the menu a program/process is kicked off in its own window(thread) and is not tied to the main screen. The user would be able to select multiple things from the menu and none of them would be tied to each other.

I know this is possible and have seen some stuff on the forums about it before but I just can't put my mind around it right now.

Thanks for any help and I know you guys are way smarter than me and can help me out.

No - I do a 'STOP THREAD HANDLE-THREAD' in the program that initiated the thread in the first place.

I keep a common data field that is set when the thread is initiated, and the program running in the thread unsets this prior to an EXIT PROGRAM, telling the initiating program to issue the stop the thread and destroy it.