OPEN COM problems with LOC

[Antoni]

Is LOC extended to return the nr of bytes waiting in the receive buffer, as in QB?. LOC was very handy to retrieve variable length binary data:

Code: Select all

dim c as string,t as integer
c=""
while loc(1)
  c+=input(1,loc(1))
sleep 0
wend
print c

It seems it does'nt work in FB.

EDITED: I once added that feature of LOC to the wiki, and it looks like I was wrong...

[hippy]

It used to work for me. LOC(filenumber) gave the number of chars received.

[Antoni]

I rechecked, you are right, it's INPUT(#f,n) what does not work!

EDITED:
Forget it, I'm stupid...Just a case of RTM.

EDITED AGAIN:
Something is wrong with INPUT and OPEN DEVICE. Filed a bug report to SF...

INPUT(F,N) problems with OPEN DEVICE
The code below works. When a letter is pressed it's
added to the end of "hello" and the string is printed.
When INPUT reads from a file it seem to work too.

Code: Select all

dim c as wstring*10
c="hello"
c=c+input(1)
print c
close
sleep

The code belowdoes not work. INPUT expects a carry
return to end, and strange characters are added to the
end of the string.

Code: Select all

open cons for input as #1
dim c as wstring*10
c="hello"
c=c+input(1,1)
print c
close
sleep

It fails too with OPEN COM, it keeps waiting for a CR
that never comes so it blocks the comms.

[BrianG]

In this case, shouldn't it be 'input$' instead of 'input'? I think this is the one of the few times where the $ tells the compiler how to treat the command.

I personally had success with the com using:

Code: Select all

......
dim as ubyte incombyte
OPEN COM "COM1:19200,N,8,1,CS,DS,BIN,DT" AS 1
.....
if LOC(1) then get #1, ,incombyte
......

Though I believe that the incomebyte can also be dimmed as a string.