Ahk Standard Library Collection, 2010 Sep (+Gui) ~ Libs: 100

Database
Timestamp: 2015-02-03
Libraries: 100
Ahk Compatible: Basic

Download (~1.5 MB)

Alternative Download

The archive contains all files and no other download is needed.
LICENSE: Please note, the script itself is GNU GPL licensed. The source code must be open, if you publish modified source of this script. See <!-- m -->http://en.wikipedia...._Public_License<!-- m -->

Attention: The libraries have all its own licenses.

Look at this: amnesiac made a custom build of the AHK Basic documentation, with the integration of the libraries I listed here. It is in the .chm format and available for download. See AHK Basic documentation with Standard Library

Table of Content (for this post)

1. Description
2. Database in ini format
3. Call for all library and function developers
4. List of used prefixes and filenames
5. See also, more material

Description

This is my first attempt of creating a collection and sharing of stdlib compatible libraries. It does contain the source, if available a documentation, if available the license text, one sample per lib and some other notes, like if it is strictly stdlib conform (no globals in use etc.).

All these information are collected by hand into one place and saved in an ini file. The associated files can be found as a flat filesystem. The default Gui default script, which is provided with the database, makes it very easy to test the scripts without installing something. It shows buttons for opening the forum posts and the related documentation.

From time to time, I will add more and more libraries, which I find good enough for this. Some libraries I am interested in are not included, because they are not stdlib compatible or easily usable/installable because of some conflicts, i.e. majkinetors Forms Framework.


Screenshot may be outdated. Sorry.

Database in ini format

Any suggestion is welcome. If you like, post your favorite library not listed in the database in following format:

[0]

GUID=regex("\w{8}-\w{4}-\w{4}-\w{4}-\w{12}") ; Generated with Titan`s uuid.ahk

Abstract={string}

Description={string}

Prefix=regex("\w+")

Date=regex("\d+") ; yyyymmdd

Revision={string}

Author={csv}

Discussion={url}

Source={url}

Documentation={url}

Sample={url}

License={string}

LicenseSource={url}

Category={csv}

Standalone="yes|no"

StdLibConform="yes|no"

Dependency={csv} ; filename: GUID

Notes={string}

Not all keys/fields must be present. As an example, look at this:

[4]

GUID=f24c8170-955e-126a-98a5-19ac76b08d4a

Abstract=Text file & Variables/String Library

Description=As the name suggest this is a AHK Library with a number of functions to "manipulate" text, both files such as *.txt, *.ahk, *.html, *.css etc AND Strings (or variables). It is NOT useful for binary files or data such as MS Office files, PDFs, EXEcutables, images etc.

Prefix=TF

Date=20100416

Revision=3.3

Author=hugov

Discussion= http://www.autohotkey.com/forum/viewtopic.php?t=46195

Source=tf.ahk

Documentation=tf.htm

Sample=tf_demo.ahk

Category=FileSystem, Text, Strings

Standalone=yes

StdLibConform=no

Notes=It is not strictly stdlib conform, because globals are in use.

I will check and verify that, before it gets added into the database.

Call for all library and function developers

If you are a developer of any function, then have it in mind others could use it with the stdlib mechanism. Every function should reside in a library (that is a file containing functions only). A library is stdlib compatible, if the main usable functions lead to automatically inclusion of the library.

Names: To avoid possible conflict, please see what others have done and which function names and prefixes they uses. Different libraries cannot share same set of names.
Script: Please do provide the needed information in a standardized way if it is possible. Most important infos which I cannot guess often are the date of last edit and the version. At least, one of them should be available.
Official example scripts would be good to have, but it is not required. If there is no one, I`ll create one.
What you should do allways is, making an external documentation. It does not need to cover every aspect, begin to write down the most important informations first.
License: And I beg you, please make a notice about what license your script uses. That is an often neglected part, which can cause serious problems. I recommend the GNU Lesser General Public License.
I found that related page: How to choose a free software license.

List of used prefixes and filenames

The prefix is the filename also. If a library does not have a prefix, duo to the fact it have only one function, then the file is named after the function without a prefix. In example Anchor.ahk does have one function named Anchor(). And the library ini.ahk have many functions prefixed with "ini_", i.e. ini_getValue().
For compatibility with these, you should choose another name for your files than these and another prefix (here in alphabetical order):
Count: 100

