AutoHotkey Community

It supports highlihting in v2.0 which is now in testing phase.
I will check with author about font styles.

_________________

Dear majkinetor,



INI files are prehistoric, but I guess most AHK users prefer it over registry.



That is great news, irrespective of whether this control should be added into AHK.
Let me assert: I am not against your suggestion. Just feel it is less attractive to be built-in. As it is, the DLL and the wrapper will be useful to me.

Regards,

majkinetor, I'd like to see a side by side comparison with a RichEdit control also, if you get a chance. Although the source for this control seems small, I'm guessing that it would take a while to add to AHK internally as its functions would need to be wrapped to AHK's syntax. The question then is... why would it be beneficial to add the code for this control and wrap it for use in AHK vs wrap API calls for an existing RichEdit control?

Check out this place for RichEdit features:
http://msdn.microsoft.com/library/defau ... ntrols.asp

As I see it, RichEdit has in favor making words out of multiple fonts, tables and URL recognition

HiEdit doesn't have that so far but it has tabs, synt highlights, line numbering, its faster and lighter (written in ASM, RichEdit is written in C++, so the difference is pretty big).

It seems however that RichEdit is buggy and IMO it would be 50x work to add it then HiEdit. So, implementation time is very much on HiEdit side.




The bottom line is that HiEdit can be used for more serious things except writting poems (thx Laslzo for example). It allows syn highlighting of AutoHotKey language thus making possible to create AHK IDE with it. Isn't that very good thing ? I have never seen editor using RichEdit, probably cus of what akyprian said above. When we account extreme performance, what do you want more ? Contrary to what some say, its not easy to find so well written controls. This is probably the best as it can be (which I think is excellenet, as AHK performs so well, it would be pitty to change that by adding hungry controls).

Anyway, somebody just have to wrapp RichEdit and you will have it without language update. Then we can have them both, right ?


You have demo in ASM code. It is how HiEdit is used. I created wrapper out of that demo code in 2-3 hours (I droped some features not so important for first tests). So... what is hard in that ?

_________________

Majkinetor: We still have not seen a really good application of HiEdit from within AHK. An AHK IDE can be programmed with opening a stand alone editor and controlling it with an AHK script. A HiEdit control makes sense if many users put together GUI's with such a control. Really, what applications benefit from this?
- Do you want to present information nicely formatted? (With little effort text can be presented nicely now.)
- Do you want tabs inside the control, instead of the GUI? (Multi-level tabs are confusing.)
- Do you want line numbers? (Listview provides them with the ability of sorting.)
- Do you want syntax highlighting?

This last feature can be useful in a GUI teaching AHK coding or allowing easy testing of code variants. However, this kind of scripts are rare, and can use an external dll instead. Until someone comes up with an application many users would regularly implement, external dll's for different kinds of nice but rarely used controls present a better solution.

The question is not how good, fast, nice or small HiEdit is, but if a significant portion of scripts badly needs it.

Yes if you want to create it for kids.


Yes.
ListView ?



Yes.
They are not confusing if you have sense for design. Also, tabs are very popular now.


No. With little effort text can be presented nicely now.


Yes.


Just one application (the good one - more users EQ better AHK). You can easily create syn highlight for any purpose, (for instance configuration keywords)


Well, they are now, as there is no control to support it. Plus, AHK IDE can be created with it - HiEdit combined with SGUI - something most users need (would also open the dor to debuging, as Chris once noted)


Some animals more equal then others ?
Why did we have last AHK update for using scientific number format ? I dont recall anybody EVER used that here, excpet you, probably the reason why U pulled it on. I mean, wtf do I need scientific number format in AHK ? I am not going ot create banking sofwtare in AHK, right ? .... ah.....

Acctually, things you mention are most important, how good fast nice and small it is. As it is like that, it can not harm AHK, can only make it lot better. I seriously dobut you will EVER find such remarkable peace of software (in its domain)

_________________

With reason, as this format wasn't available. I tried to use it, and found it isn't implemented.
Obviously, it was just a little update of the number parser, and I doubt it added 1KB to the uncompressed exe...

I wouldn't use this format for banking application, I believe they use BCD or some other more reliable (no rounding error) format.

Frankly, you bury RichEdit control too easily, and I believe that Laszlo is right, there is more demand for the capability to display/edit "nice" text (wordprocessor-like) than for source code editor-like capability.

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

Hi again.



I didn't say "life" When I've needed RichEdit controls (standard of custom ones) I've used them, usually when programming in Delphi. It's simply that my use of AHK is more in the fields of keyboard modifications, small automations and prettyfied batch files.

And about the Edit control, it's not a question of liking or disliking. It is what it is, and it does what it does. There's nothing to like between anything. If you ask "which do you prefer?", my answer would be "to do what?".


I agree (talking about my personal needs here).

I have nothing against HiEdit per se. It looks like a serious piece of software, but I don't see the need to include it internally. Which was what the poll asked (and why I try to explain my "other"). Too subtle? Ok, change my "other" for "no".

