AutoHotkey Community

_________________

I voted "no" in the poll because building this into AutoHotkey would increase the size of all compiled scripts by ~40KB. Even if it were omitted from compiled scripts, I wouldn't want its code in AutoHotkey.exe because it'd increase the memory used by every script (even when never called). Furthermore, AutoHotkey.exe becomes slower to launch as its file size grows.

To bring your work the attention it deserves, I've linked to it from the Edit control section:

We are talking here about several KB's.

I hope you are aware that AHK needs better text controls.
Benefits of this control, IMO, are multiple times bigger then drabacks.

Anyway, I beleive that in VISTA times, memory that we are talking about here is trivialy low. I also think you didn't check memory usage of HiEdit. TaskInfo here shows no difference when I run above basic script with and without HiEdit.

_________________

Do you happen to know HiEdit's license? I assume it's free, at least for noncommercial use, because I couldn't find any info to the contrary.

Yes, its free. I can ask author for more details if you like

I already asked him if he would have something to object about it being added in AHK and he said "not at all".

You should also recognise this man as one of the rare developers programing in ASM today for the sake of extreme optimisation.

You can see here our conversation

_________________

Thanks. By the way, when stdlib gets implemented (hopefully soon), this could be distributed with AutoHotkey as an external DLL with your API and documentation (if you wish).

Well, that is one alternative (the bad one )

_________________

It was just an idea.

Oh, good
I was afraid it is final decision

_________________

What box do I need to have performance problems with AHK? I am even running AHK on an antique PII 333.
I start AHK and swoosh – it's there, just like magic. What amount of performance degree we are talking about?

Well, I agree with majki. HiEditor rocks, so many advantages which are worth the downsides.

Including this control as an "alternative" doesn't sound too good to me, I would prefer to have this one by default and the present one as an alternative (or dumped because two documentations are confusing).

My two cents!

Icfu

I promise I will do AHK developer with debuging with this control, if you add it internaly. You know you said you will provide debuging commands once somebody is willing to abuse them... well after that, I am searching for good edit control ... so here it is.

I can imagine even nastier consequences, like integration of above with SGUI for ultimate IDE.

_________________

I voted Other, because I never had the need for such an edit control in AHK. I can always fire up Notepad or WordPad, if needed. They are standard Windows tools. If you need a better editor, there are many choices, and most of them can be controlled by an AHK script.

The added 50KB is not much by itself, but there are many controls even more useful, which could be included. Any nonstandard control (not in Windows) is better distributed in a library. It is not clear that a library (loaded only when needed) is considered internal AHK feature, or not. (I did not want to vote NO, because I don't like the standard edit control, but for short user I/O it is sufficient, and it does not consume extra memory.)

You can even use Edit in console if you like

The fact is that even Windows itself has better text controls internaly (RichEdit). Why they didn't to stick with Notepad?

So, the above means, that more complex Edit control (RichEdit in this case) is absolute minimum for programing environment, as OS'es by rules, always implement only what is abolutely neccessary, leaving higher abstractions to 3th party frameworks.


Can you point at some ? Or you just talk in general ?

I don't think that you can find me control that is so optimsed, so unversaly needed, so missing in AHK ... as HiEdit.

Of course, you can always provide links for 20 useful 40KB large, developed in ASM according to OS standards, controls to make your point stand.

I am waiting for the links

_________________

I don't mean HiEdit is not cool, but I have to distribute it with my compiled scripts. If it is in AHK, all the scripts, which don't use it get bloated. Using RichEdit costs next to nothing and users normally know, how to use it.

I don't know a good application of HiEdit. Do I ask the user to enter his favorite poem or write an essay or an AHK script? If I need complicated text editing I always fire up MS Word and cut and paste text to the desired place. This way I have spell checker in many languages, autocorrect, all of my text entry settings, column selection, tables, etc. But it is very rare that someone needs these from an AHK script.

A few examples are: New controls on GUI windows (Buttons, Statics, HMTL, RTF...), or Graphing Dll - RMChart.