WinAPIEx UDF

[Yashied]

Thanks, will be added in the next version.

Edited September 9, 2010 by Yashied

[guinness]

Excellent! It's just an observation but I noticed that in the AutoIt HelpFile the UDF examples they have use #AutoIt3Wrapper_Au3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 to ensure all variables are declared/used etc. correctly. Because I have started to use #AutoIt3Wrapper_Au3Check_Parameters= within my scripts, the other day it reported (non-disastrous) 17 warnings with WinAPIEx..

I was wondering with the next release coming has it been something you have considered looking at in the past? Of course these are non-script breaking warnings, but it would make the UDF 100% Tidy

Edited September 8, 2010 by guinness

[Yashied]

Excellent! It's just an observation but I noticed that in the AutoIt HelpFile the UDF examples they have use #AutoIt3Wrapper_Au3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 to ensure all variables are declared/used etc. correctly. Because I have started to use #AutoIt3Wrapper_Au3Check_Parameters= within my scripts, the other day it reported (non-disastrous) 17 warnings with WinAPIEx..

I was wondering with the next release coming has it been something you have considered looking at in the past? Of course these are non-script breaking warnings, but it would make the UDF 100% Tidy

OK, will be done in the next version. Thanks.

[guinness]

Look forward to the next release

[Yashied]

The library has been updated.

v3.0

Changes

• Added the following functions.

  _WinAPI_AddFontMemResourceEx

  _WinAPI_BeginUpdateResource

  _WinAPI_ClipCursor

  _WinAPI_CreateFileMapping

  _WinAPI_CreateIcon

  _WinAPI_CreateIconFromResourceEx

  _WinAPI_DllGetVersion

  _WinAPI_EndUpdateResource

  _WinAPI_FlushViewOfFile

  _WinAPI_GetClipCursor

  _WinAPI_GetConnectedDlg

  _WinAPI_GetDCEx

  _WinAPI_GetErrorMessage

  _WinAPI_GetOutlineTextMetrics

  _WinAPI_GetTextAlign

  _WinAPI_IsInternetConnected

  _WinAPI_LookupIconIdFromDirectoryEx

  _WinAPI_MapViewOfFile

  _WinAPI_OpenFileMapping

  _WinAPI_PathRelativePathTo (Thanks Mat)

  _WinAPI_RegQueryMultipleValues

  _WinAPI_RemoveFontMemResourceEx

  _WinAPI_ReplaceFile

  _WinAPI_SetTextAlign

  _WinAPI_UnmapViewOfFile

  _WinAPI_UpdateResource

• Added examples for the functions above.
• Removed the following functions.

  _WinAPI_FileTimeToLocalFileTime (use Date.au3)

  _WinAPI_FileTimeToSystemTime (use Date.au3)

  _WinAPI_GetIconBitmap (use _WinAPI_GetIconInfo())

  _WinAPI_GetIconMask (use _WinAPI_GetIconInfo())

  _WinAPI_GetProfilesDirectory (use _WinAPI_ShellGetKnownFolderPath())

• Changed header for the following functions.

  _WinAPI_FindResource

  _WinAPI_FindResourceEx

  _WinAPI_PathSearchAndQualify (added parameter)

• Changed few internal function.
• Changed elementname in the $tagTEXTMETRIC structure.
• Removed some unused local variables. (Thanks guinness)
• Prevented the unloading some DLLs (such as sensapi.dll) after using its functions.
• Fixed a bug related to returning incorrect error code in the _WinAPI_AdjustTokenPrivileges() function.
• Fixed several bugs related to incorrect definition of data types.
• Fixed several minor bugs.
• Updated documentation (WinAPIEx Help).

Edited October 4, 2010 by Yashied

[KaFu]

Again, definitely a must have !

[UEZ]

Fully agree! Must have library!

Thanks again for your efforts Yashied!

Br,

UEZ

[Yashied]

A small update without changing UDF version.

Changes

• Added the following functions.

  _WinAPI_GetProcessHandleCount

  _WinAPI_GetSystemTimes

• Added examples for the functions above.
• Renamed the following functions.

  _WinAPI_GetModuleFileNameEx => _WinAPI_GetProcessFileName

  _WinAPI_GetWindowModuleFileName => _WinAPI_GetWindowFileName

