WinAPIEx UDF

[Yashied]

The library has been updated to version 1.77. Now library contains 197 functions and 58 examples (uses almost all functions). I think this will be the final major update. I'll be glad to any feedback and suggestions for further development of this library.

Added functions

_WinAPI_AlphaBlend

_WinAPI_BeginPaint

_WinAPI_CreateCompatibleBitmapEx

_WinAPI_CreateRectEx

_WinAPI_DrawShadowText

_WinAPI_Ellipse

_WinAPI_EndPaint

_WinAPI_EqualRgn

_WinAPI_ExtSelectClipRgn

_WinAPI_FillRgn

_WinAPI_FitToBitmap

_WinAPI_FrameRgn

_WinAPI_GetBValue

_WinAPI_GetGValue

_WinAPI_GetObjectType

_WinAPI_GetPixel

_WinAPI_GetRValue

_WinAPI_CreateBrushIndirect

_WinAPI_CreateDIBSection

_WinAPI_CreateEllipticRgnIndirect

_WinAPI_CreatePolygonRgn

_WinAPI_CreateRectRgnIndirect

_WinAPI_GradientFill

_WinAPI_InvalidateRgn

_WinAPI_InvertRgn

_WinAPI_MakeRGB

_WinAPI_OffsetClipRgn

_WinAPI_OffsetRgn

_WinAPI_PaintRgn

_WinAPI_Polygon

_WinAPI_PtInRegion

_WinAPI_RestoreDC

_WinAPI_SaveDC

_WinAPI_SetDCBrushColor

_WinAPI_SetDCPenColor

_WinAPI_SetPixel

_WinAPI_SetStretchBltMode

_WinAPI_StretchBlt

_WinAPI_TransparentBlt

_WinAPI_ValidateRgn

+ few examples

Edited September 2, 2009 by Yashied

[UEZ]

Thanks again Yashied for your efforts!

Great library now with a lot of great functions!

UEZ

[ProgAndy]

You've done a great job with this UDF library.

I think now it is time to split the WinAPI-functions into multiple files, just using the different categories on MSDN or our scripts will grow too big

Btw: the last update seems to overlap with my GDI library

Edited August 30, 2009 by ProgAndy

[Yashied]

You've done a great job with this UDF library.

I think now it is time to split the WinAPI-functions into multiple files, just using the different categories on MSDN or our scripts will grow too big

I've been thinking about it. But, for example, GetDC function resides in user32.dll, but CreateCompatibleDC - gdi32.dll. Typically, these functions are used together and in this case will have to use both libraries. So I did not split the file into pieces, the more that I did not find any restrictions on AutoIt file size.

Edited August 30, 2009 by Yashied

[ProgAndy]

I've been thinking about it. But, for example, GetDC function resides in user32.dll, but CreateCompatibleDC - gdi32.dll. Typically, these functions are used together and in this case will have to use both libraries.

I did not think of splitting by DLL, but on the categories in MSDN, since the functions are grouped by logical categories and not the DLLs they are located in. For example, the functions you mentioned are located in Windows GDI -> Device Contexts.

So I did not split the file into pieces, the more that I did not find any restrictions on AutoIt file size.

I just think, it is not a good programming practice to include all and everything to use the things you want, but on the other hand there is the Obfuscator which is able to remove all unneeded functions when compiling, so this is not a very big problem. Additionally, one file will be easier to handle for less experienced users, just think about the new files for the constants... Edited August 30, 2009 by ProgAndy

[Yashied]

I agree. Thanks anyway.

[Zedna]

@Yashied

Very good additions.

Sorry I can't give you more than five stars :-)

I agree with ProgAndy about splitting WinAPI UDF.

I think it will be good to move all GDI stuff from WinAPI.au3 to new GDI.au3

[Yashied]

@Yashied

Very good additions.

Sorry I can't give you more than five stars :-)

I agree with ProgAndy about splitting WinAPI UDF.

I think it will be good to move all GDI stuff from WinAPI.au3 to new GDI.au3

Thanks. Maybe you're right.

[Zedna]

I agree with ProgAndy about splitting WinAPI UDF.

I think it will be good to move all GDI stuff from WinAPI.au3 to new GDI.au3

Now I'm looking at WinAPI UDF and I see all functions have prefix WinAPI_

so if we would move GDI functions to newly created GDI UDF

this prefix should be changed to GDI_ and this will be BIG script breaking change.

So I'm not sure if that will be good idea due to bad backward compatiblity (script breaking changes).

[corgano]

This has to be one of the biggest librarys I have ever seen. Good work!

Are there examples for all of them?