_________________
Regards,
Antonio

The main reason I'd like to see a RichEdit control implemented is because a RichEdit control can be extended (with a simple API call) to hold up to 2 Gig (or more?) of data. That can be very handy when manipulating and displaying data in a GUI. The built-in features of a RichEdit control are also handy for formatting text (colours, html links, etc...).

Syntax highlighting can also be done with a RighEdit control. The reason people don't usually use it for editors isn't because of speed but because they would have to write the parsing and highlighting code themselves. Most people end up using a control that has built-in functions for highlighting instead. Some of these controls allow you to just drop a config file in a directory then init the control. This doesn't mean that syntax highlighting can't be done in a RichEdit control. Some of the syntax highlighting controls available are just subclassed RichEdit controls.

I don't think that being able to use syntax highlighting and add line numbers justifies adding the control that you are suggesting though. I realize that you would like to construct an editor but how many people here are likely to want to built a syntax highlighting editor using AutoHotkey? If the ability is possible using an external dll then that seems like a reasonable solution.

I think you're misunderstanding what I meant. Wrapping into AutoHotkey itself is a bit different. The functionality would need to be integrated with the GUI command(s) instead of being called directly. The question I was asking is why add extra code then wrap into the GUI commands when you can wrap a RichEdit control into the same command(s) without adding any extra code for the control itself? Wrapping a RichEdit might also be a bit less time consuming since many of the API calls are the same as for an Edit control.

2GB ?
I just tryed HiEdit with 120MB of data and it loaded it in 2 sec. If you only whisper to author that you want more inteligent loading I guess you will have it next version


I agree. Again, RichEdit can be wrapped, I don't see why Chris has to do this.

Not if you want to be serious. RichEdit obviously dosn't work correctly for anything more advanced then writting poems (again, thumbs up for Laszlo). Keep in mind that HiEdit does not have same purpose as RichEdit. The later is mostly for make up, the previous for everything else.


Like I said, I didnt' find any editor having RichEdit. So "most" isn't appropriate word. Its better to say that some n00bs use it.


What are you trying to prove ? That anything can be done? I know that.
BTW, subclassing isn't available in AHK and I beleive Chris is not particulary interested to do that.


The point is ahk being mature enough to alow creating its IDE in AHK itself (like Borland created Delphi IDE in Object Pascal, it seems to be good showcase and good ability to have for lausy 40KB)


Acctually, I gave you here only one control this guy crated. He has like bunch of them, I beleive more will come. For instance his Animated Gif control is only 9KB and supports things like zoom in/out.

If lets say 10 of his controls are added to the language this will create much better working environment. Summed togher, size will not be changed more then 100KB which is ridiculosly small comparing to benefits ppl will have.

The point is to recognise extraordinary things around us. Both AHK and akyprian can benefit from this, as two good things can be joined together to create better whole. You can be sure akyprian will bug fix, test and polish its controls, so this contrary to what you say, after initialisation realase work from Chris. Contrary to that, current controls are maintaned only by Chris, thus their maintance is time consuming.

Lest not discuss the fact that Chris can never crate in C++ nothing remotely fast as those controls akyprian creates.

_________________

No, I'm not trying to prove anything. I'm just pointing out the fact that syntax highlighting is possible using a RichEdit control and that people have created syntax highlighting controls from subclassing a RichEdit control. The point wasn't whether you can subclass in AHK (which is basically just wrapping existing functionality and adding additional features in a module...) but that it can be done with a RichEdit control. The basic functionality is already built-in.

We're not discussing Chris creating anything. We're discussing adding a custom control in AutoHotey vs adding a common Windows control to AutoHotkey.

That is exactly the point. The above states that syn highl can not be created in AHK succesifully, even if RichEdit was internal.


Oh yes we are. You see, Chris is the only developer of AHK. So if certain thing demands much time, it will not be there cuz of "energy budget" (pin this in your head). This means, that anything requireing more time will not be done. Also, in the light of things going on (version 2, stdlib, ...) if Chris even wants to add RichEdit it will not be available until those prioirities are done. So, currently, only things that can be imlemented fast can be added, that doesn' require more work on Chris later (like bug correcting , maintance etc..). In the akyprian case, this means that Chris should do wrappers for his superb controls and don't think about it ever else, except overwriting .lib when new version is created. He doesn't even have to create aditional interface for new version as if control is present internaly, you will be able to access new features by the means of standard messaging protocol.

Alternative would be some dll's to be shiped with AHK when stdlib finaly gets created, as Chris mentioned at the beginning, but I guess that will also rise new theories when time comes like "hej, I don't need dlls in stdlib"

Well, I don't want to discuss this any more.
I can not prove you my point, so you will all have to live in your theories. Good luck.

_________________

Preview of version 2 is available. Syn highgliting is added but I included only some AHK keywords. Other will be there when control is over.

Enjoy.

_________________

Could you provide a link?

1st posting includes the hosting.

Icfu

_________________