AutoHotkey Community

>It would be much more generally useful for SetTimer to accept a function and parameter
agreed. That's what i should have said.

>UrlDownloadToFile could easily serve as the basis for a built-in UrlDownloadToVar command.
agreed again. however, for dynamically generated urls, a javascript engine is needed... That is why i suggested edbrowse... But this is not so straightforward and probably not worth it. And tank's iweb is probably a better and more general solution anyways.

>There are many different ways to persist the state of variables, so I think it best be left up to scripts.
I don't think the user should have to bother with chosing between AxM, ini, sql, others... Its just a wild guess that making variable persistence mindlessly easy will make persistent data more accessible to user programmers.

>I believe the plan is to support associative arrays - i.e. arrayvar[somekey]:=somevalue. Why would "hashes ... be the most requested feature as soon as arrays are implemented"?
Nevermind. associate arrays are close enough.

I would presume some sort of hash table would be used internally for an associative array, but such details matter little to the user. Also, an associative array would have the property of random access, so it could function as a normal array - using solely numeric keys.

Personally, I would assume that after an associative array comes tree. There are many ways that a tree could be used (menus, folder structures, tree controls). With a tree data value, one could store and manipulate a temporary copy, and then "load" it into the correct place. For menu items, my menu wrapper can perform these tasks. For manipulating a tree control or file / folder structure, there already exist built-in functions / commands.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

• It's been mentioned around IIRC but haven't seen it on the list: a FOR loop with STEP option - remembering good ol' BASIC days.
• A way to retrieve and call a label by address (discussion)
• Debug function set: LogFile, filepath, options ; Log, On/Off. Would log to file the current line and the value of any variables processed by it

May be others worth mentioning but can't focus enough right now.

I wrote a function which handles for loops (yeah, I miss them too).

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Yeah but it's not as clear as

No offense.
I hope this gets implemented as it would also solve other issues such as the need to translate A_Index to zero-based index in certain situations without the use of additional variable var := A_Index-1.

try:

I think that has limited use compared to While, Repeat..Until/Do-Loops or C-style for. Also, the following are probably closer than tinku99's code:
That's a good point, but your example uses the additional variable. Perhaps an alternate syntax utilizing A_Index would be better, but I can't think of anything intuitive enough to be worth implementing over the existing methods.
I've already posted my views in that thread; I'll just add that I think it shouldn't be in the Top 40.
That could be done via AutoHotkey_L and DBGP.ahk (see also example). I think the binaries I've provided won't run on Windows 9x, but maybe you knew that. If you or anyone else would like to discuss either topic further, please post in the AutoHotkey_L thread.


Are personal feature requests really relevant to the topic of this thread?

Links have been updated for numbers 2 and 10. For-Loops have been added to proposed syntax, since it's been requested many times previously.

Not really; it's more useful for people to voice support for (or against) established requests, since new items won't be added to the list unless many users are in favor.

#10: I'm not in favor of more types of loops. The while loop is convenient for its readability, but adding extra syntax for For loops (with less readability) and Do...While (trivially different from While) seems to bring more cons than pros.

Switch/Case: I'm taking a neutral stance on this.

#5: I agree that these operators are valuable to have available inside expressions, though I wonder how the interpreter will distinguish the operators from variables with the same names...

And, incidentally, I posted a (tested) workaround for #35 here.

_________________
Ternary (a ? b : c) guide     TSV Table Manipulation Library
Post code inside [code][/code] tags!

I'm posting some PM correspondence I had with jaco0646 here regarding the Planned Features list, so forgive me if it's both on/off topic:

The list is both a good idea and a bad idea. It's a good idea in that everybody is allowed to give some input on what features and capabilities we can expect in the new version. It's a bad idea because the only people who are likely to contribute to that list are long-time users and/or people with programming experience. While their input is valuable, their skills (for the most part) have progressed well past the level of the intended end user.

The whole point of AHK is to extend the power of Windows commands and functions to a beginning user in a simple fashion. The beginning user knows what he/she wants but usually lacks a meaningful way to communicate it, and the more advanced user knows how to solve their problems but doesn't typically probe that problem to see a need within AHK itself. So with very few ways to gauge the needs of the intended end user AHK blossoms at the higher end of the spectrum and withers at the lower end.