• A
• Affinity
• AHKHID
• AHKsock
• Align
• Anchor
• argp
• baseConvert
• CColor
• cdomessage
• CMDret
• CMDret_stream
• com
• ConnectedToInternet
• ConsoleApp
• Crypt
• DamerauLevenshteinDistance
• DateParse
• Delay
• difference
• Dlg
• dll
• Dock
• DockA
• Edit
• EmptyMem
• Eval
• Exec
• File
• FileExtract
• FileGetVersionInfo
• fileIsBinary
• Font
• ftp
• Functions
• Gdip
• GetAvailableFileName
• GetCommonPath
• grep
• HLink
• Hotstrings
• HtmDlg
• httpQuery
• HttpQueryInfo
• ILButton
• ini
• InternetFileRead
• IsFullScreen
• json
• LetUserSelectRect
• MCI
• MCode
• md5
• mg
• MI
• Mount
• msTill
• Notify
• pgArray
• ping
• PixPut
• ProcessInfo
• QPX
• Rand
• RandomUniqNum
• Rebar
• regionGetColor
• RemoteBuf
• RichEdit
• RPath
• SB
• sc
• ShellFileOperation
• ShowMenu
• Splitter
• st
• StdoutToVar
• StrGet
• StrPut
• strTail
• StrX
• sXMLget
• TaskButton
• tf
• ThousandsSep
• Toolbar
• ToolTip
• TrayIcon
• TVX
• type
• UnHTM
• USBD
• uuid
• VA
• WaitPixelColor
• WatchDirectory
• Win
• WinServ
• xpath
• yaml

See also, more material

Some tools using this "Ahk Standard Library Collection" as backend or base information center:
[Basic]AutoHotkey Help with Standard Library
These are not included. Either they are not tested. not compatible with my collection or need non standard DLL files:
LowLevel & dynamic code
Forms Framework
MS Office Automation Functions
.NET Framework Interop
Embedded Windows Scripting (VBScript & JScript) and COM
PPJoy library
Voice Recognition COM
WinTraymin to trayicon
Clock + cpu and memory usage
Interesting helper stuff for coders:
MCodeGen - Easily transform C/C++ code into mcode
Scriptlet Library
Easy Script Block Editor
WinAPI Listing [New Version]
U T e s t

 

Fantastic! Thank You! Continue this great project!

Thx for your encouragement. I made this to easier share our loved and often used libraries that everyone should know the existence of them. Hope more people find it useful.

One thing that bugged me allways is, that even our more great scripters dont specify a license. Also often there is no explicit date or version numbering founded. AND even sometimes it lacks a documentation!

Excellent program.

My only suggestion would be to have an install all option.

Ah install all... hmm may be i add that option. Does make it sense?
I have some other ideas like search and filter features. But that is not that important to me. The main focus is not the Library Explorer script, but the collection itself.

Hi Tuncay,

That is brilliant. Thanks a lot. I'll use it.
It should have link to update itself, or at least a link to its own forum post.

Nicely presented GUI and script.

I think the ini database would be easier to maintain if it identified the sections as [Lib LibFileNameNoExt] or similar rather than using sequential numbering. Here's one method (complete working example):

/*
[Lib $]
Abstract = Function Collection
[Lib Functions]
Abstract = Command Functions
[Lib INI]
Abstract = Basic Ini String Library
[Lib TF]
Abstract = Text file & Variables/String Library
*/

; Allocate a buffer likely big enough to hold all section names.
VarSetCapacity(names, 4096)
; Retrieve all section names.
DllCall("GetPrivateProfileSectionNames", "str", names
        , "uint", VarSetCapacity(names)//t_size()
        , "str", A_ScriptFullPath)

p := &names
; For each null-terminated substring up to the double-null-terminator ...
while (s := StrGet(p)) != ""
{
    ; Skip non-Lib sections.
    if SubStr(s,1,4) != "Lib "
        continue
    ; Read a key from this section.
    IniRead, abstract, %A_ScriptFullPath%, %s%, Abstract
    ; Show it.
    MsgBox 0, % SubStr(s,5), %abstract%
    ; Advance to the next section name.
    p += t_size(StrLen(s)+1)
}

