Page 1 of 1

Bug in comm.c

Posted: Sat Dec 24, 2005 2:15 pm
by Enrico Maria Giordano
The following sample freezes with the latest FWH (it worked ok with a previous FWH release):

Code: Select all

#include "Fivewin.ch"


FUNCTION MAIN()

    LOCAL oDlg

    LOCAL oGet, cTxt := ""

    LOCAL nCom

    DEFINE DIALOG oDlg;
           SIZE 500, 500;
           TITLE "Terminal"

    @ 0, 0 GET oGet VAR cTxt MEMO

    oGet:bKeyDown = { | nKey | Tasti( nCom, nKey ) }
    oGet:bKeyChar = { | nKey | 0 }

    ACTIVATE DIALOG oDlg;
             ON INIT ( oGet:Move( 0, 0, 500, 500 ),;
                       nCom := APRICOM( oDlg, oGet ),;
                       IF( nCom < 0, oDlg:End(), ) );
             CENTER

    IF nCom >= 0; CLOSECOMM( nCom ); ENDIF

    RETURN NIL


STATIC FUNCTION TASTI( nCom, nKey )

    SENDSTR( nCom, CHR( nKey ) )

    RETURN NIL


STATIC FUNCTION APRICOM( oDlg, oGet )

    LOCAL nCom, cDcb

    BEGIN SEQUENCE
        nCom = OPENCOMM( "COM1", 16384, 16384 )

        IF nCom < 0
            ? "Errore di apertura della porta di comunicazione."
            BREAK
        ENDIF

        BUILDCOMMDCB( "COM1:115200,N,8,1", @cDcb )

        IF !SETCOMMSTATE( cDcb )
            ? "Errore di impostazione della porta di comunicazione."
            BREAK
        ENDIF

        oDlg:bCommNotify = { | nCom | Connect( nCom, oGet ),;
                                      EnableCommNotification( nCom, oDlg:hWnd, 1, -1 ) }

        IF !ENABLECOMMNOTIFICATION( nCom, oDlg:hWnd, 1, -1 )
            ? "Errore di abilitazione della notifica."
            BREAK
        ENDIF
    RECOVER
        nCom = -1
    END SEQUENCE

    RETURN nCom


STATIC FUNCTION CONNECT( nCom, oGet )

    ENABLECOMMNOTIFICATION( nCom, 0, 1, -1 )

    oGet:Append( RECEIVESTR( nCom ) )

    RETURN NIL


STATIC FUNCTION SENDSTR( nCom, cString )

    LOCAL nBytes := WRITECOMM( nCom, cString )

    RETURN nBytes = 0 .OR. nBytes = LEN( cString )


STATIC FUNCTION RECEIVESTR( nCom )

    LOCAL cBuf := SPACE( 1000 )

    RETURN LEFT( cBuf, READCOMM( nCom, @cBuf ) )
EMG

Posted: Sat Dec 24, 2005 5:17 pm
by Antonio Linares
Enrico,

FWH COMM functions are still buggy. They should not be used :(

Posted: Sat Dec 24, 2005 5:22 pm
by Enrico Maria Giordano
It maybe but it seems to be worst in the latest release. I can send you the latest working comm.c if you want.

EMG

Posted: Sat Dec 24, 2005 5:38 pm
by Antonio Linares
Enrico,

Yes, please email me the comm.c that was working for you. Thanks.

Posted: Sat Dec 24, 2005 5:51 pm
by Antonio Linares
Enrico,

Yes, please replace the actual comm.c with the previous one. We thought it was going to provide a better functionality, but no, things get worse.

I don't want to blame MS but I can't understand how they don't provide this functionality built-in as it was on 16 bits, same as there is no a DrawBitmap() for a GUI since the early days of Windows...

Thats why we were doing some research on mscomm32.ocx

Posted: Sat Dec 24, 2005 6:13 pm
by Enrico Maria Giordano
Antonio Linares wrote:Enrico,

Yes, please replace the actual comm.c with the previous one. We thought it was going to provide a better functionality, but no, things get worse.
I already done so. :-)
I don't want to blame MS but I can't understand how they don't provide this functionality built-in as it was on 16 bits, same as there is no a DrawBitmap() for a GUI since the early days of Windows...
I agree. The MS guy who designed the API layer did not make a good work for me.
Thats why we were doing some research on mscomm32.ocx
I would prefer the current APIs that don't need any additional component.

EMG

Posted: Sat Dec 24, 2005 7:18 pm
by Antonio Linares
Enrico,

> I would prefer the current APIs that don't need any additional component.

Me too.

Anyhow, lets work to properly implement COMM support for 32 bits.