[archive] C$RUN - Cancel?

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

I use the "CreateProcessA" call to initiate the external exe program that I want to track. Then I monitor the status of that process by using the "GetExitCodeProcess" call. To terminate the process, I then call "FindWindowA" to get the handle of the process I want to terminate, and
call "EndTask" using that handle.

Create-Process.
move "CommServerJob" to Window-Title
inspect Window-Title replacing trailing space by null
set lpTitle to address of Window-Title
CALL "CreateProcessA"
using null,
by reference lpCommandLine,
null,
null,
value 0,
value dwCreationFlags,
null,
null,
by reference startupinfo,
by reference process-information
returning CALL-R-N


Terminate-Process.
CALL "FindWindowA" using
by reference null
by reference Window-Title
returning Return-Handle
CALL "EndTask" using
by value Return-Handle,
by value 0,
by value 0
returning call-r-n

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

I use the "CreateProcessA" call to initiate the external exe program that I want to track. Then I monitor the status of that process by using the "GetExitCodeProcess" call. To terminate the process, I then call "FindWindowA" to get the handle of the process I want to terminate, and
call "EndTask" using that handle.

Create-Process.
move "CommServerJob" to Window-Title
inspect Window-Title replacing trailing space by null
set lpTitle to address of Window-Title
CALL "CreateProcessA"
using null,
by reference lpCommandLine,
null,
null,
value 0,
value dwCreationFlags,
null,
null,
by reference startupinfo,
by reference process-information
returning CALL-R-N


Terminate-Process.
CALL "FindWindowA" using
by reference null
by reference Window-Title
returning Return-Handle
CALL "EndTask" using
by value Return-Handle,
by value 0,
by value 0
returning call-r-n

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

I use the "CreateProcessA" call to initiate the external exe program that I want to track. Then I monitor the status of that process by using the "GetExitCodeProcess" call. To terminate the process, I then call "FindWindowA" to get the handle of the process I want to terminate, and
call "EndTask" using that handle.

Create-Process.
move "CommServerJob" to Window-Title
inspect Window-Title replacing trailing space by null
set lpTitle to address of Window-Title
CALL "CreateProcessA"
using null,
by reference lpCommandLine,
null,
null,
value 0,
value dwCreationFlags,
null,
null,
by reference startupinfo,
by reference process-information
returning CALL-R-N


Terminate-Process.
CALL "FindWindowA" using
by reference null
by reference Window-Title
returning Return-Handle
CALL "EndTask" using
by value Return-Handle,
by value 0,
by value 0
returning call-r-n

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

Here is the code of the program that uses the create process call.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

Here is the code of the program that uses the create process call.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

Thanks for the program. I'm sure that will end up being quite helpful. I think I'm still having a disconnect though. When I call "createprocessa" or "findwindowa" I get abends because it can't find those programs.

I'm not sure what the following are used for and if they are required for those commands or not. I added them to my start up and it did not appear to make a difference.
SET ENVIRONMENT "DLL_CONVENTION" TO "1"
CALL "Kernel32.DLL".
CALL "USER32.DLL".

I think the process you have going is much harder to handle then what I'm looking for. I basically want to bring up an independant exe (an onscreen keybaord or keypad) that is to be closed when my application is stopped or if someone hits the button on the screen to stop it.

Again, right now, I am using a C$Run, which might not the best approach., but I need the on screen keyboard to work without locking my application so the the touchscreen entries can be pulled into my screen input controls.

Once I can figure out how to use the calls noted above, I should be able to play some with this but again, they just fail on not founds right now.

thanks for your help and quick responses, Mike

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

Thanks for the program. I'm sure that will end up being quite helpful. I think I'm still having a disconnect though. When I call "createprocessa" or "findwindowa" I get abends because it can't find those programs.

I'm not sure what the following are used for and if they are required for those commands or not. I added them to my start up and it did not appear to make a difference.
SET ENVIRONMENT "DLL_CONVENTION" TO "1"
CALL "Kernel32.DLL".
CALL "USER32.DLL".

I think the process you have going is much harder to handle then what I'm looking for. I basically want to bring up an independant exe (an onscreen keybaord or keypad) that is to be closed when my application is stopped or if someone hits the button on the screen to stop it.

