[Wish] PrintArray / ArrayDisplay (gui)

[jNizM]

Wish for v2:
A build-in function to display arrays (similar to _ArrayDisplay() from auto it) in a small gui+listview (or an other alternative way to display) for fast debugging.

Examples for function name:
- PrintArray()
- DisplayArray()
- ArrayPrint()
- ArrayDisplay()

Examples for display:

Code: Select all

arr := ["a", "b", "c"]

column 1 | column 2
--------------------
1        | a
2        | b
3        | c

Code: Select all

arr := {a:"1", b:"2", c:"3"}

column 1 | column 2
--------------------
a        | 1
b        | 2
c        | 3

Code: Select all

arr := [{Var_A:"a", Var_B:"b", Var_C:"c"}, {Var_A:"A", Var_B:"B", Var_C:"C"}]

Var_A    | Var_B    | Var_C
-------------------------------
a        | b        | c
A        | B        | C

[lexikos]

Why v2?

Why don't you just write a script to do it?

[Nextron]

Not exactly in a table or built-in, but I think that can get messy quickly. You can use this as a starting point:

https://autohotkey.com/boards/viewtopic ... 270#p78270

[lexikos]

This is an example of why it should not be built in. The best way to present the array's contents may depend on personal preference and/or the meaning of the array. If there's a built-in function which presents it in a basic table, that function becomes dead weight as soon as someone makes a script that presents it in a better way or offers better functionality.

What if you want to modify the array?

DebugVars.png (4.11 KiB) Viewed 7686 times

[guest3456]

This is an example of why it should not be built in. The best way to present the array's contents may depend on personal preference and/or the meaning of the array. If there's a built-in function which presents it in a basic table, that function becomes dead weight as soon as someone makes a script that presents it in a better way or offers better functionality.

i don't think thats a good reason why it should not be built in. we've come up with better ways to do Pixel/ImageSearch, are those built-in commands now dead weight? i don't think so.

the question as usual is whether or not its worth your time to implement something like this. only you can answer that. i dont see this as a huge need, especially when there are numerous scripts that already do it (see GeekDude, HotKeyIt, tidbit). but i know i do find it handy when using php to quickly dumb the array contents for debugging purposes

[nnnik]

i don't think thats a good reason why it should not be built in. we've come up with better ways to do Pixel/ImageSearch, are those built-in commands now dead weight? i don't think so.

These Commands greatly simplify the Task of doing what they are doing. They are meant for newbie users to make it possible for them to do what AHK is build for.
A Function that displays the content of an Object is not necessary for AHK to work like it should. Only an advanced user could understand what it outputs. Such a user could build such a function for himself.

[Coco]

I am neither for nor against the request but I think that a built-in object stringification/serialization function would me more useful and flexible compared to the display in GUI stuff. You can use the function for debugging(display output in GUI, stdout, MsgBox, file, etc.), as an alternative to INI/XML(you would need a parser to read it back though), etc.

Alternatively:
Using print() you can use the ff helper function to display any value(strings, numbers, object/arrays, Func, ComObject, etc.) in the script's main window:

Syntax: Puts( Value [, Indent , SecondsToWait ] )

Code: Select all

#Include <print>

puts(value, indent:="", wait:="")
{
    static offset := A_AhkVersion<"2" ? -2 : -3
    if (Exception("", offset).What != "print")
        return print(value, Func(A_ThisFunc),, indent)

    prev_dhw := A_DetectHiddenWindows
    DetectHiddenWindows On
    value := RegExReplace(value, "\R", "`r`n")
    ControlSetText Edit1, %value%, ahk_id %A_ScriptHwnd%
    DetectHiddenWindows %prev_dhw%
    if !DllCall("IsWindowVisible", "Ptr", A_ScriptHwnd)
        WinShow ahk_id %A_ScriptHwnd%

    WinWaitClose ahk_id %A_ScriptHwnd%,, %wait%
}

Copy them both into your User Lib and you should be good to go.

[lexikos]

@nnnik: I agree.

i don't think thats a good reason why it should not be built in.

Virtually any reason outweighs the reasons (that weren't given) for making it built in. Here are some more:

• There are hundreds or thousands of users capable of implementing this request as a script, and only a handful capable of implementing it in C++ (even fewer willing/likely).
• It would be easier to implement in script.
• As a script, it can easily be modified or extended to fit the purpose or preference of the user.
• I'm not going to develop a feature that I'll never use because it's already obsolete.

we've come up with better ways to do Pixel/ImageSearch, are those built-in commands now dead weight?

They are to me and to every other user who never uses them, whether because they use something better or because they just don't need them.

I don't think your comparison to ImageSearch is relevant;

• Unlike ImageSearch, this request does not require high-performance code.
• At the time ImageSearch was implemented, it wasn't even possible to call external dll functions or machine code functions (which I assume are used by the "better ways" you mentioned)-- adding it to the program was the only way to get that functionality with adequate performance.
• ImageSearch wasn't obsolete when it was added; this would be.
• ImageSearch is more useful and more central to AutoHotkey's "mission" (automation).
• ImageSearch is more difficult to implement, but is easier in C++ than in script, unlike this request.
• ImageSearch must remain for backward-compatibility, at the very least.

I think that a built-in object stringification/serialization function would me more useful and flexible compared to the display in GUI stuff.

That seems more suitable to be built-in than the original request; if implemented, it could be utilized by ListVars.

However, a user-defined function would be just as useful and more flexible. A built-in function just would be more available/portable (and faster, but that's irrelevant if the function is used mainly for debugging). On the other hand, built-in functions don't interfere with ListLines or line-by-line debugging.

[kczx3]

This is an example of why it should not be built in. The best way to present the array's contents may depend on personal preference and/or the meaning of the array. If there's a built-in function which presents it in a basic table, that function becomes dead weight as soon as someone makes a script that presents it in a better way or offers better functionality.

What if you want to modify the array?

DebugVars.png

I've never seen a control look like this in AHK. It appears it is a combination of a treeview and listview, correct? Can you point me to any existent documentation regarding how to achieve this? Thanks!

[guest3456]

I've never seen a control look like this in AHK. It appears it is a combination of a treeview and listview, correct? Can you point me to any existent documentation regarding how to achieve this? Thanks!

thats actually a really good point that i had originally missed

i had been looking for a gui control like that forever, and i had assumed that you had to do some fancy subclassing to accomplish it

Lex, can you post the code for that sample script?

[kczx3]

Tapping into this could be a viable alternative if I could figure out the whole .NET Framework Interop, http://www.componentowl.com/better-listview

[lexikos]

It's just a ListView with indented items and icons. The tree structure works by adding and removing rows. It's not really reusable as a control since I designed it as a standalone GUI for use in debugging. I have a bit more work to do on a related project, then I'll release the code and maybe someone can make it usable as a control.

[guest3456]

I didn't know that ListViews could be edited outside of the first column

[lexikos]

What I meant was: It's just a ListView with indented items and icons... and an Edit control.

[lexikos]

I didn't know that ListViews could be edited outside of the first column

Actually, it seems just me had already written a library for that, and is currently looking for testers for a new version.

[lmstearn]

Perhaps a function just to dump the entire array as a string- separators and all?
Handy when dealing with value fields in ini files, for example.
Although in this case, SO has a quick solution, so not a major drama.