• The following functions returns now array instead of structure (see documentation).

  _WinAPI_GetProcessIoCounters

  _WinAPI_GetProcessMemoryInfo

• Removed $tagPROCESS_MEMORY_COUNTERS structure.
• Fixed a bug related to memory leak in _WinAPI_UpdateLayeredWindowEx() function.
• Updated documentation.

Edited September 22, 2010 by Yashied

[ivan]

***** + Thanks for sharing.

I've read the entire thread trying to find an objective justification for not seeing this in the Autoit UFDs, but I honestly have found nothing. Perhaps a discussion on splitting this script and a subjective discussion on error reporting. Furthermore, there are no objections from community members.

I can also point that Yashied has maintained the code, frequently added functionality and kept a neat record of script versions. The chm documentation and examples are complete, practical and illustrating.

I have tested a few functions and in a matter of minutes found enormous benefits and enhancements. Not to mention that I found a solution to a resource issue that has been bugging me for days... but that's off the point.

I must agree here that the reason for this not being fully incorporated to Autoit is, as Yashied pointed out at the outset, "unknown".

Again, thank you and well done!

[Mat]

It's size probably doesn't help. This thing is huge.

[pierrotm777]

It's a great job.

Thanks for this share

[Ascend4nt]

Re: Including this as a Standard UDF:

I agree with Mat about the size. It absolutely *needs* to be split into separate files. Plus, the standard UDF's have a mostly-standardized form of calling them, where the type of the function being performed comes before the rest of the function name. (_Date_Time, _Mem, _Net, _Security, _Timer etc).

That's my major gripe with this all-in-one module thinking. It is far too large, and besides the problem of it all being jumbled into one file, I believe its far easier to find the type of function you would need more easily using MSDN or Google. I don't see any structure in the Help file either. '_WinAPI_*' doesn't do anything for me, and while I've often used similar conventions for some functions in the past, I seriously try to avoid doing that anymore unless I can't think of a category, or just don't have anything related to that category.

Other things that didn't agree with me the last time I looked over it:

- There's a lot of internal function calls, unnecessary variable checking or 'fixing' (like operations involving paths will call PathCanonicalize or something similar). Most all standard AutoIt UDF's don't bother check parameters and just jump right to the DLLCall.

- Type safety - I've seen areas the last time I looked where functions aren't x64 safe, and I wasn't about to go checking every single function and reporting on them.

- Error returns - there's no standards for them. But this is actually typical of AutoIt UDF's so it wouldn't affect the feasibility of including them. I just prefer a standard return scheme in my own UDF's.

And hmm.. I can't recall, but I believe I disagreed with the parameter form for some functions. But that's just a small personal preference also - I mean seriously, think about '_IsPressed()' - who's bright idea was it to require a STRING to be passed to a function that must then convert it into a number? Seems moronic to me.

Lastly, and this is my main thing.. why include *every* single API function that there is for Windows. Seriously - why? The UDF will probably continue to grow past its already massive size 'just because' there's another API function in Windows he missed. I know the whole point of the UDF is basically 'every API call for Windows'.. but I still don't get it. Most all API functions are documented well enough out there, and DLLCall doesn't have to be wrapped for every little thing.

If I personally need something, I can easily code any API function myself, which is what I currently do. All I need is MSDN. When I feel I have a number of functions that relate to a certain theme, I'll create a UDF, sure - but I'll also create a standardized interface for calling them.

Blah.. I'm not trying to bash Yashied here. I actually know that he's put a LOT of effort into this and it is to be applauded for sure, especially with included example code and a Help file to boot! I just don't see how it could ever be included in AutoIt as it is, and I certainly don't have or see a use for it myself.

HOWEVER, having said that though, I will say this:

For newbs, I can see this as being quite helpful. That is its one saving grace and why I'll occasionally tell people to check this out. For people that have no clue about DLLStruct's and DLLCall's, this is probably as great a place to start learning about it as any.

Additionally, with examples included - it might open people's eyes as to what certain API calls really accomplish.

So yes - I think this UDF is awesome, as is Yashied for putting so much effort into it. But for it to be included in AutoIt UDF's, not gonna happen any time soon.

