Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Windows Telephony Warning

Status
Not open for further replies.

MollyMoon

Programmer
Mar 3, 2003
18
0
0
US
We frequently get the following Windows Telephony Warning:
"The requested connection is in use by another application. ProComm Plus is unable to use this connection."

The modem ProComm is attempting to use is NOT in use at the time. I'm trying to find out what error is returned to ProComm when this occurs so that I can look for it in my script and take action accordingly.

Any help would be greatly appreciated!


 
Hello,

Go to Click on Example Scripts. Go down to the 12th Sample. This deals with the TAPI Modem Connection. Maybe this will get you started.

hank camphm@bellsouth.net
 
I guess I didn't describe the problem correctly. The modem is not in use, but ProComm thinks it is. I was thinking this might be a known bug in ProComm, but it is more likely a modem issue.

Thanks anyway!
 
If Procomm cannot access the modem for some reason (another application has it, previous program didn't close the modem correctly, and so forth), then this error message will be displayed. I've received this at home at times when I've made a dialup networking connection, disconnected, and tried to use the modem in Procomm, but DUN had not fully released the modem for some reason. You might try updating your modem drivers and flashing new firmware (if your modem supports that) to see if that clears up the situation.
aspect@aspectscripting.com
 
Thanks knob. I will definitely update the modem drivers.

In my case, the previous program to have accessed the modem would would be ProComm itself. Our app launches multiple instances of ProComm, waiting for a free modem before launching another ProComm and running the script. When this problem occurs (it happens every night at some point before our app has completed its entire process), there appears to be a certain amount of time after which the modem is freed again on its own. We have not been able to pin down that exact time period, unfortunately. Hopefully new drivers will help.

 
Are you closing Procomm and reopening it at any time during this process? I saw some behavior in version 4.7 years ago where you would access the modem, close Procomm, but the globe icon in the system tray would not go away. When this happened, modem communication was problematic. I have not done much modem operations with Procomm since then, so I don't know if version 4.8 is any better-behaved or not.
aspect@aspectscripting.com
 
As a matter of fact ProComm is opened and closed repeatedly, and I have seen the behavior you mention with the globe icons in the system tray not going away. In fact this seems to happen quite frequently. They disappear if you move the mouse over them.

The script being run closes ProComm as follows:

Disconnect
PWExit

Should I be using another method to close ProComm?
 
That is the correct way to do it. Symantec recommends that you put a pause 15 before the pwexit command. I don't know if that will make a difference, but you can give that a try.
aspect@aspectscripting.com
 
I will add the pause 15 as you recommend.

Do you know what error is returned by ProComm under this circumstance? I'm assuming I can trap it with $CNCTMSG...

Have there been any updates to v4.8?

Thanks much for all your help.
 
I do not know if Procomm returns an error message that can be accessed via a script in this instance. I would think $CNCTMSG would not have it since Procomm would be unable to even dial.

The only update to version 4.8 that I am aware of is a new FAPI32.DLL. I don't know if this will fix the problem, but you can read more about what it does fix here:

aspect@aspectscripting.com
 
I had a similar problem with a script I created with Procomm Plus 2.X (back when Procomm did not use TAPI). At the beginning of the script, I was using a user window to paint the screen. When I migrated this script to Procomm Plus 4.X, I start experiencing this promblem.

If I had a TAPI session open to an existing modem, and then ran my script, my script decided it wanted to use a new TAPI session, and I would completely lose access to my open TAPI session. The modem would remain connected but I could not access it at all. Disconnecting the line would drop the connection but still would not release the TAPI session. Even closing all sessions of Procomm and all associated tasks wouldn't clear the TAPI connection. The only way I found to retrieve that TAPI session was the completely restart Windows.

Unfortunately, I never really found a proper fix. My work-around was to remove the User Window at the beginning of my script and then my script would use the existing TAPI session and not create a new one.
 
It's interesting that you had to restart Windows.

We've found that the problem does clear itself up eventually. There seems to be some amount of time (we have been unable to pinpoint a specific length) whereby if we tell our app not to use that modem, then reinstate it a while later, the Telephony Warning will resolve itself... presumably because the TAPI session associated with that particular modem has been cleared by whatever.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top