working with a custom dll

[trancexx]

There is no need to use DllOpen() and DllClose(). The string is copied when using the "str" parameter. It would be rather stupid if it wasn't.

Could you put that in the help file, about copying string. To make it official. One line saying just that.

See this:

expandcollapse popup

#cs

http://msdn.microsoft.com/en-us/library/bb759979(VS.85).aspx

    LPTSTR StrFormatKBSize(
    LONGLONG qdw,
    LPTSTR pszBuf,
    UINT cchBuf
    );

#ce


$iSize = 12345;67890

ConsoleWrite(@CRLF)

ConsoleWrite("+ Size = " & $iSize & " bytes" & @CRLF & @CRLF)


; FIRST CASE
;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ConsoleWrite("! ptr + ptr" & @CRLF)

$tBuffer = DllStructCreate("char[65536]")

$aCall = DllCall("shlwapi.dll", "ptr", "StrFormatKBSize", _
        "int64", $iSize, _
        "ptr", DllStructGetPtr($tBuffer), _
        "dword", 65536); 16 would be enough

ConsoleWrite("error = " & @error & @CRLF)
ConsoleWrite("return = " & $aCall[0] & @CRLF)
ConsoleWrite("result = " & $aCall[2] & @CRLF)

$tString = DllStructCreate("char[65536]", $aCall[0])
ConsoleWrite("  result by return = " & DllStructGetData($tString, 1) & @CRLF)

$tString = DllStructCreate("char[65536]", $aCall[2])
ConsoleWrite("  result by result = " & DllStructGetData($tString, 1) & @CRLF)
;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ConsoleWrite(@CRLF)


; SECOND
;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ConsoleWrite("! str + str" & @CRLF)

$aCall = DllCall("shlwapi.dll", "str", "StrFormatKBSize", _
        "int64", $iSize, _
        "str", "", _
        "dword", 65536)

ConsoleWrite("error = " & @error & @CRLF)
ConsoleWrite("return = " & $aCall[0] & @CRLF)
ConsoleWrite("result = " & $aCall[2] & @CRLF)
;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


ConsoleWrite(@CRLF)


;THIRD
;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ConsoleWrite("! ptr + str" & @CRLF)

$aCall = DllCall("shlwapi.dll", "ptr", "StrFormatKBSize", _
        "int64", $iSize, _
        "str", "", _
        "dword", 65536)

ConsoleWrite("error = " & @error & @CRLF)
ConsoleWrite("return = " & $aCall[0] & @CRLF)
ConsoleWrite("result = " & $aCall[2] & @CRLF)

$tString = DllStructCreate("char[65536]", $aCall[0])
ConsoleWrite("  result by return = " & DllStructGetData($tString, 1) & @CRLF);<- crash is likely to happen here
;XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Since there is no buffer available after DllCall() returns (third example), it would likely crash. And that explains it.

[Valik]

If we attempt to document every possible way in which you can shoot yourself with DllCall() we will never be able to do anything else again.

[trancexx]

If we attempt to document every possible way in which you can shoot yourself with DllCall() we will never be able to do anything else again.