[Yashied]

Are there examples for all of them?

For most (most interesting).

[Yashied]

In native AutoIt WinAPI.au3 library I see the chaos with use a color modes (RGB or BGR). Some functions work only with RGB, others only with BGR, the third with both. So I wrote a function _WinAPI_SetLibraryColorMode() for my UDF, that changes the color mode for all functions that use the color values. By default, as it was before, all function work in RGB color mode. Calling this function with parameter 0 (False) determines the color mode in BGR format. It is necessary for compatibility with some functions from the native WinAPI UDF. For example,

$hBitmap = _WinAPI_CreateCompatibleBitmapEx($hDC, 400, 400, _WinAPI_SwitchColor(_WinAPI_GetSysColor($COLOR_3DFACE)))

or it can be written as follows

_WinAPI_SetLibraryColorMode(0)
$hBitmap = _WinAPI_CreateCompatibleBitmapEx($hDC, 400, 400, _WinAPI_GetSysColor($COLOR_3DFACE))

Also, I fix a few bugs related to return the incorrect values (True instead False). And, at the request of some users on this forum, added some useful functions:

_WinAPI_DllInstall

_WinAPI_DllUninstall

_WinAPI_FillStruct

_WinAPI_GetObjectEx

_WinAPI_GetRgnBox

_WinAPI_PathMatchSpec

_WinAPI_TextOut

This is finale (I think ), WinAPIEx.au3 is done. I take a timeout for this project. In the future I think to write GDIPlusEx.au3 (UEZ probably will be happy ), or try "to tie" DirectX for AutoIt.

P.S

Thanks to all who took part to expansion of this library, namely (alphabetical):

Authenticity

GEOSoft

KaFu

Martin

MrCreatoR

ProgAndy

Psandu.ro

Rover

WideBoyDixon

And thanks to all AutoIt community on this forum.

Yashied.

[smashly]

Hi your udf is coming along nicely and it's very useful as a learning tool,

But really think the error returns on most the functions need to be thought out a bit better.

Maybe follow along the lines of WinAPI.au3 error handling and returns may make your udf more professional.

As it is atm the error returns are not to helpful to try and debug if something is going wrong

eg:

If (@error) Or ($Ret[0] = 0) Then

Return SetError(1, 0, 0)

EndIf

To me this just tells me there's an error, but what is the error?

Has autoit failed the dll call or has the api call succeeded but the return failed.

If I can distinguish the error then I can resolve it a lot quicker.

for example if the return was more like:

If @error Then Return SetError(@error, 0, 0) ;error is 1 to 3 then I know autoit failed the dll call

I understand that each api call can net different error returns, but the constant is the @error after a dll call before even dealing with the api error return.

Cheers

[Yashied]

Hi your udf is coming along nicely and it's very useful as a learning tool,

But really think the error returns on most the functions need to be thought out a bit better.

Maybe follow along the lines of WinAPI.au3 error handling and returns may make your udf more professional.

As it is atm the error returns are not to helpful to try and debug if something is going wrong

eg:

If (@error) Or ($Ret[0] = 0) Then

Return SetError(1, 0, 0)

EndIf

To me this just tells me there's an error, but what is the error?

Has autoit failed the dll call or has the api call succeeded but the return failed.

If I can distinguish the error then I can resolve it a lot quicker.

for example if the return was more like:

If @error Then Return SetError(@error, 0, 0) ;error is 1 to 3 then I know autoit failed the dll call

I understand that each api call can net different error returns, but the constant is the @error after a dll call before even dealing with the api error return.

Cheers

smashly, what are the reasons to write the following?

$Ret = DllCall(...)

If @error Then

Return SetError(@error, 0, 0)

EndIf

If we are talking about WinAPI, it is best to do so:

$Ret = DllCall(...)

If @error Then

Return SetError(_WinAPI_GetLastErrorMessage(), 0, 0)

EndIf

But there is not much point, because in most cases it is simply not necessary. Users themselves can call _WinAPI_GetLastError() or _WinAPI__GetLastErrorMessage() and analyze the error code. For example, error code 127 - "The specified procedure could not be found", ie equivalent to @error = 3. Other errors after calling DllCall() did not usefull for you, and you'll still have to call _WinAPI_GetLastError(). Of course, you can always return the WinAPI error code, but as I said, this is not often required, and use for this resources - this is not professionally. I think it would be more correct to write so (in your script):

_WinAPI_...()
If @error Then
    $iCode = _WinAPI_GetLastError()
    ...
EndIf

EDIT:

Furthermore, in most cases the DllCall() is executed much slower than the WinAPI function that it implements.