Again, right now, I am using a C$Run, which might not the best approach., but I need the on screen keyboard to work without locking my application so the the touchscreen entries can be pulled into my screen input controls.

Once I can figure out how to use the calls noted above, I should be able to play some with this but again, they just fail on not founds right now.

thanks for your help and quick responses, Mike

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

A new problem, when I run from our application and not from Acubench directly, I can't call user32 or kernel DLLs...

I get program missing or inaccessable on both.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

A new problem, when I run from our application and not from Acubench directly, I can't call user32 or kernel DLLs...

I get program missing or inaccessable on both.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

A new problem, when I run from our application and not from Acubench directly, I can't call user32 or kernel DLLs...

I get program missing or inaccessable on both.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

Interesting, I have not run into that problem. I would suspect that it would be a pathing issue of some sort. Kernel32.dll and User32.dll are a standard part of windows and should be in the path. This is where the code for the CreateProcessA and FindWindowA are found. I have only run the commserver application on windows 2000 and windows Xp so far with no problems. I'm not sure what Windows version you are running or if that would even be the issue here.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

Interesting, I have not run into that problem. I would suspect that it would be a pathing issue of some sort. Kernel32.dll and User32.dll are a standard part of windows and should be in the path. This is where the code for the CreateProcessA and FindWindowA are found. I have only run the commserver application on windows 2000 and windows Xp so far with no problems. I'm not sure what Windows version you are running or if that would even be the issue here.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

I am doing some digging on this. Someone in my office suggested I look for a config option that handles "case" of the call commands. I am stuggling to find anything. I am also reviewing the @display and @winapi call usage to see if that helps. We are using thin client but the application resides on a unix box. So far, I have not had any luck which tells me it's most likely a case issue.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

I am doing some digging on this. Someone in my office suggested I look for a config option that handles "case" of the call commands. I am stuggling to find anything. I am also reviewing the @display and @winapi call usage to see if that helps. We are using thin client but the application resides on a unix box. So far, I have not had any luck which tells me it's most likely a case issue.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

The problems you are experiencing is due to the use of CODE-PREFIX. Acubench uses CODE-PREFIX, when this is in use, the standard system path (which include the directory of where the Windows system DLLs reside) are not used.

There are three solutions to this: You may either use the full path in your CALL statement, like: CALL "C:\\WINDOWS\\SYSTEM32\\KERNEL32.DLL". This has the disadvantage though, that although not common, it does happen that Windows is installed elsewhere.

The other solution is to add C:\\WINDOWS\\SYSTEM32 to the CODE-PREFIX, in which case I assume you set CODE-PREFIX in a configuration file, so it would be easy to modify to fit local variants. This of course also applies to using an alias in the config file for the full path file name.

Finally, you may upgrade to a more recent version. This issue has namely been addressed, I am not sure in what version we introduced this, but at least as of 7.0.0, there is a new configuration variable USE-SYSTEM-DIR.
This variable is default TRUE and regardless of what you set CODE-PREFIX to, if this is TRUE, the current Windows system directory will be searched for DLLs, if not found on the CODE-PREFIX path.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

The problems you are experiencing is due to the use of CODE-PREFIX. Acubench uses CODE-PREFIX, when this is in use, the standard system path (which include the directory of where the Windows system DLLs reside) are not used.

There are three solutions to this: You may either use the full path in your CALL statement, like: CALL "C:\\WINDOWS\\SYSTEM32\\KERNEL32.DLL". This has the disadvantage though, that although not common, it does happen that Windows is installed elsewhere.

The other solution is to add C:\\WINDOWS\\SYSTEM32 to the CODE-PREFIX, in which case I assume you set CODE-PREFIX in a configuration file, so it would be easy to modify to fit local variants. This of course also applies to using an alias in the config file for the full path file name.

Finally, you may upgrade to a more recent version. This issue has namely been addressed, I am not sure in what version we introduced this, but at least as of 7.0.0, there is a new configuration variable USE-SYSTEM-DIR.
This variable is default TRUE and regardless of what you set CODE-PREFIX to, if this is TRUE, the current Windows system directory will be searched for DLLs, if not found on the CODE-PREFIX path.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

