AutoHotkey Community

It is currently May 24th, 2012, 1:47 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: September 4th, 2007, 3:09 am 
Offline

Joined: December 4th, 2006, 10:35 am
Posts: 561
Location: Galil, Israel
If file of the same name as the function does not exist in one of the library directories, every .ahk file in the library direcotries is searched, and the first function with the same name that is found will be used.



how to do it: at first need (first time name of function is not in script and not in libraries, load all files in libraries and parse the functions for names list. (Can limit to files which begin with LIB_ for example, to apply only to intentional multi-function library files).


why to do this: Most functions are included in 'mass' function ahk files such as "CoHelper.ahk", etc.


and..

Instead of having hundreds or thousands of unmanageable function files in the directory, can have a very organized useable LIBRARY SET, with simular functions included in same file.

_________________
Joyce Jamce


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: September 4th, 2007, 3:34 am 
Offline

Joined: November 2nd, 2004, 2:43 pm
Posts: 1019
Location: London, UK
this is already partially done, in the case of cohelper i believe the function call would be

Code:
cohelper_functionname()


at least i think that's how it works.

_________________
Steve F AKA Superfraggle

http://r.yuwie.com/superfraggle


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: September 4th, 2007, 4:42 pm 
Offline
User avatar

Joined: August 30th, 2005, 8:43 pm
Posts: 8620
Location: Salem, MA
you would have to edit the cohelper.ahk file to include a cohelper_ before each function definition if you were to use the existing functionality. Since cohelper was written before this method of the standard library was announced, it does not conform with the right naming.

Here are two posts by me that are related, each followed by a direct response from Chris.

http://www.autohotkey.com/forum/viewtop ... 403#129403
http://www.autohotkey.com/forum/viewtop ... 887#143887

I am still working out an example for Chris about the last one.

_________________
Image
(Common Answers) - New Tutorials Forum - Humongous FAQ


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: September 9th, 2007, 6:17 pm 
Offline

Joined: December 4th, 2006, 10:35 am
Posts: 561
Location: Galil, Israel
actually, don't think that is happening right now as:


1. Simple easy to remember functions such as BoardUP() hex() tooltips() undo() etc. etc.. don't meet the X_ functioname requirement

2. The ENTIRE X_ fileset is loaded in, not just the named function.. (ie. file size issues / load issues along with name conflicts issue.


forcing a structure of XX_function name to load a function from a library file, does not seem 1. Necessary, 2. helpful in many cases.


obviously, there can be multiple function names, (take the first one found, alphanumeric sort to load order of master files).

can even require a special name for master files, such as LIB_xxx

if does not effect the function names, doesn't matter what lib file is called.



again, if was not clear:

simple() + func() name() is **NICE**.

this is not the same as

LIB1_simple() + Lib2_func() Lib3_name() ... etc..


or, eg.

Invoke(xxxx) is amazingly cool, easy, flowing and only takes 6 keys


DOM_Invoke(xxx) is heavy, progrmatic, and complex. (and takes 10 keys)

_________________
Joyce Jamce


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: September 9th, 2007, 10:08 pm 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2537
One of the main concerns with the stdlib functionality is maintaining a reasonable level of performance. This is the reason that files are currently auto-included based on the function/file names. Searching through (loading then parsing) all files in a directory in search of a particular function then doing additional parsing to make sure that only that specific function gets included does not seem like it would be very efficient. Especially if multiple functions need to be loaded once the library gets fairly large. If this is not what you are suggesting then please clarify.

An alternative is to save each function in a file by itself and name the file after the function, if your goal is to only include that specific function instead of loading all functions from the file. This makes organizing functions a bit more time consuming though when they are part of a set. I'm slowly working on a project for maintaining stdlib files, importing functions from existing files, checking for conflicts, etc... that may make things much easier but due to a current lack of time available it may be quite a while before anything is available (unless someone else beats me to it ;) ). This method avoids the possibility of function name conflicts but is probably not practical without an application available for managing/organizing the files.

An option that might be very handy if included in AutoHotkey might be to have autohotkey look for a filename in a specific subdirectory in the stdlib if the prefix matches a directory name. In other words, if a function was named X_Hex() and a directory named X exists, then search for a file named Hex.ahk in the X directory. This way the files in a set can be placed together but then only one function gets loaded. This wouldn't solve the issue of having to specify a prefix though.

If you don't mind all functions in a file from being loaded then you can create a dummy function inside the file. For example, you could create a function called init() inside the cohelper.ahk file that does nothing then call cohelper_init() near the beginning of the script before calling any functions inside cohelper.ahk. Another option is to rename the cohelper file to coinitialize.ahk (assuming that you must call this function before any other functions in the file can be used - if that's always the case. I'm not that familiar with it yet). This will force all other functions in the file to be available for use without having to specify a prefix for each function.

Unfortunately, there does not seem to be a practical/efficient option available to allow a single function to get loaded from the library by itself when the function is buried in a file that contains many other functions without loading them all. Only searching through files with a prefix would be unlikely to be much more efficient since anyone submitting a file containing more than one function would likely start using that method and then most files would end up being searched.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: September 10th, 2007, 12:25 am 
Offline

Joined: December 4th, 2006, 10:35 am
Posts: 561
Location: Galil, Israel
corrupt wrote:
One of the main concerns with the stdlib functionality is maintaining a reasonable level of performance.


careful not to confuse STANDARD libraries with a library function generally. Since it is unknown what a user will have as 'personal' or 'local' function names, most standard libraries should use NON-STANDARD function names. DDE_Execute() for example. DDE_xxx... is a good thing for *most* standard libraries.

but.. (1) super special functions that are like an add-on to AHK itself, such as Sean's "Invoke()" ... likely should be named as simple as possible, ie. just like any other built-in AHK name.



Quote:
Searching through (loading then parsing) all files in a directory in search of a particular function then doing additional parsing to make sure that only that specific function gets included does not seem like it would be very efficient. Especially if multiple functions need to be loaded once the library gets fairly large.


actually should not be such a big deal at all. The trick is simply to CACHE the function names during 'pre-compile' or 'file-prep' stage.


In fact, the *only* change necessary, is to allow one (or more) GLOBAL LIBRARIES to work just like the XX_name setup in place now... but if no XX_, then search in 'global' library master file instead of "XX_" file...



hope that makes more clear sense....

_________________
Joyce Jamce


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: September 10th, 2007, 2:30 am 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2537
Joy2DWorld wrote:
careful not to confuse STANDARD libraries with a library function generally. Since it is unknown what a user will have as 'personal' or 'local' function names, most standard libraries should use NON-STANDARD function names. DDE_Execute() for example. DDE_xxx... is a good thing for *most* standard libraries.

but.. (1) super special functions that are like an add-on to AHK itself, such as Sean's "Invoke()" ... likely should be named as simple as possible, ie. just like any other built-in AHK name.
So, why would something like Invoke() be any different? Why should it not be something like Com_Invoke() ? ...and, more importantly, how does this change anything? It is currently possible for you to organize the Lib (either of them) to function either way by following the suggestions I gave in the previous post.

Joy2DWorld wrote:
Quote:
Searching through (loading then parsing) all files in a directory in search of a particular function then doing additional parsing to make sure that only that specific function gets included does not seem like it would be very efficient. Especially if multiple functions need to be loaded once the library gets fairly large.
actually should not be such a big deal at all. The trick is simply to CACHE the function names during 'pre-compile' or 'file-prep' stage.
I think you're missing the point and not seeing the big picture here. AutoHotkey does not currently parse through any of the files in the Lib directories to determine if it needs to #Include a file. AutoHotkey only searches for a file with the same name as a missing function with a .ahk extension. In the case where a function has a prefix, AutoHotkey does not search through the file containing the prefix.ahk to determine whether the function is actually in the file. It just #Includes the entire prefix.ahk file if it exists in the Lib directories. What you are suggesting is to parse through all the possible files in the directory one by one to determine which functions they include. This will obviously take considerably longer as the Lib directories get larger than simply searching whether a file exists in the diectory with a particular name.

Joy2DWorld wrote:

In fact, the *only* change necessary, is to allow one (or more) GLOBAL LIBRARIES to work just like the XX_name setup in place now... but if no XX_, then search in 'global' library master file instead of "XX_" file...
Again, I think you have misunderstood. Files are not currently being searched to see if they contain a specific function.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: September 10th, 2007, 4:30 am 
corrupt wrote:
Joy2DWorld wrote:

In fact, the *only* change necessary, is to allow one (or more) GLOBAL LIBRARIES to work just like the XX_name setup in place now... but if no XX_, then search in 'global' library master file instead of "XX_" file...
Again, I think you have misunderstood. Files are not currently being searched to see if they contain a specific function.


Thanks for fixing my incomplete...


right now, the functions in the file are being parsed.

instead of loading them all as functions in the script,

simply cache them.

if a function name matches that requested,


load that function.


parsing only occurs once. (per master library file).

this is occuring right now with the xxx_ function.



hopefully now this is more clear.


Report this post
Top
  
Reply with quote  
 Post subject:
PostPosted: September 10th, 2007, 2:09 pm 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2537
Not exactly. At the moment the entire file is being #Included as if the user had added an #Include command for the file with the same name as the function (or the file with the prefix.ahk). It's not just the functions that are being parsed in the file(s). The entire file and any/all syntax is being loaded as part of the script (basically merged at the end of the original script AFAIK).


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group