AutoHotkey Community

Thanks for putting together a list (although a rather small and incomplete one).

Although it doesn't make much of a difference to me, I'm curious. What would be needed for you to add the cGUI and RichEdit functions to your list? They already create a functional control and the current functionality is documented. A screenshot is available and a .zip file is available for download that contains the necessary files and examples. If there is something that doesn't meet your requirements then please let me know so that I can consider making the necessary updates.

2 corrupt
Can you select word in control and change its font ? The very basic feature of RichEdit. When it gets done, I will add the control.



I will soon create thread about what is needed for Natural Docs to be used with AutohotKey


Captcha is almost here, it just needs some tweaking. THere is a function named Random and function named Pass. Probably every second programmer has those in their own scripts. There is also thing that Titan mention about array of controls.. perhaps he can make it less error prone.


Not at all. I concentrated to collect all good controls created around with or without dll's. Of course DLL must be small, not big as AHK itself (acctually, all dlls at first post are probably around 100K together). Wrappers must not have globals that can interfere with outer world and some other things. How to write good wrappers is topic for itself and it should be explained in thread. However, I first wanted to see if smb has some suggestion or proposition for possible interface.

The bottom line is only that users of these controls will not have more pain than joy while using them. I am shure I missed something good so it would be good ppl point that to me.

_________________

In other words, globals must not be initialized in autoexecute section (outside functions) because some people like majkinetor prefer to #Include at the end of the script, where the autoexecute section is likely to be ended (and thus, globals are likely to remain uninitialized).
And any global (and function name) must have some prefix to reduce the risk of collision: instead of creating a SetNextUInt function, name it CreateWindow_IPA_SetNextUInt (ie. here I used the name of the AHK file as prefix). Same for label names!
That's where we regret not to have local functions, or namespace, or some other kind of encapsulation (like putting functions in a table, or in a class).

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

Exactly.

However its much more complex then that. OnMessage is particulary bad.
For instance if module needed to monitor WM_MOUSEMOVE it will remove user monitor. That's where we regeret not to have dynamic functions so we can do like




LOL.
What if you include 2 modules at the top of the script? You don't have to be majkinetor but it will still not work .

Acctually, "on top include" is good enough only for single include. Second, I would like to have insight about what is going on in MY OWN autorun section, perhaps I want to even use it ...

_________________

Well, if the autoexec section of the module is just a bunch of global variable inits, there is little risk. If it has any program flow breakage (goto, return, exitapp (!), hotkey (?) and so on, there is a risk, indeed, but mostly reflecting a poor design.

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

So you can make an initialization function that sets the needed globals:I've done that on a tooltip thing (I never finished it ) so that the user could set defaults for the rest of the functions by leaving those blank in that function.

_________________
Changed siggy at request of ahklerner

Well, it doesn't have to do with bad design at all.



Module1.ahk


Module2.ahk


So you see, moudle2 autorun will never get executed. What is more ugly, result depends on order of modules....

Initialisation function is the only solution.

_________________

What if you did something like:

Would execution continue with the next line after the #Include?

Anyway, script execution skips function declarations (right?), so this wouldn't even be necessary if the script has no hotkeys/hotstrings (as long as you don't write "return.")

Initialization functions aren't the only solution. That said, they are the most consistent solution, in that it doesn't matter where the user #includes the script - the init code will always run. (Assuming it is called by the module itself the first time a module function is used.)

You are kidding, no?
I put my test code at the end of the functions (you are upset by that) and it works fine.
This code is OK:

Of course, I agree that having a ModuleX_Init() function is cleaner, and more flexible (than autoexec or Gosub or imposed include placement).

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

I thought AHK stops AutoExecute section at first function decl...

_________________

No

_________________
Ciao
toralf

More info at: Using #Include to Share Functions Among Multiple Scripts

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

After reading this I have to say just that I am correct again. Not for functions though, but for subroutines. This probably made me think the same is true for the functions. ANother inconsistent AHK behavior if I am to judge.

_________________

Well you're not, so shut up just kidding

We could use a standard for sets of functions/custom controls... Like err... The name for a set of functions could be done by doing:Which involves 8 hyphens and the name of the set of functions, and w/e amount of hyphens afterwords (for me I use the line you can use on PSPad and put it to 40 and put hyphens to there, but not everyone uses PSPad, so w/e you think you need). Also for an individual function that a user would use should be formated like this:

Or an alternative xml format. It would really help out people who want to implement some controls, and a standard was somewhat requested, so I thought I would share an idea.

_________________
Changed siggy at request of ahklerner

If we use XML it should probably use a XAML/C# type schema since they're very comprehensive. Personally I would prefer a simpler text based format such as that of Natural Docs.

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.