t_size(n=1) { ; For ANSI vs Unicode compatibility.
    return (A_IsUnicode ? 2 : 1)*n
}
StrGet(p) { ; Script functon not required in AutoHotkey_L.
    return DllCall("MulDiv","int",p,"int",1,"int",1,"str")
}

... or you could ini_getAllSectionNames(), which is already included with your script.

Suggestions:
- The listview could have checkboxes so a user could select multiple libraries to install or check for updates.
- check if lib isn't already installed and indicate so in gui, perhaps directly in listview or in a separate tab "Installed libs"

Edit:
- Make sure all running examples are closed automatically when you close Library Explorer.ahk

Do someone use the stdlib mechanism from the installed AutoHotkey folder? I dont see a reason for checking that folder, which would make thinks much complicated. I just ignore it now. Its a basic script for demonstration reason (ok... not anymore).

I would like to have a filter system. I know I saw anywhere a working example with two lists. I think I did make a request for that in wish list...

@toralf
I am glad that you like it.
About self updating... I was never successful at making a self updating script. I need asstistance at that point.
And about the link to its own forum post... there is one, its small named to Home.

@Lexikos
At the beginning I had to decide if I use sequencial numbers or names as entry header (section). I decided for numbers, because the database should be accessible from any application. May be users decide to write their own script todo something specific with the library.

If I would have names, then the user must know which content it have before access to the content. For my ini library that is no problem. 8) :lol: :wink: The two (database file and script accessing the database) are nearly independant works.

But if you think it is really better, then may be I do it with names. currently I dont see any reason why.

And there is something...

; Retrieve all section names.
DllCall("GetPrivateProfileSectionNames", "str", names
        , "uint", VarSetCapacity(names)//t_size()
        , "str", A_ScriptFullPath)

:shock: :shock: :shock:
I wish I knew that earlier.

@hugov
- I am against multiple selections and installations. Then something like install all would be possible, but why? Why should someone install all libraries? The problem is to me, that the user of the project do not see the library as a individual work in that case.

- About the check of already installed libs, I think about it. Its a good idea to provide such an info "Installed Libraries" as an extra tab. Yes I like it. Thx.

- Closing automatically all example scripts at script exit is in planning. Also may be the button for Run Example would change to Exit Example or something.

Do someone use the stdlib mechanism from the installed AutoHotkey folder?

Yes, but only for scripts which are dependent on specifics of a given exe (standard AHK, AHKL ANSI or Unicode). For instance, CLR, COM and IsObject (standard AHK only: returns false). Unless you had some way to tell the script where the folders are and which build uses them, and then actually utilised this information, there'd be no point checking in my case.

However, I can see some use for an option to use the StdLib folder (i.e. the one along-side AutoHotkey.exe). I only use My Documents (UserLib) out of necessity - if I didn't, I'd have to duplicate a whole lot of scripts for each build. Others might prefer the StdLib folder or use it out of necessity, i.e. because they have multiple users on the PC using the same libs or they run AutoHotkey.exe on multiple PCs via a network share or removable drive.

This is really a great idea. I'm sure, most of us where missing such a function for keeping their libraries updated.

Unfortunately I have to keep this collection updated for the whole functionality. I would whish a function like the plugin manager of notepad++ <!-- m -->http://www.brotherstone.co.uk/npp/pm/<!-- m -->

This plugin essentially allows you to install, update and remove all the existing plugins, including itself, right from inside Notepad++. It will notify you when a plugin you use has been updated, and allow you to update it, simply by clicking the "update" button. The update can be delayed or ignored.
It has a centrally located list of plugins, which will be kept up to date.

Additional features:

Only plugins that are compatible with your Notepad++ are shown and installed
Install all supplemental files as well as the plugin file itself (e.g. config, doc, extra libraries). Also installs dependency plugins if any.
Validation of DLLs copied, against a central list of valid files. This slightly mitigates the risk of automatically downloading updates.
Proxies are supported, just change the setting

