Jump to content

WinAPIEx UDF


Yashied
 Share

Recommended Posts

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

Posted Image

Posted Image

Posted Image

Posted Image

Posted Image

Posted Image

Posted Image

Posted Image

Edited by Yashied
Link to comment
Share on other sites

Thanks again Yashied for your efforts!

Great library now with a lot of great functions! :D

UEZ

Please don't send me any personal message and ask for support! I will not reply!

Selection of finest graphical examples at Codepen.io

The own fart smells best!
Her 'sikim hıyar' diyene bir avuç tuz alıp koşma!
¯\_(ツ)_/¯  ٩(●̮̮̃•̃)۶ ٩(-̮̮̃-̃)۶ૐ

Link to comment
Share on other sites

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 :D

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

Edited by ProgAndy

*GERMAN* [note: you are not allowed to remove author / modified info from my UDFs]My UDFs:[_SetImageBinaryToCtrl] [_TaskDialog] [AutoItObject] [Animated GIF (GDI+)] [ClipPut for Image] [FreeImage] [GDI32 UDFs] [GDIPlus Progressbar] [Hotkey-Selector] [Multiline Inputbox] [MySQL without ODBC] [RichEdit UDFs] [SpeechAPI Example] [WinHTTP]UDFs included in AutoIt: FTP_Ex (as FTPEx), _WinAPI_SetLayeredWindowAttributes

Link to comment
Share on other sites

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 :D

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 by Yashied
Link to comment
Share on other sites

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 by ProgAndy

*GERMAN* [note: you are not allowed to remove author / modified info from my UDFs]My UDFs:[_SetImageBinaryToCtrl] [_TaskDialog] [AutoItObject] [Animated GIF (GDI+)] [ClipPut for Image] [FreeImage] [GDI32 UDFs] [GDIPlus Progressbar] [Hotkey-Selector] [Multiline Inputbox] [MySQL without ODBC] [RichEdit UDFs] [SpeechAPI Example] [WinHTTP]UDFs included in AutoIt: FTP_Ex (as FTPEx), _WinAPI_SetLayeredWindowAttributes

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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 :D), 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 :D), 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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by Yashied
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 2 weeks later...

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. :D

Link to comment
Share on other sites

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 by Yashied
Link to comment
Share on other sites

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

Have you removed it?

UEZ

Edited by UEZ

Please don't send me any personal message and ask for support! I will not reply!

Selection of finest graphical examples at Codepen.io

The own fart smells best!
Her 'sikim hıyar' diyene bir avuç tuz alıp koşma!
¯\_(ツ)_/¯  ٩(●̮̮̃•̃)۶ ٩(-̮̮̃-̃)۶ૐ

Link to comment
Share on other sites

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...