Paul, at 14:24 on May 20 1995, you wrote to Bill Grimsley...

BG> In this example, half of the previous info still remains...

BG> Ú Transfer Status ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
BG> ³ Event 1 starts in 36 minutes  
BG> ³ YooHoo request event: S R     

BG> Only cosmetic, but I knew you'd want to know.

PE> I have had a look at the code, and no bug jumps to the fore.  I
PE> have never seen the problem here, but then I've never seen the
PE> "YooHoo request event" message either!  

You need to be watching the Status window during the first part of the
call, which most people wouldn't bother doing anyway.  I only do so just in
case the call fails to negotiate EC, as very occasionally happens.

PE> I'd prefer to just leave the cosmetic fixes out of BTPE anyway, as any time 
PE> spent reading Binkley code is wasted time, because I can't use the 
PE> knowledge 
PE> that I gain without restriction, unlike MSGED where the more I read the 
PE> code, the more I have a set of windowing functions that I can use etc etc. 

Fair enough.  I just thought it might be an easy fix, as it appears that
not enough string space is being allocated for the message.  You possibly
have it truncated to response size (null padded, is that the term?) when it
needs to have enough space allocated to clear the previous message if it's
longer (as it quite often is).  But then what would I know, I'm no
programmer.  

PE> The main reason I added "Aftercall" to Binkley was because
I thought it 
PE> would be personally useful to get the Spirit to tell me why it hung up.

Does Aftercall work for you as well as it does here then?

Regards, Bill
@EOT:

--- Msgedsq/2 3.10 alpha