Announcement

Collapse
No announcement yet.

INKEY$ Transferproblem to PBWin

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • INKEY$ Transferproblem to PBWin

    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
    Last edited by Dieter Mayr; 3 Dec 2007, 07:47 AM.

  • #2
    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?
    Rgds, Dave

    Comment


    • #3
      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
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        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.

        ????
        Last edited by Michael Mattias; 3 Dec 2007, 09:20 AM.
        Michael Mattias
        Tal Systems Inc. (retired)
        Racine WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          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.
          Engineer's Motto: If it aint broke take it apart and fix it

          "If at 1st you don't succeed... call it version 1.0"

          "Half of Programming is coding"....."The other 90% is DEBUGGING"

          "Document my code????" .... "WHYYY??? do you think they call it CODE? "

          Comment


          • #6
            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

            Comment

            Working...
            X