Page 1 of 1
Sendnetworkfile, Receivenetworkfile
Posted: Mon Mar 27, 2006 7:51 pm
by Ninja
How about adding an optional prameter, with a pointer to a function that is called by sendnetworkfile and receivenetworkfile with 1 parameter, that contains the current download state? Would help much, when sending big files.
Posted: Wed May 03, 2006 11:40 am
by Anden
Good idea. Has been requested lots of times (and ignored as often)
Don't use those commands anyway, they are (still) buggy.
But i have to admit, that these bugs are very hard to track down.
I have a file here (~ 3 MB) which can be received by all clients but one. On that machine, ReceiveNetworkfile() "hangs" after receiving app. 200 kB. Smaller files are no problem. Very strange ...
I don't know how these commands work internally, so i dont't have a clue what's wrong. Thus i can't help fixing the problem ...
Posted: Wed May 03, 2006 1:47 pm
by Bonne_den_kule
I want it too...
Posted: Wed May 03, 2006 3:38 pm
by Nik
As one will always need some expertise to write good networked applications, one should be able to do this easily without the help of a standard command.
Posted: Thu May 04, 2006 6:14 am
by Anden
Well, if everybody is always reinventing the wheel again and again, we would still be fiddling around with our macro-assemblers.
Coding stuff like: Output text (fast) and trying to optimize stack positions ...
(which was quite funny, though
)
Posted: Thu May 04, 2006 12:09 pm
by Nik
It's deffinitley not like reinventing the weel and it would be a good idea if there were any common way on transfering files since there isn't it would only help to do soem quick dirty tools without a lot of use. there just are different protocolls for filetransfer and you will need to choose one of them, if you use ftp fine you can take the standard winapi functions else reproduce the protocoll that's just what networking is about...
Posted: Fri May 05, 2006 6:04 am
by Anden
Well, here are the facts:
1) SendNetworkfile() and ReceiveNetworkfile() already exist. Though they are not perfect (no progress indicator, problems with packet retransmissions)
2) Fred already had to choose a protocol for (1), we just don't know what it is
3) Thus coding the same functionality as in (1) again is definitely inventing the wheel the second time, sorry.
4) (1) is the common way in PB, as is OpenWindow() for opening, hurrah, a window ...