The problems you are experiencing is due to the use of CODE-PREFIX. Acubench uses CODE-PREFIX, when this is in use, the standard system path (which include the directory of where the Windows system DLLs reside) are not used.

There are three solutions to this: You may either use the full path in your CALL statement, like: CALL "C:\\WINDOWS\\SYSTEM32\\KERNEL32.DLL". This has the disadvantage though, that although not common, it does happen that Windows is installed elsewhere.

The other solution is to add C:\\WINDOWS\\SYSTEM32 to the CODE-PREFIX, in which case I assume you set CODE-PREFIX in a configuration file, so it would be easy to modify to fit local variants. This of course also applies to using an alias in the config file for the full path file name.

Finally, you may upgrade to a more recent version. This issue has namely been addressed, I am not sure in what version we introduced this, but at least as of 7.0.0, there is a new configuration variable USE-SYSTEM-DIR.
This variable is default TRUE and regardless of what you set CODE-PREFIX to, if this is TRUE, the current Windows system directory will be searched for DLLs, if not found on the CODE-PREFIX path.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

I do think this is the issue I'm having, though I need a bit more direction.

First we are on 6.2 for development, using either the 6.2 or 7.0 run time (both react the same). The cllient in this case will be Windows, but our application resides on Unix. So my question is how can I fix the code-prefix when it's set up for unix pathing?

CODE_PREFIX .:/s/ssi102/ssiobj;/s/...

Is there a thin-client prefix, maybe tc_CODE_PREFIX or THIN_CODE_PREFIX? I could not find anything about a thin client version of this variable in the manuals.

I did use the fully qualified path, as follows with success, but I think this is temporary fix unless I can't fix the pathing issues.

CALL "@[DISPLAY]:c:\\windows\\system32\\KERNEL32.DLL@WINAPI".
CALL "@[DISPLAY]:c:\\windows\\system32\\user32.dll@winapi".

Another question is if I code the fully qualified path, do I cancel with the fully qualified path as well or does doing a cancel of kernel32.dll and user32.dll work?

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

I do think this is the issue I'm having, though I need a bit more direction.

First we are on 6.2 for development, using either the 6.2 or 7.0 run time (both react the same). The cllient in this case will be Windows, but our application resides on Unix. So my question is how can I fix the code-prefix when it's set up for unix pathing?

CODE_PREFIX .:/s/ssi102/ssiobj;/s/...

Is there a thin-client prefix, maybe tc_CODE_PREFIX or THIN_CODE_PREFIX? I could not find anything about a thin client version of this variable in the manuals.

I did use the fully qualified path, as follows with success, but I think this is temporary fix unless I can't fix the pathing issues.

CALL "@[DISPLAY]:c:\\windows\\system32\\KERNEL32.DLL@WINAPI".
CALL "@[DISPLAY]:c:\\windows\\system32\\user32.dll@winapi".

Another question is if I code the fully qualified path, do I cancel with the fully qualified path as well or does doing a cancel of kernel32.dll and user32.dll work?

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

Just an FYI, I did figure out a way to remove the full pathing, but it's still not a preffered method, though better than coding the full path.

In windows, right click my computer, go to properties, advanced tab, then environment variables. Make sure that %SystemRoot%\\system32 (in this case c:\\windows\\system32) is in PATH variable.

In addition, we have found that we need CODE_CASE to be 0 (or not in the cobol config) or we have issues with our calls to the methods.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

Just an FYI, I did figure out a way to remove the full pathing, but it's still not a preffered method, though better than coding the full path.

In windows, right click my computer, go to properties, advanced tab, then environment variables. Make sure that %SystemRoot%\\system32 (in this case c:\\windows\\system32) is in PATH variable.

In addition, we have found that we need CODE_CASE to be 0 (or not in the cobol config) or we have issues with our calls to the methods.