Yes of course. Only in this case AutoIt programmer (who's that?) have no reason to even think that third example would 'act' unexpectedly.

It's undocumented fundamental behaviour.

[Valik]

I don't agree. Why would you think you could use something you don't control? I certainly don't expect to use things I don't control so why do you?

[trancexx]

I don't agree. Why would you think you could use something you don't control? I certainly don't expect to use things I don't control so why do you?

Will you allow me to elaborate? Since it's going off-topic.

[Valik]

Go ahead.

[trancexx]

Ok.

So... AutoIt programmer is person writing AutoIt scripts. His knowledge of other languages is questionable (irrelevant actually). For this example let's say he is he and has none.

He is introducing himself with Dllcall() function. Reads documentation, makes few attempts, read some more and finally hits few ssuccessful calls.

Then he tries to call some functions that are more requiring on a knowledge level. Only thing he have is msdn and AutoIt documentation (with number of examples in UDFs). Based on that and needed additional reading he becomes to see things clearer.

In the mean time StrFormatKBSize pops up. For practice do calling in all possible ways. Three of them are few posts up.

Third example is not working properly. Why is that??? Read msdn... read AutoIt's help file... nothing. It simply isn't working as you expect it. Only possible explanation is that your expectation is not right. Forget about it and move on.

This is bad situation. It's bad because you are left without the answer to something that by your current logic shouldn't be happening. Only because you are AutoIt programmer.

If you know some other language(s) you can, depending on your capacity, derive possible answers to the question.

You can presume what you said about copying and do few more tests on some other functions. Doing that you will be almost certain that's happening. But not be sure of cours - because it's not documented.

AutoIt programmer (I must emphasize) is stuck four sentences up. Only because documentation lacks that information.

To understand what I said here, you have to forget your c++... (whatever) knowledge and reread it only with AutoIt.

Btw, if your counterargument would be that to use DllCall() you need to know other basic languages then you aren't reading this as I asked you to and once again my post will be meaningless.

[Valik]

Btw, if your counterargument would be that to use DllCall() you need to know other basic languages then you aren't reading this as I asked you to and once again my post will be meaningless.

That is my counter-argument. You fail to take into consideration that DllCall() is an advanced feature that virtually requires an understanding of C or a C-like language. Not every single feature of AutoIt is designed so that a newbie who's never programmed a day in their life can start using them. There are advanced features in the language for advanced users who know what they are doing. DllCall() and the related functions are examples of advanced features.

An additional counter-argument is how is a newbie going to know or find out about a Windows API function? It's not like they are going to have a ton of experience on MSDN. Hell, I've been using MSDN for years now and I didn't even know about the function you demonstrate. MSDN is massive. The Windows API is massive. It's going to be the last place a newbie goes to look.

[trancexx]

Would it then make more sense to you if I say this?

There are advanced features in the language for advanced users who know what they are doing. DllCall() and the related functions are examples of advanced features.

This is also why you should include copy part in the documentation.

If advanced user wants to use advanced features and if you are allowing that then he most certanly must have as much possible informations about internal working of AutoIt in that field.

Advanced user must be told what's going to happen with that part of memory.

I see this 33% below my nick and did saw your reactions to some of my posts. That all and since I did say what I meant is telling to me that I should be out of this thread now.

It's your call.

[Valik]

This is also why you should include copy part in the documentation.

If advanced user wants to use advanced features and if you are allowing that then he most certanly must have as much possible informations about internal working of AutoIt in that field.

Advanced user must be told what's going to happen with that part of memory.

Again, I ask, why would a user think they could access the memory? Nowhere do we state that you can access the memory. I once again find myself saying: It's our responsibility to document what the language can do, not what it can't do.

[trancexx]

Again, I ask, why would a user think they could access the memory? Nowhere do we state that you can access the memory. I once again find myself saying: It's our responsibility to document what the language can do, not what it can't do.

Yes, I see your point.

All I can say as a possible answer is: "Because it's not documented that occupied space will be freed after the content is copied to another buffer before the function returns. And help file is not making any particular distinction between ptr and str or int (this is newbie part)."

Maybe... It would make things easier to learn. Teach people more.

I bet if you would ask 10 users of AutoIt to explain what's happening with the posted example, 8 would never (but never) figured out.

With just one sentence inside help file that number would likely be smaller. People would be smarter.

[Valik]

All I can say as a possible answer is: "Because it's not documented that occupied space will be freed after the content is copied to another buffer before the function returns.

But AutoIt doesn't return raw memory. It returns variants. That way implementation details aren't your concern and you can just write code.

And help file is not making any particular distinction between ptr and str or int (this is newbie part)."

Newbies shouldn't be using the function. Period.

I bet if you would ask 10 users of AutoIt to explain what's happening with the posted example, 8 would never (but never) figured out.

With just one sentence inside help file that number would likely be smaller. People would be smarter.

You know what else would make people smarter? If they would stop to think. I bet most of those 8 people would be experienced users who didn't stop long enough to think the problem through.

Besides, I doubt very seriously a newbie is going to understand what the remark means anyway so what's the point?