InetRead() - missing background flag as for InetGet()

[Zedna]

InetGet() is for download to file

InetRead() is for download to variable

InetGet() has background flag

InetRead() has no background flag

I miss background flag in InetRead().

In my project I have got some information window and some advanced information I want to download from intenet and display as aditional information. These information are not mandatory (may/may not be there) so I want to display basic information and in background download aditional information from web to variable (no temporary file). If download is sucessfull then show result from from variable to window by GUICtrlSetData(). Now I use InetRead() without background but in case of problems with connection/download whole my window will be blocked.

I can easily imagine that similar way somebody can use also multiple background download with InetRead() to array of variables. Each InetRead() would be downloading to $array[$n].

Should I add feature request for this to Trac?

InetRead() - add background flag in the same way as it is for InetGet()

EDIT: Post your opinion here if you have any.

Edited November 6, 2011 by Zedna

[trancexx]

First you should have made a thread asking if you should make this thread.

[JohnOne]

I think it would be rather useful, so I'll say yes.

[Zedna]

First you should have made a thread asking if you should make this thread.

I don't like any your (past/present) reactions targeted to me!

You are unnecessarily aggresive/rude.

Do me a favour and ignore all my posts if you don't have any constructive related opinion!

***

I don't want to unnecessarily bloat Trac.

As for BUG reports where people are not sure is recommended to post of forum for confirmation first.

Feature requests where more people can post more opinions to it are the same candidate for such procedure (forum instead of Trac).

Edited November 6, 2011 by Zedna

[trancexx]

I don't like any your (past/present) reactions targeted to me!

You are unnecessarily aggresive/rude.

Do me a favour and ignore all my posts if you don't have any constructive related opinion!

***

I don't want to unnecessarily bloat Trac.

As for BUG reports where people are not sure is recommended to post of forum for confirmation.

Feature requests where more people can post more opinions to it are the same candidate for such procedure (forum instead of Trac).

I don't give a fuck what you like or not.

Do your self a favor and use your head next time.

Edited November 6, 2011 by trancexx

[Jos]

OMG .. what a great response.

You could either ignore questions if you don't like them or try to be a bit more professional and construct a normal answer.

Playing the "overrule game" or saying "You are stupid" isn't always the best approach.

Jos

[Zedna]

I don't give a fuck what you like or not.

Do your self a favor and use your head next time.

It looks like you successfully absolved Valik's lesson of assertivity.

EDIT: But Valik is more proffesional person.

Edited November 6, 2011 by Zedna

[JohnOne]

I can sense the romance in the air, but cant you keep your courting rituals in your secret forums?

[Jos]

I can sense the romance in the air, but cant you keep your courting rituals in your secret forums?

Maybe not the best post to make at this moment as it doesn't contribute to anything.

Let's stay on topic here and comment to the question posted and leave out all personal attacks/smart remarks....

Jos

[Valik]

I've already responded to this subject in our secret love forum but I'll post here for all to see who also incorrectly think this is a good idea.

InetRead() returns it's data. Please explain how data is supposed to be returned to a variable after the function has already returned. This function simply cannot work in the background because that contradicts the purpose of it's existence.

[Zedna]

InetRead() returns it's data. Please explain how data is supposed to be returned to a variable after the function has already returned. This function simply cannot work in the background because that contradicts the purpose of it's existence.

This was my first idea of worying about that featre request.

But further thoughts were OK to me. Here it is:

Instead of parameter "Filename" in InetGet() there would be ByRef parameter "VariableName" in InetRead()

As far as I know that this ByRef variable will be completely ready after some While loop with InetInfo tests

I must forbid to access to that variable in my code until InetInfo will give finished state.

Anyway I didn't think that now data are returned as RETURN from function and not by ByRef variable.

Is it possible to have Autoit's internal function with ByRef parameter like in UDFs?

[JohnOne]

I've already said it sounds useful, so at the risk of once again being a dumbass, I'm going to say how I seen it in my head (without knowing if it would be possible)

InetRead ( "URL" [, options ] ,ByRef $var]])

One of the options is to return immediately, and the ByRef $var replaced the File as with with InetGet

EDIT:

way to slow.

Edited November 6, 2011 by JohnOne

[KaFu]

What's the underlying Api call? Maybe it easier to code an UDF for this task?

[Valik]

How many built-in functions support ByRef parameters? The answer is 0. How many times have I stated in the past 8 years that AutoIt does not support reference parameters for built-in functions? The answer is in the double digits.

