Just for the record: It was a server side problem. The server required
connection: keep alive in the http headers to fully download the pdf file.
Thanks for the help though.
All the best,
Malte___
use-revolution mailing list
use-revolution@lists.runre
Ok,
I don´t get it. It does not seem a general problem, which makes it
even stranger. At least I know now it does not have to do with the 4.0
engine. Also happens with a 3.5 standalone.
The scenario is as follows. rev client communicates with a server. It
fails most of the time on one XP
Malte, I think there may be a few minor changes in the version shipping with
Rev 4. (But nothing that obviously changes previous working.)
In your code, I'd suggest you split the following line:
> put URL tPath into URL ("binFile:"& tTempPath)
into two parts, and add error checking after each p
Malte,
do you still have the dps of version 4? Try building with dp-3 or dp-4 but
not with gm-1 see if it goes away...
Cheers
andre
On Tue, Dec 8, 2009 at 1:18 PM, Malte Pfaff-Brill wrote:
> I think something is fishy with libURL in Rev 4. Some script that used to
> work in previous versions no
I think something is fishy with libURL in Rev 4. Some script that used
to work in previous versions now breaks with the current engine.
local tPath, tTempPath
put getServerUrl()&"test.pdf" into tPath
put the tempname & ".pdf" into tTempPath
libURLSetStatusCallback "dataupdate",the l
Andre.
It wasn't me. I just butted in.
Craig
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revoluti
Craig,
put should be blocking, actually, I know it is blocking! I've been blocked
by it many times. I don't know why you're experiencing that behaviour at all
but I am trying to work around it. I don't know how familiar you are with
liburl callbacks. You can basically tell it to execute a command
In a message dated 12/7/09 1:54:15 PM, an...@andregarzia.com writes:
Andre.
I am always trying to change my habits, to use "send in time" instead of
wait. But here I intended it to be used well before the handler actually does
anything, likely right after the "case" statement. A simple block o
Craig,
never use a wait call while there's a network transaction going on. LibURL
does not like wait commands.
Andre
On Mon, Dec 7, 2009 at 4:47 PM, wrote:
> I am a newbie here, but would inserting a "wait for messages" prevent the
> errant keypress?
>
> But is that slightly different than wha
I am a newbie here, but would inserting a "wait for messages" prevent the
errant keypress?
But is that slightly different than what you really want, which is to
ignore double keypresses? In HC I would have said:
...
wait 15
if the mouseClick then exit yourHandler
...
This works in rev, too.
C
Dan,
this is me guessing here, but why don't you use a script local variable like
local lRunning
on doSave
if lRunning is true then
send "doSave" to me in 200 millisecs
end if
put true into lRunning
put "ftp://admin:passw...@123.456.789.012/UploadTest.txt"; into ftpPath
--use a valid path
Hiya...
Isn't the "put" command blocking? I find that if I call a 'put' to write to a
server twice in fast succession, the second 'put' is handled BEFORE the first
one is complete. For example:
I made a new stack with this script:
on doSave
put "ftp://admin:passw...@123.456.789.012/UploadT
12 matches
Mail list logo