Edited September 4, 2009 by Yashied

[smashly]

Hi,

This is what I see in so many of your functions in 1.78 udf

If (@error) Or ($Ret[0] = 0) Then
    Return Seterror(1, 0, 0)
EndIf

It is not really a good error return, it's better then nothing but only just.

Then I read what you've just said..

$Ret = DllCall(...)

If @error Then

Return SetError(_WinAPI_GetLastErrorMessage(), 0, 0)

EndIf

That is exactly what I mean that a lot of the functions have poor error return methods..

Lets break it down.

$Ret = DllCall(...)

If @error Then ...

If there was an error at this point then it would lay with the DllCall() function and it's autoit retuning an error.

So the first error check after a DllCall() would be to see if AutoIt Failed.

DllCall() Return Value

Success: @error = 0.

Failure: @error = 1 unable to use the DLL file,

@error = 2 unknown "return type",

@error = 3 "function" not found in the DLL file.

I'd like to know if Autoit failed or the api return is failing

Once again @error is only returning an error if DllCall() function is failing.

Now once we know there is no DllCall() function error,

then we know that the Dll file I called Can be used, the "return type" is correct and the function exists in the dll.

So now it's worth while to query the api return eg: _WinAPI_GetLastErrorMessage() or $ret[0] <> 0 or whatever the api dll call returns to find if it failed or not.

Please don't get me wrong as I mean no disrespect.

You've done a great job of slinging over 200 api calls into a udf which is no small task and it is appreciated.

I'd be buggered if I'd ever even attempt to do what you've done.

Cheers

[joseLB]

Hi Yashield

Great library! I think there is one very interesting, about to know transmited/received packages by TPC in a PC. Follows a sample program, based on monoceres clues at http://www.autoitscript.com/forum/index....9917&hl=joselb&fromsearch=1&#entry719917

$MIB_TCPSTATS=DllStructCreate("dword[15]")
global $sent=0, $resent=0, $received=0, $enviados, $recebidos, $mediaEnv=0, $mediaRec=0
while 1
$lastsent= $sent + $resent
$lastReceived= $received
DllCall("Iphlpapi.dll","int","GetTcpStatistics","ptr",DllStructGetPtr($MIB_TCPSTATS))
$received= DllStructGetData($MIB_TCPSTATS,1,10) ; dwInSegs
$sent=DllStructGetData($MIB_TCPSTATS,1,11) ; dwOutSegs
$resent=DllStructGetData($MIB_TCPSTATS,1,12) ;dwRetransSegs
;MsgBox(0,"Total uploaded/downloade",$sent+$resent&" packets." [email="&@CRLF"]&@CRLF[/email]& $received)
$enviados= $sent+$resent - $lastsent
$mediaEnv= ($mediaEnv*9 + $enviados) /10
$recebidos= $received - $lastReceived
$mediaRec= ($mediaRec*9 + $recebidos) / 10
ToolTip("packets sent: " & Round($enviados) & " = " & Round($enviados * 1.5) & "Kbits | ~ " & Round($mediaEnv* 1.5) _ 
  [email="&@CRLF"]&@CRLF[/email]& "packets rec: " & Round($recebidos) & " = " & Round($recebidos * 5.5) & "Kbits | ~ " & Round($mediaRec* 5.5))
sleep(1000)
WEnd

Jose

[Yashied]

1.8

Added functions

_WinAPI_AssocQueryString

_WinAPI_ChildWindowFromPointEx

_WinAPI_DragAcceptFiles

_WinAPI_DragFinish

_WinAPI_DragQueryFileEx

_WinAPI_DragQueryPoint

_WinAPI_EnumChildWindows

_WinAPI_GetTopWindow

_WinAPI_GetWindowModuleFileName

_WinAPI_IsHungAppWindow

_WinAPI_IsWindowUnicode

+ few examples

For good measure only two votes are not enough.

[Yashied]

People, why do you modify this UDF, and then tell me: "Oh, here you have an error, Ah, it does not work"? This UDF is fully working in the form in which I offer it to you! I tested every function in AutoIt 3.3.0.0 and 3.3.1.1 Beta (WindowsXP SP3 x86, for x64, some may not work), and it works as designed. Please do not have to write me in the mailbox similar questions, ask in this topic for.

Thanks.

Edited October 7, 2009 by Yashied

[UEZ]

I cannot see the download link from your 1st post anymore

Have you removed it?

UEZ

Edited September 23, 2009 by UEZ

[Yashied]

I cannot see the download link from your 1st post anymore

Have you removed it?

UEZ

No, it's there where it was before. Post #1