I think in order to keep AHK relevant going into v2.0 we also need to be mindful of how the simple things for the beginning user get done, too. Maybe we can all browse Ask For Help to try to get some of those needles out of the haystack, I don't know, but the Planned Features list strikes me as top heavy on advanced features and little additional to offer the beginner.

I think in order to meet the need for advanced features to enhance the beginning user's experience (potentially as well as those of the advanced user), I can think of two things that should be considered for v2.0:

1. A new script writer with additional features such as the ability to suggest/add parameters to recorded commands and record controls under the mouse (if any) and offer options for what to do with them (anybody who's seen one of my back and forth's in Ask for Help trying to sort an ASW script into a more usable format knows what I mean).
2. Standardization/implementation of COM functions(particularly for manipulating IE and MS Office apps)

I don't know how feasible or even ideal such changes are, but, IMO, enhancing the new user's experience should be as big a goal as implementing new, advanced features.

But that's just one man's long-winded opinion.

_________________

Try Quick Search for Autohotkey or see the tutorial for newbies.

Looking at the list, I would make some changes to the ordering. I'd move "Support multiple mice and keyboards" from 2 to below "Unicode support." I also think the new syntax items listed at 10 should be higher.

I agree with sinkfaze that the the script writer needs a lot of work and often teaches newcomers bad habits that cause additional problems.

i want to be clear my responses to this have nothing to do with wish list items and everything to do with the type of support needs found in the ask for help forum

There needs to be more focus around office apps and web applications. Non gamers next most common automation needs are around this

Lets not overlook Der Raphael's httpQuery which with some enhancements could be mad to satisfy a whole range of web automation tasks
Segway:::: I know its been approached and Chris has made his opinion known and a general depth of understanding necesary to do so known as well. the post eludes me at the moment. Some level of COM support built in has been in a round about way requested thru the ask for help for couple years now. And while Seans library satisfies this for the most part.the concepts behind this and CLR. This may be a bit over the top and most users may not see the benifit of CLR but for sure the COM support would benifet all.


one of the more common things to do with text files are CSV
Chris argued the limited usefulness but all one has to do is see the half done CSV scripts and requests in the Forum for help to see the value.


I will add one other item that is a hot topic for corparate users who might use this as a tool with greater support from IT depts. I will not however re post the arguments they are well documented. a way to password protect and obfusicate un compiled scripts

One final and highly needed but it seems un mentioned part of V2 enhancements
A new recorder....

_________________
No matter what your oppinion Please join this discussion
Formal request to Polyethene

Doh i didnt see you posted on this subject as well :

_________________
No matter what your oppinion Please join this discussion
Formal request to Polyethene

Thank you to everyone for your replies. Your input is valuable; keep it coming.

Links have been updated for numbers 8 and 35. Updating AutoScriptWriter has been added to the end of the list. If anyone wants it moved higher, let me know.

The proposed new syntax (#10) is by far the most divisive item on this list. People either love it or hate it. There have been so many requests for it that I had to keep it in the top ten; however, almost as many people see it as superfluous “sugar” that only complicates the language. Considering the long history of discussions on this item, it would need massive support one way or the other to justify moving it out of the top ten or into the top five.

COM is always a hot topic on the help forum. While I don’t tend to get involved in those threads, my perception is that most users are satisfied with the libraries available (once they learn to use them of course). If more people think COM functions should be built into AHK, let me know.

It is my perception that Folks just need more friendly syntax and documentation on the subject. The use of the library actually complicates the learning curve some what. It took me months for instance to make the jump comfortable coming from a VB understanding

And i had gaps even then because there are limitations in AHK that even Sean cant easily script away. such as working with databases and testing for null records.

Testing objects is so much more difficult with AHK

I think you will find that there are a ton of folks who use it and dont post because they have accepted incorrect limitations. Standardized built in support for COM would remove this and make the language easier to support in a corp environment.

For most users it is to difficult to sort throu double posted questions in th threads misunderstood responses to make effective use. Then there is the fact that we are asking Sean to provide near solo support for such a critical element. All from a thread on the forum. Even then there are changes to numput and numget in the latest version of ahk which seem to have hurt the previous logic that allowed COM_Invoke to support large numbers. If Support for COM were built into AHK the likelyhood that future changes to AHK could so break existing functionality would not so easily be overlooked

_________________
No matter what your oppinion Please join this discussion
Formal request to Polyethene