• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 325
  • Last Modified:

Extra modems for AWMODEM.INI?

Anybody know of any source of updated AWMODEM.INI to use with APRO?  The one TurboPower supply doesn't seem to have been updated since 1997 or so...  There must be a better way than typing them all in manually.  Please don't tell me to use TAPI - it's so unstable I've given up for now - may revisit it later when the pressure's off a bit!

Rob
0
robnorthcott
Asked:
robnorthcott
  • 4
  • 3
1 Solution
 
LoneACommented:
Hi robnorthcott

The reason why it hasn't been updated for so long is because it is easyer and more reliable to use TAPI.

In the beginning, the TAPI-components delivered by TP WHERE unstable - i agree on that. But this isn't a problem anymore - I use the RAS-dialer from the Async. Pro. 3.04-package - and it work fine on ALL Windows-versions - INCLUDING Xp !

So if you still want to use the AWMODEM.INI-aproach, I'm afraid there IS no other way, than typing in the new modem-types.

/LoneA



0
 
robnorthcottAuthor Commented:
I'm using APRO 3.06.  Using TAPI, my application was so unstable I almost gave up completely (random access violations and other errors part way through zmodem transfers were the worst problems).  After discussing the problems with people on this site (mainly Jeff Duncan - thanks Jeff), I scrapped TAPI and used the "old" TApdModem component, and the app now runs MUCH more reliably.  It still gives errors on shutdown, but that seems to be a known APRO bug that they are looking into (but the published fix seems to be for version 4).  There's no way I'm going to upgrade just on the off chance that it may work better, so I'm sticking with the old way for now.  I plan to try TAPI again sometime (although probably not with APRO - these experiences have put me right off the package even though it was recommended by various people), but for now I just haven't got the time to waste.  It seems that simple things always work (make a connection, send a file, drop the line) but then the components become more and more unstable the more you do.  I admit I'm not the most experienced comms programmer, but that's why I bought APRO in the first place - it was supposed to deal with the technical comms stuff and let me get on with the rest of the application.  If I'm doing something wrong I'd be glad to take advice, but it seems it isn't just me getting these problems.  I will certainly never agree to develop another application involving modem communication, and am seriously considering giving up programming altogether after over ten years in the job.  Thanks TurboPower!

Sorry about the rant folks (tried to keep it as polite as possible!), but unless I can get this stuff working in the next four days I'm stuffed, and all over a stupid modem link.

Rob
0
 
LoneACommented:
Hi Robnorthcott

Sorry to hear that - I've been working with TP-components - specially Async. Pro for about 6 or 7 years now, and I don't agree with you at all. Sorry to say it - but EVEN though you need a component for dealing with the communications, you need to to have some knowledge about what's happening. Most problems with communcations are TIMING-problems - and I guess most off those you have experienced are this kind off problems.

I've used TP-components i different applications (mainly home banking applications) and they ARE stable.

"It still gives errors on shutdown" - well I have an "old" application, using Zmodem and "the old" modem-component. Shut down is done like this:

This is implemented on my "Close"-button.

  IF ZmodemProtokol.InProgress THEN
  BEGIN
    ZmodemProtokol.Cancelprotocol;
  END;

  IF APRO_Carrier  THEN
  BEGIN
    try
      MyModem.HangUp;
      MyModem.WaitOnResponse;
    except
      on EModemBusy do ... som errorhandling;
      on EBadHandle do ;
    end;
  END;

On normal Zmodem-termination i don't use the "IF ZmodemProtokol.InProgress THEN"-part.

The APRO_Carrier-function is a locale function:

FUNCTION APRO_Carrier : BOOLEAN;
BEGIN
  IF MyComport <> Nil THEN
  BEGIN
    IF MyComport.Open THEN
      Result := MyComport.DCD
    ELSE
      Result := FALSE;
  END
  ELSE
    Result := FALSE;
END;


And this is implemented on my formclose:

  IF Assigned(MyComport) THEN
  BEGIN
    MyComport.Open := FALSE;
    MyComport.Free;
  END;
  IF Assigned(MyModem) THEN
    MyModem.Free;

AND remember to RESET triggers, if you use any ! The main-reason why you get trouble with access violations etc. on shut down, is because events are fired AFTER you closed your components. You need to give WINDOWS the time to close down at to clear all communications buffers before you free your components and the window they are on.

I hope this help you ...

/LoneA
 
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
robnorthcottAuthor Commented:
Thanks LoneA - as I said, I'm the first to admit my limited experience in this area.  Timing is definitely a problem, because I had to put long delays in the code using the DelayTicks function to cure some of my initial problems (it seems that modems are very unstable for a few seconds after changing state?).  Anyway, thanks for the suggestions - I'll give that a try and get back to you.

I apologise again for the rant...  it's just that I've wasted so much time over this in the last few months.

Rob
0
 
LoneACommented:
Hi robnorthcott

Thats okay - we all get frustrated sometimes.

I wanted to comment on your problem on :
"It seems that modems are very unstable for a few seconds after changing state"

Well - not in general !

If you experience this, their might be a configuration-problem between the modem you call from and the receiver modem. They need to agree on the protocols they use (V42 bis. K52flex or not etc.), speed and so on. To solve this kind of stability-problems you need to read the manual for your own modem and you need to know how the recieving modem is configured. Using the AT-commands, you can try to deactivate compression and error-correction (V42 and V42bis), change the speed between the modems and so on.

Another reason why modems sometimes are unstable are problems with the quality of the external telephone-line...  

There can also be a problem on internal phonelines - there can be noise on the line, if you have many phones, fax-mashines etc. on the same phoneline.

Switchboard can also cause problem with noise and can disconnect lines etc. If this is a problem, you need a data-secure-line for your modemcommunication.

/LoneA
 
0
 
robnorthcottAuthor Commented:
I didn't mean "unstable" as "dropping line".  It just seems that you have to pause for a few seconds between receiving the "OnConnect" event and starting a protocol transfer, for example.  Or between "OnProtocolFinish" and dropping the line.  If I don't put these pauses in, I get all sorts of horrible errors.  It's all timing problems, as you said.  I'll try your suggestions for shutdown now - if I can get the app to shut down without giving errors, I'll be reasonably happy :-)

Rob
0
 
robnorthcottAuthor Commented:
LoneA,

I tried your suggestions and my app now closes without errors :-)  Yippee....

It actually seems pretty stable altogether now, so I'll stick with it how it is until the panic is over, then maybe get back to trying TAPI again.  Hopefully with what I have learnt doing this I should be able to get TAPI to behave itself next time.

Anyway, thanks for your help - I'll accept the answer to my original question ("no updates to AWMODEM available"), but it was the shutdown stuff that actually helped me most.  I'll even increase the points - this has really helped me out!  Thanks again.

Rob
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now