[Yashied]

I tried to include into this UDF only basic functions. I have not touched on topics such as GDI+, DirectX, Networking, and many, many others. This is really a separate topics and separate UDF. Split WinAPIEx into pieces will be quite problematic. Will needs to duplicate many functions, for example, _WinAPI_CloseHandle(), _WinAPI_DeleteObject(), etc., or to include other UDFs. Anyway, if I split WinAPIEx, for example, WinAPIEx1, WinAPIEx2, etc. then many the ready-made programs will begin with the following lines.

#Include <WinAPIEx1.au3>
#Include <WinAPIEx2.au3>
...
#Include <WinAPIExN.au3>

This would be similar to the situation with a GUI. If I were to include in my project the small GUI, begin to multiply #Include...

#Include <Constants.au3>
#Include <EditConstants.au3>
#Include <FontConstants.au3>
#Include <GUIButton.au3>
#Include <GUIComboBox.au3>
#Include <GUIConstantsEx.au3>
#Include <GUIImageList.au3>
#Include <GUIListView.au3>
#Include <GUIMenu.au3>
#Include <GUITreeView.au3>
#Include <MenuConstants.au3>
#Include <StaticConstants.au3>
#Include <WindowsConstants.au3>

It's very inconvenient.

'_WinAPI_*' doesn't do anything for me, and while I've often used similar conventions for some functions in the past, I seriously try to avoid doing that anymore unless I can't think of a category, or just don't have anything related to that category.

Do you often look for functions in the MSDN by categories? Even in MSDN changed several times a categories. Though perhaps it needs be done in documentation.

There's a lot of internal function calls, unnecessary variable checking or 'fixing'...

Only where it's really necessary.

Most all API functions are documented well enough out there, and DLLCall doesn't have to be wrapped for every little thing.

It's a trancexx's programming style. I think the code which consist only of the DllCall() functions, not a good idea to general perceptions, and debug programs. Though, it's a private matter.

Thanks to all for your comments.

P.S

Ascend4nt, we are software developers (I think), and we each have their own preferences regarding the code design, methods of it writing, etc. So it should be. Glad to see you again.

Edited September 23, 2010 by Yashied

[Mat]

Of course obfuscator will strip unused functions if you ask nicely...

[Yashied]

For information. If you use Aut2Exe with UPX, inclusion the WinAPIEx UDF adds only ~150 KB.

[linus]

... If I personally need something, I can easily code any API function myself, ...

... not dealing with API functions every day maybe I could, but why figure out on myself when it's provided ready to use with nice help/example ...

From this point, size of UDF doesn't really matter, only nice-to-have (and time saving) would be division of the help file into categories.

[Ascend4nt]

Split WinAPIEx into pieces will be quite problematic. Will needs to duplicate many functions, for example, _WinAPI_CloseHandle(), _WinAPI_DeleteObject(), etc., or to include other UDFs. Anyway, if I split WinAPIEx, for example, WinAPIEx1, WinAPIEx2, etc. then many the ready-made programs will begin with the following lines.

#Include <WinAPIEx1.au3>
#Include <WinAPIEx2.au3>
...
#Include <WinAPIExN.au3>

With CloseHandle/DeleteObject etc, you can always have a 'base' include that includes the most common API calls in it.

I wouldn't name the separate modules as numbers, as that's just plain confusing. This is where categories would make sense. However, even if you were to do 'WinAPIEx_User32' or 'WinAPIEx_Kernel32', you could cut it down in some pieces. Of course, the problem with that though is that Microsoft spreads common 'categories' across multiple DLL's (GUI elements functions can be found in I believe 3 separate DLL's). Perhaps at the minimum you could separate constants out.. but those are probably used inside the functions.

Do you often look for functions in the MSDN by categories? Even in MSDN changed several times a categories. Though perhaps it needs be done in documentation.

No, of course not - MSDN isn't very consistent. I can usually find what I'm looking for within one or two searches though. Naming your own functions with categories may be a huge inconvenience, no doubt, but it would be a great approach IMO. It would suck for those that are already using your UDF though lol.

But this is, as you point out, personal preference. Still - it would carry weight if you were to do that and ask for it to be included as a set of standard UDF's.