The database resides in the web and contains all links to all plugins. There are three tabs in the plugin-GUI, which all show the plugins with version, description and a comment about stabiltity:
- Available: shows all available plugins
- Updates: shows all installed plugins which have updates on the net
- Installed: shows all installed plugins

It would be great to have such a functionality. Of course it is nessessary, that all plugin-author keep their plugin-updates at the same place.

...und reichst du mir den kleinen Finger, will ich gleich den ganzen Arm

ruespe, that is currently impossible, because not all of the library developers are providing the needed information. I would collect all those and verfiy myself, that point did not need to be automated (of course would be better).

Some authors have links in the post to their scripts. An update to the script can make the post date of the link outdated. Or another one have the source in the post only, so I cannot write an auto-update feature.

This collection should not be seen as the only and best solution. It is a workaround until we get a better one. There is a related discussion about that topic, started by DerRaphael.
[*:1akdb691]stdLib: call for informationI think with this project it is best to stay as a predownloaded and by hand indexed archive. Sure, after some time passed, there will be allways outdated libraries. For now, we cannot do something about. Its the nature of this community. It lacks an organization, ... no one must follow any standard. That is allright to me. Everyone is welcome, otherwise new bees have problems with integration.

Date: 2010-03-01
Libs: 23

From History.txt:

* LIB: Added library Dock.ahk by majkinetor. (GUID=45A4EC6E-2393-11DF-98E1-539655D89593)
* LIB: Added library md5.ahk by SKAN. (GUID=D778ECFA-23F5-11DF-9285-3AAA56D89593)
* LIB: Added library st.ahk by Banane. (GUID=DE306F2C-2469-11DF-A591-656D56D89593)
* LIB: Added library ProcessInfo.ahk by HuBa and wOxxOm. (GUID=11B37928-249E-11DF-9745-E14B56D89593)
* LIB: Added library EmptyMem.ahk by heresy. (GUID=E3E60D1A-24AE-11DF-B2B2-A0BB56D89593)
* LIB: Added library DateParse.ahk by Titan. (GUID=98BC2FAE-24B3-11DF-BF95-525355D89593)
* LIB: Added library FileGetVersionInfo.ahk by SKAN, wOxxOm. (GUID=CB903340-24B7-11DF-8214-5D6D55D89593)
* LIB: Added library USBD.ahk by SKAN. (GUID=187D751A-24BC-11DF-A4AA-E88755D89593)
* LIB: Added library Affinity.ahk by SKAN. (GUID=54BA6EE0-24BF-11DF-AF06-D09B55D89593)

* DOC: Removed unneeded counter.js and pixel.gif from documentation of TF. (Thx hugov)

* GUI: Library Explorer completly rewritten and reorganized code.
* GUI: The compiled version of the Library Explorer is removed.
* GUI: Now all installed libraries are shown. (Thx hugov)
* GUI: Every examples process will be terminated automatically on exit of main script.

Please make suggestions for adding libraries.

This is really a good idea, I can see this becoming useful.

I would like to see a library for automating Explorer/File Dialogs/(context menus, I have a few functions, but they don't work in all cases. There is something like that from majkinetor, but it is outdated and doesn't properly support Vista/7. He said he was working (or wanted to) on getting it updated, but I don't know the current status of that.

@fragman
From which library do you speak?


Added following to the first post:
Call for all library and function developers

If you are a developer of any function, then have it in mind others could use it with the stdlib mechanism. Every function should reside in a library (that is a file containing functions only). A library is stdlib compatible, if the main usable functions lead to automatically inclusion of the library.

Names: To avoid possible conflict, please see what others have done and which function names and prefixes they uses. Different libraries cannot share same set of names.
Script: Please do provide the needed information in a standardized way if it is possible. Most important infos which I cannot guess often are the date of last edit and the version. At least, one of them should be available.
Official example scripts would be good to have, but it is not required. If there is no one, I`ll create one.
What you should do allways is, making an external documentation. It does not need to cover every aspect, begin to write down the most important informations first.
License: And I beg you, please make a notice about what license your script uses. That is an often neglected part, which can cause serious problems. I recommend the GNU Lesser General Public License.
I found that related page: How to choose a free software license.