INKEY$ Transferproblem to PBWin

[Dieter Mayr]

Hello

I have, some time ago, written a Proram in PB-DOS to transfer programs from a NC-controlled machine and save them to disk.
I am working on transfering this program now to PBWin, i made some simple projects already in PBWin, but only as hobby and with limited time and knowledge.
The serial port communications i have finished already and they work well.
In my DOS-Program i have the communications routine running in a DO - LOOP loop with checking INKEY$ to Escape to be able to terminate the routine. All the timeouts of the COM-port are disabled so the program is waiting fas long as it receives data from the machine and thats why it is neccesary to be able to terminate the routine.
In my Win-Program i call my communication SUB from the CALLBACK of a dialog where i enter the data for the programs database and give these data as parameter to my SUB where the program from machine is received and stored to disk and the data is written to the database.
My problem is now:
How do i implement the termination routine in PBWin?
A simple MODAL-Dialog will block the loop waiting for transmission from machine, so i guess i would need something MODELESS, but i am not sure how to realise it.
I thought of having a new dialog with a Cancel-Button and a TextBox to have the status, like "Waiting for transmission", "Receiving" and "Transmission finished".
I think i just need a starting point how to realise it, some things in windows programming are not very clear to me.

Thanks for any sugestions and ideas.

Dieter

'edited because of typo

[Dave Biggs]

The PB COMM.BAS sample program uses a separate thread to capture data coming in from the comport.
The receive thread runs in the background and terminates when a flag is set from the main program.
Maybe you could use something similar?

[Michael Mattias]

In my DOS-Program i have the communications routine running in a DO - LOOP loop with checking INKEY$ to Escape to be able to terminate the routine. All the timeouts of the COM-port are disabled so the program is waiting fas long as it receives data from the machine and thats why it is neccesary to be able to terminate the routine

In a Windows program, you normally would not wait for a keystroke to terminate... you'd provide the user a "quit" or "abort" button to click.

(FWIW, <Escape> will result in WM_COMMAND/IDCANCEL notification message, so you don't even need the separate control if you don't want it).

That click will result in a notification message, on receipt of which you can 'do something.'

And this being your lucky day...

GUI + Worker Thread + Abort Demo

MCM

[Michael Mattias]

However... I belive the COMM calls are blocking calls... meaning you can't interrupt them once they start and you'll have to wait for the timeout.

[ADDED]

Hmmm, I wonder if this is that place I was looking for to use Asynchronous I-O... where you can issue a CancelIO () call.

I don't do nuthin' with serial communications, but it might be worth a test to see if you could set up the COMM I-O as asynchronous (overlapped) so you would have a point of entry where a CancelIO() could be used to escape the block.

????

[Cliff Nichols]

MCM,
your comment of

However... I belive the COMM calls are blocking calls... meaning you can't interrupt them once they start and you'll have to wait for the timeout.

If this is true, then I think you just inadvertently gave me a route to pursue with some of my bugs with my Serial Port communications

It sounds like Dieter is running into the basic problems that I 1st ran into, so I may be of some help if Dieter could clarify what CNC machine? or better yet code being used.

Dave Biggs comment about using the PB COMM.BAS sample program is DEFINITELY the 1st starting point.

[Dieter Mayr]

Thanks for your answers

Michaels example looks very interesting to me and i will try to understand it and use it in my application.

@Cliff
The machine is a Deckel FP4 with a Contour CNC, quiet old but still reliable.
I will post the code in the next days.

Thanks a lot for assistance so far

Dieter