Can we talk about dll structs and pointers in autoit?

[markyrocks]

Ok so I maybe wrong about some of this stuff so please correct me or rearrange my thought process as necessary.   

I've been playing around with structs alot and in autoit  it seems like the only real intended purpose is for working with outside dll calls that I guess require a struct or struct pointer as a function argument or as a buffer for a return value.   I'm tired so this might not be completely accurate.  I've used structs in other languages and again I could be wrong but it seems in other some other languages  that they're a way to group data or functions or maybe both as a way to quickly access data or have one variable with multiple values.  Also a big part of why structs exist is for efficiency.   Like if you have an array it's a type of data structure usually to access the information contained within it has to be looped though to find the relevant data.  But with a struct you can point directly at the data instead of looping though.  Obviously this can be done by using the specific element of an array but it's much easier to use.  If you have 10 arrays and the 1st element is equal to a person's name,  second element age, 3rd address ect.  Its obviously easier to use Array.age to get the underlying data than $Array[1].  I even had to look back to see which element it was.  This obviously can get very confusing if you're using 20 or 30 elements.   It would probably make more sense to assign array to an element number and use age as the array and point directly at it via $age[$array].  But that screams of confusion.  It also goes against the grain of how we view objects with attributes.   Age is an attribute of array not the other way around.  Now obviously we dont access struct data in autoit via struct.element.  I'm working on a solution to get closer to that.  I don't even know how useful or popular it will be but I definitely feel like it could revive dll structs in autoit and actually make them a useful data storage method.  

Ok so anyways,  that kinda brings me to my next point and that's about pointers to structs.  I just reread the section about dllstructgetptr().  This is the most frustrating thing for me.  Bc it relates to the ability to have reasonable nested structs.  Bc literally it would be as simple as just making a struct with the elements being the names of other structs and the data being a pointer to the nested struct....That would be great but as far as I can tell theres no way to use the pointer to a struct to access the data within.   I've even gone as far as opening up the process of my own running script and opening the pointer with a memory read.  This might be plausible but I can't figure out how to decode the underlying data... this is all highly unnecessary and overly complicated.   But obviously autoit doesn't have a method to type cast a variable as another type or an obvious way to dereference a pointer.  Well or even a realistic way to  go from a variable to a pointer and back well unless it's an int.  I played around with it and the ptr() function is basically worthless.  Apparently it creates a 1 byte pointer but again not very useful.  Literally I don't even know why it exists.   

 

I think I might have an idea.  Speaking about nested structs and pointers.  The example shows using a pointer to an array to create a 2nd and 3rd array in the same memory address.... it might be possible to use the pointer to an array to create like a shell struct around it and then have access to the underlying data of the original.   The only issue is that the 2nd array might prevent the data from being pulled out bc of mismatched datatypes or the size of the elements....  hmmmm very interesting.  I'm going to have to mess with that.  I'm glad we had this talk.

 

 

[markyrocks]

ya this is pretty cool this does actually seem to be working.  Shockingly!!!! I can't believe it. 

expandcollapse popup

Global $2d[5][2]
$2d[0][0]="john"
$2d[0][1]=19
$2d[1][0]="frank"
$2d[1][1]=-1
$2d[2][0]="mark"
$2d[2][1]=True
$2d[3][0]="tom"
$2d[3][1]=15.76654
$2d[4][0]="Popeye"
$2d[4][1]="another string inside of a struct"


Test()

func Test()
$tag="struct;int;int;bool;double;char[128];endstruct"

$New_Struct=DllStructCreate($tag)

for $n=0 to UBound($2d)-1
    DllStructSetData($New_Struct,$n+1,$2d[$n][1])

    Next

$pointer=DllStructGetPtr($New_Struct)


$DummyStruct=DllStructCreate($tag,$pointer)

if @error<>0 Then
    MsgBox('','','struct failed to create')
Else
    $dat=DllStructGetData($DummyStruct,5)

MsgBox('','dat',$dat)
    EndIf

$DummyStruct=0
$New_Struct=0
endfunc

I have no issue saving the tags for structs that are created so as to make a dummy shell over top of them.  If i tried to retrieve the data using a element name instead of a number it wouldn't give me nothing but i'm assuming if i can store the tags then creating dummy shell struct using the names as retrieval mechanisms shouldn't be an issue.  Im pumped bc this saved me alot of pain and aggravation. I am learning alot which is kinda the whole point of this.

 

I've continued messing with this and Yes you can definitely store pointers to structs within structs so nested structs wont require just adding on to the end of an existing struct.  I just finished writing my function that gets data out of nested structs.  I'm assuming that i can get it to the point where the program i'm writing can create and set data to structs within almost infinitely and retrieve the data aswell.

Edited January 5, 2020 by markyrocks