[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

There is no particular code prefix for the thin client.
You may alter your code prefix when calling DLLs, like:
*Save
ACCEPT WsCurrentCodePrefix FROM ENVIRONMENT.
*Change
SET ENVIRONMENT "CODE-PREFIX" TO "blabla".
*Do what you got to do
CALL "Mydllsgoeshere"....
*Restore
SET ENVIRONMENT "CODE-PREFIX" TO WsCurrentCodePrefix.

As for the CANCEL, you must cancel the same way to CALL. E.g. the path is required. Which is another reason you should probably want to use an alias. E.g. in your code:
CALL "Kernel32.dll"
In the config file:

Kernel32.dll @[DISPLAY]:c:\\windows\\system32\\kernel32.dll@winapi


[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

There is no particular code prefix for the thin client.
You may alter your code prefix when calling DLLs, like:
*Save
ACCEPT WsCurrentCodePrefix FROM ENVIRONMENT.
*Change
SET ENVIRONMENT "CODE-PREFIX" TO "blabla".
*Do what you got to do
CALL "Mydllsgoeshere"....
*Restore
SET ENVIRONMENT "CODE-PREFIX" TO WsCurrentCodePrefix.

As for the CANCEL, you must cancel the same way to CALL. E.g. the path is required. Which is another reason you should probably want to use an alias. E.g. in your code:
CALL "Kernel32.dll"
In the config file:

Kernel32.dll @[DISPLAY]:c:\\windows\\system32\\kernel32.dll@winapi


[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

There is no particular code prefix for the thin client.
You may alter your code prefix when calling DLLs, like:
*Save
ACCEPT WsCurrentCodePrefix FROM ENVIRONMENT.
*Change
SET ENVIRONMENT "CODE-PREFIX" TO "blabla".
*Do what you got to do
CALL "Mydllsgoeshere"....
*Restore
SET ENVIRONMENT "CODE-PREFIX" TO WsCurrentCodePrefix.

As for the CANCEL, you must cancel the same way to CALL. E.g. the path is required. Which is another reason you should probably want to use an alias. E.g. in your code:
CALL "Kernel32.dll"
In the config file:

Kernel32.dll @[DISPLAY]:c:\\windows\\system32\\kernel32.dll@winapi


[Migrated content. Thread originally posted on 24 October 2007]

We are starting non-acu applications using the C$RUN using "appl.exe -options". I would like to use the same control in my acu program to close the application as I did to start it. However, my attempts to destroy the thread and cancel C$RUN have not worked.

If anyone has any ideas, I would appreciate it. If you need more details, I can provide it.

thanks, Mike :confused:

I like the idea of using an alias for all our common windows dll calls. Thanks!

Has anyone used the mountfocus on screen keyboard via a com call? http://www.virtual-keyboard.com/index.html

We are doing touch screen coding and the issue I am having is being able to start a keyboard in a manner than I can use a button on my page to close that keyboard when hit. I have it working using an ASYNC call of C$SYSTEM to start the .exe with my .kbd file but am not having any luck making the COM call. I did generate a .def file using axdefgen.exe, but it does not seem to work right, though the .def looks great. I have been emailing the support at mountfocus, but they do not know how to work with Acu. I have attached the .def file.

One of the big issues I'm having is calling the DLL. I don't want to move it from the istallation location, but when I try to call
call "@[DISPLAY]:C:\\Program Files\\MountFocus\\Keyboard\\Kbd.dll"

Program Files is changed to ProgramFiles in the message stating the dll can't be found.

Just to see if it helps, my contact at mountfocus noted the following things:

1) "Regarding AcuCobol I took a look at their website, and according to the specifications you should be able to control a COM object from an AcuCobol program. The name of the Runtime Keyboard COM server is ?Kbd.mfSoftkeys? (without the quotes)." I am not sure how I can call or start a com server.

2) When I tried going directly to the dll, I got this response... "The Kbd.dll is an ActiveX, but please note that it is only a proxy for the actual COM server (out of process) that is implemented in Kbd.exe. So, Kbd.exe is needed for Kbd.dll to work ? but not the other way around. In most cases I recommend instantiating the COM server directly without using the ActiveX proxy." I have asked for sample C or VB code that makes this call, but I do not have it yet.

Thanks to everyone for the help so far. I have a partial solution, I'm just hoping to find a better way to control the start and stop of this external keyboard.