PE>>> Now after every 1k or whatever, the Zmodem routine needs to end so

 PE>>> that you can both transmit the data and update the display.
 Then you

 PE>>> need to start again. But to restart, what you REALLY want, is a goto

 PE>>> that takes you smack bang into the middle of the loop that you were

 PE>>> just in the middle of before you were forced to exit to inform the

 PE>>> caller.  It would have been nicer if you could just inform
the caller

 PE>>> without having to exit.



 PM>> You could pass the Zmodem code the address of a function to call every

 PM>> time it need to update the status. Similar to the approach taken with

 PM>> qsort().



 PE> Which is what everyone else does, but it still boils down to Zmodem doing

 PE> the checking of the keyboard, updating the screen.  All it has done is

 PE> isolate the checking bit into a user-supplied function.  Still no good

 PE> for a client-server, or OS2PM type environment.



Since the function is user supplied, it can do any thing you want. This
could be updating an OS/2 PM window or communicating with another machine.



 PM>> The function could return a non zero value if you want to terminate the

 PM>> transfer. Using this method means that the zmodem loop would not end

 PM>> every block and you wouldn't have to jump into the middle of it.



 PE> There is no doubt that it can be done that way, I just don't think that

 PE> that's the proper way of doing it, and I am looking for alternatives. I

 PE> think Zmodem should just return when it's got nothing to do, and let the

 PE> caller decide whether to constantly poll the comms and keyboard, or

 PE> return to Windows, or return from the mainframe to the PC, or whatever,

 PE> rather than getting Zmodem to call some complex scheduling thing.  What

 PE> do you think?  BFN.



Well, for a start, you shouldn't be constantly polling anything. All the
user supplied function should be doing is to updated the display and
checking if the transfer needs to be aborted



What's really going to decide the issue is where the Zmodem routine gets
it's data from. If you have a routine that calls it with some data to
transmit, then the Zmodem routine will need to return after processing the
data. Therefore, the calling routine should probably be the one controlling
the display etc.





Paul



--- GoldED/2 2.42.G1114