It's a trancexx's programming style. I think the code which consist only of the DllCall() functions, not a good idea to general perceptions, and debug programs. Though, it's a private matter.

Indeed, I would feel better if the standard UDF's had at least *minimal* parameter/return checking - however, like a number of built-in functions, debugging lies with the programmer. At least, that's my theory on the standard UDF's. Still - I hate that some functions return values that pass tests like 'IsPtr()' when in fact the API call returned a 0 result, and 0 is certainly an invalid pointer. Things like that still bother me with the standard API's.

On a whole, I agree this stuff is really personal preference. I was just trying to view it from the perspective of it being included in the AutoIt standard UDF's. With the standard UDF's, the burden of checking/debugging things is on the programmer, but with UDF's like mine or yours, we include some parameter checking. To what extent those parameters should be tested is based on our programming styles I suppose.

Anyway, I do see this UDF as a very nice community contribution, and obviously something you've worked very hard on. I also see people getting much use out of, so its definitely a big help to others. I'll probably continue to point newbs to this UDF as it would save them alot of time, in addition to giving them some insight into what things do.

So while I may have my reservations about things (especially about the possibility of it being added to AutoIt), I do acknowledge that its a great UDF to be recommended to others. Keep up the good work Yashied.

@Mat:

If any UDF there ever was to require it, this is certainly the one to use the 'strip' Obfuscation compile-time option on. I would also recommend allowing function renaming with the '/om' option to shrink it down further. ~150KB on disk, while not huge, is still to me more than is needed. Plus we can't forget that in-memory requirements will be different, as probably would execution-time. AutoIt has to of course parse through all that stuff AND store it in memory somehow.

[ivan]

Linus is the first one to place a strong objection.

I personally think that a run time memory increase is a small price to pay for greater functionality, depending on what your program does. It definitely cuts down on developing time, and for this I'm quite grateful. I'm quite honest here and admit that it would take me ages to write a single function in this library, so to me, it's significantly useful. I'm probably more concerned with whether using it accomplishes a particular job, but then this is practical thinking. I must say, I've only started looking at this script and in a relatively short time I have learned lots from it.

Anyway, if you plan to abuse resource (mem + processor) usage by embedding lots of objects (browsers, multimedia players, power point, to mention a few) you're asking for trouble, in which case you should watch it. Otherwise, loading this library will never reach a fraction of the resource usage of embedding a browser object in a gui. With this I mean to point out that a discussion of resource usage is only relevant with a specific program in mind.

If you were to account the number of functions in the script you should probably add those in the WinAPI.au3 while you're at it, since this lib already includes it:

#Include <WinAPI.au3>

On the other hand, I have found that reading this script is painful. I'd probably start with a little suggestion for a split, if this is feasible, move:

#Region Global Variables and Constants

......

#EndRegion Global Variables and Constants

to a "WinAPIEx_VARS.au3" file.

In any case, the decision on whether this is included in Autoit is not up to me. This really is down to the good judgement of the autoit team.

Ivan

Edited September 26, 2010 by ivan

[131738]

_WinAPI_GetConnectedDlg

--------------------------------------------------------------------------------

Launches the Get Connected wizard within the calling application to enable network connectivity.

_WinAPI_GetConnectedDlg ( $iDlg [, $iFlags [, $hParent]] ) $iDlg - Specifies which the dialog should be launched, valid values: |0 - Local area network connectivity. |1 - Internet connectivity. |2 - Virtual private network (VPN) connectivity.

*********************************************************

_WinAPI_PathRelativePathTo

Return Value

Success - Failure - Empty string and sets the @error flag to non-zero.

Edited September 27, 2010 by 131738

[Yashied]

_WinAPI_GetConnectedDlg

--------------------------------------------------------------------------------

Launches the Get Connected wizard within the calling application to enable network connectivity.

_WinAPI_GetConnectedDlg ( $iDlg [, $iFlags [, $hParent]] ) $iDlg - Specifies which the dialog should be launched, valid values: |0 - Local area network connectivity. |1 - Internet connectivity. |2 - Virtual private network (VPN) connectivity.

And what?

_WinAPI_PathRelativePathTo

Return Value

Success - Failure - Empty string and sets the @error flag to non-zero.

OK.