It's not as simple as you make it out to be. Saying "Don't access this variable until you check that the download is complete" is not enough. Some stupid fuck will come along and post "OMG AutoIt crashed" code where they don't write proper code and they just happen to time it perfectly so that they try to write to the variable while AutoIt's background download thread tries to write to it and they get a crash. That means AutoIt variables will need set up for thread safety. The alternative is to store everything in a temporary memory location and then once the download is complete it can be moved to the actual variable. This doesn't require thread safety but does require additional mechanisms to be written for the functionality to even work. This, of course, is ignoring the fact that built-in functions do not support reference parameters which would need solved first. Even if we went the second route of storing to a temporary location and copying to the variable after the download is complete, somebody will want to read the data on-the-fly. The first method would support this natively but the second method would not. A new functions would have to be written and thread synchronization would need set up to support this. This would lead to more work because what we're talking about doing now is pretty much identical to how the STDIO redirection thread works except the data source is different. That means the STDIO class for doing this would need to be re-factored so we don't have two virtually identical classes doing the same thing with different sources.

So what's the net gain for this? Why is writing to a file in the background such a horrible solution that we have to devise new systems and modify existing systems in AutoIt?

Edited November 6, 2011 by Valik

[Zedna]

OK. Thanks for explanation Valik. If ByRef parameters are so complicated then this request really can't be done.

What's the underlying Api call? Maybe it easier to code an UDF for this task?

I can remember somebody asked that already and probably Larry or Gary answered but I can't find it now...

[Zedna]

So what's the net gain for this? Why is writing to a file in the background such a horrible solution that we have to devise new systems and modify existing systems in AutoIt?

It's the same as FileInstall() versus resources.

If it's possible to do things easily without temporary files on disk then it's simply better.

[JohnOne]

OK. Thanks for explanation Valik. If ByRef parameters are so complicated then this request really can't be done.

I can remember somebody asked that already and probably Larry or Gary answered but I can't find it now...

I think InternetReadFile, (Wininet.dll) might be a possible candidate.

[Valik]

It's the same as FileInstall() versus resources.

If it's possible to do things easily without temporary files on disk then it's simply better.

You care far too much about how things are done.

Anyway, I can think of at least one way to do this without having to do anything other than use built-in functions. I'm not going to explain it, though, because the complexity versus functionality is not proportional. In other words, I can describe you an overly complicated system to do what you want but I view it as pointless. Besides it's not difficult to think of.

[ProgAndy]

By the way, here is the solution

expandcollapse popup

#include<NamedPipes.au3>
#include<WinAPI.au3>
Func _NamedPipes_DataAvailable($hNamedPipe)
    Local $aResult = DllCall("kernel32.dll", "bool", "PeekNamedPipe", "handle", $hNamedPipe, "ptr", 0, "int", 0, "ptr", 0, "dword*", 0, "ptr", 0)
    If @error Then Return SetError(1, 0, 0)
    Return $aResult[5]
EndFunc

$hMyPipe = _NamedPipes_CreateNamedPipe(".pipemyautoitinetgetpipe" & @AutoItPID, 0, 1, 0, 0, 0, 0, 1, 0, 2^22)
$tReadBuffer = DllStructCreate("byte[" & 2^22 & "]")
$pReadBuffer = DllStructGetPtr($tReadBuffer)
$iRead = 0
$bData = Binary("")

Local $hDownload = InetGet("http://www.textfiles.com/art/cowz.txt", ".pipemyautoitinetgetpipe" & @AutoItPID, 1, 1)
Do
    Sleep(250)
    If _NamedPipes_DataAvailable($hMyPipe) Then
        _WinAPI_ReadFile($hMyPipe, $pReadBuffer, 2^22, $iRead)
        If $iRead And $iRead < 2^22 Then
            $bData &= BinaryMid(DllStructGetData($tReadBuffer, 1), 1, $iRead)
        ElseIf $iRead Then
            $bData &= DllStructGetData($tReadBuffer, 1)
        EndIf
    EndIf
    ToolTip(InetGetInfo($hDownload, 0) / InetGetInfo($hDownload, 1) * 100)
Until InetGetInfo($hDownload, 2)    ; Check if the download is complete.
Local $aData = InetGetInfo($hDownload)  ; Get all information.
InetClose($hDownload)   ; Close the handle to release resourcs.

If _NamedPipes_DataAvailable($hMyPipe) Then
    _WinAPI_ReadFile($hMyPipe, $pReadBuffer, 2^22, $iRead)
    If $iRead And $iRead < 2^22 Then
        $bData &= BinaryMid(DllStructGetData($tReadBuffer, 1), 1, $iRead)
    ElseIf $iRead Then
        $bData &= DllStructGetData($tReadBuffer, 1)
    EndIf
EndIf


MsgBox(0, "", "Bytes read: " & $aData[0] & @CRLF & _
    "Size: " & $aData[1] & @CRLF & _
    "Complete?: " & $aData[2] & @CRLF & _
    "Successful?: " & $aData[3] & @CRLF & _
    "@error: " & $aData[4] & @CRLF & _
    "@extended: " & $aData[5] & @CRLF)
MsgBox(0, '', BinaryToString($bData))

[Valik]

Clever.