The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
VB6 programming issue -- 2 instances of same program conflicting
Nerissa
Registered User regular
Registered User regular
Before anyone starts... not using VB, or using .NET is not an option here. It has to be VB6. This is for work, and VB6 is what they have.
Every application mentioned runs unattended, and must be able to recover from errors without user intervention. Some of them run 24 / 7, and I don't want to be the one tapped to wake up every hour and check to make sure they are running. :P
I have an OCX file that I wrote, which contains about 5 custom controls and about 5 other classes that are not actually controls. It is used in a multitude of projects. One of those classes wraps the interaction with an external terminal emulator (Attachmate Extra!). It connects, sends commands, retrieves the responses, etc.
On at least one machine, I have 3 separate applications running all day, all using this class to connect to separate terminal instances. They are working fine.
On another machine, I am trying to run 2 instances of a 4th application, each connecting to a separate terminal instance. As long as I am running either instance by itself, it's running fine. When I try to run two instances, one of them occasionally gets an "Automation Error" which is untrappable, and pops up a message needing to be clicked away before it can continue.
Both the machine that is running 3 different applications and the one that is trying to run 2 instances of the same application are Win2k Pro.
The way I understand it is that if I include a class in a library, each instance of the program has it's own object of that class, and it probably shouldn't be a thread issue... but I'm out of other ideas.
They way they are (normally) set up, there is a single copy of the .exe with two .ini files -- the program takes the name of the .ini file as a command-line parameter, which it then uses to know which terminal session to connect to and initializes its object based on the info it reads from that file. I tried making a copy of the directory and running the two instances off separate copies of the .exe in separate directories, but from looking at the logs over the weekend, that doesn't seem to have solved my problem.
Anyone have any ideas?
Every application mentioned runs unattended, and must be able to recover from errors without user intervention. Some of them run 24 / 7, and I don't want to be the one tapped to wake up every hour and check to make sure they are running. :P
I have an OCX file that I wrote, which contains about 5 custom controls and about 5 other classes that are not actually controls. It is used in a multitude of projects. One of those classes wraps the interaction with an external terminal emulator (Attachmate Extra!). It connects, sends commands, retrieves the responses, etc.
On at least one machine, I have 3 separate applications running all day, all using this class to connect to separate terminal instances. They are working fine.
On another machine, I am trying to run 2 instances of a 4th application, each connecting to a separate terminal instance. As long as I am running either instance by itself, it's running fine. When I try to run two instances, one of them occasionally gets an "Automation Error" which is untrappable, and pops up a message needing to be clicked away before it can continue.
Both the machine that is running 3 different applications and the one that is trying to run 2 instances of the same application are Win2k Pro.
The way I understand it is that if I include a class in a library, each instance of the program has it's own object of that class, and it probably shouldn't be a thread issue... but I'm out of other ideas.
They way they are (normally) set up, there is a single copy of the .exe with two .ini files -- the program takes the name of the .ini file as a command-line parameter, which it then uses to know which terminal session to connect to and initializes its object based on the info it reads from that file. I tried making a copy of the directory and running the two instances off separate copies of the .exe in separate directories, but from looking at the logs over the weekend, that doesn't seem to have solved my problem.
Anyone have any ideas?
Nerissa on
0