AutoHotkey Community

Not really. As long as Gui variables exist, so will dynamic variables. I have no intention to redesign the Gui commands.
So what is the difference between a function and a command? They are implemented differently, but so are built-in functions and user-defined functions, or control flow statements and other commands. If a change in implementation does not effect a change in usage, is the implementation even relevant? Are we discussing the current incomplete v2 alpha, or what we want v2 to become?

I tend to loop csv column names and set them to named column ordinals

BS Code example

that way no mater the order of the columns sent to me the script correctly interprets data fill or read. there is a value to this level of simplicity

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

I don't like the DoubleDerefs/Dynamic Variables, but as long as there are "Commands" in the Syntax, I don't see any reason to remove them.

Remove this concept completely or let it be.

Commands provide under some circumstances simpler Syntax. Saying commands, especally the handling of gui commands, are noobfriendly is not that prooven as some people say. In my expirience this is something which can be truly improoved.



Using Commands to create a LV but being forced to use Functions to handle it is far away from being consistent. Using Commands with strange syntax to modify a Control is also far away being noobfriendly.

This is one part about usage. The other part about commands and the Gui handling is, it is very inflexible for advanced users. Guis and Controls should be Objects, which provides much better data structures. We can have a List of Controls - we can easy write some Layout-Manager for controls, as a Pane has a list with Child-Controls etc.

To not confront newbies with objects, one can provide a intuitive Syntax to handle them.

Creating a Gui without functionality is somewhat nice the way it is.
But if it comes to defining behaviors/actions like change something, it's getting very weird and unintuitive.


An OOP replacement takes out a lot of the magic. The following example can be combined with better and shorter syntax off course.

The point is, as an User I want to have a EditBox. I want to take this thing and do whit it whatever I want. This is the way humans work. We think in Objects, not in Functions

Using Objects is very intuitive, even for newbies. Objects are here to make things easier. Objects are much more "real" Things and therefore easier to understand for humans Writing Objects yourself isnt noob friendly, but is not required.

Setting the Value of a Text-Box is so much easier to understand, if you can say: "Well I have a TextBox called myedit and I want to set its text;

This looks much simpler, no external Function is needed.



They have different usage as functions. A User has to learn two things instead of one. Commands even are implemented a way which forces you to lookup their documentation to guess if an Expression or traditional String is expected.


About your clipboardall discussion. Whats the point? The Clipboard is an static Class/prefixed Function-Collection , which may have an method getBinaryData() for advanced useres.

Where "bin", which is a copy of the current Clipboard-Data, itself is a datastructure - be it a byte Array or a simple AHK Object which provides a possibility to get a pointer to the start.

_________________
http://securityvision.ch
AHK 2D GAME ENGINE

I agree with this. IMO, objects need to become integrated into the AHK more fully - including the training. Objects should be the next step after variables - essentially a slightly more powerful variable (newb thought process). Once the AHK community becomes as comfortable with objects as they are with variables, then the discussion to remove double-derefs could be had. Until then I cannot justify limiting varaible usage.

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

Sometimes I use it for a recursive function.
Besides that, I remember I found it useful a number of times. I'll post more examples when I recall it.

That isn't a double-deref. It just looks similar.

I may be misunderstanding the meaning of double-reference then.

Is this a double-reference?
And isn't this a double-reference?

@Guest: Both are double-derefs, since they make AutoHotkey dynamically look up a variable at runtime.

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

Then isn't %A_ThisFunc% a double-deref?

No. The way you're using it is just a dynamic call, which is not the same as a double dereference.

_________________

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