DllStructSetData() instead of variables?

[Kip]

Hi

I know you can (kinda) store data in a struct.

But can you actually keep data in a structure?

Because, if so.. you can create some really cool arrays

Or is it slowing down the computer/program?

[SmOke_N]

Hi

I know you can (kinda) store data in a struct.

But can you actually keep data in a structure?

Because, if so.. you can create some really cool arrays

Or is it slowing down the computer/program?

Creating the struct globally then using DllStructSetData() would keep the data in the struct for the entire app to use.

Obviously making the struct local within a function, unless you pass that struct back as a return, the data would be destroyed.

The same rules would apply as other variables.

Gary did some nice work with the Structs in the struct include.

[Siao]

It's not much slower than using AutoIt arrays, from teh (rather limited) testing I did.

I had the same idea mainly because of ability to use memory pointers. Which it seems developers have no intention to make available for AutoIt's native variables, and that's a shame.

Too bad the DllStruct syntax is so bloated, and making function wrappers would add more overhead.

[Kip]

My idea was this:

In the first array type, data can only be "kept" in the last dimension,

In the second one (the one that can be created using DllStruct..) data can be stored in multiple dimensions. And every dimension can have a different count of elements.

It's just 'array in array', but using standard autoit arrays, the script would slow down.

Edited May 21, 2008 by Kip

[Jon]

At the moment structs are actually stored inside a hidden autoit array, so by storing stuff in a struct array, you are actually storing stuff inside an array inside an array...

Also, DLLStructs are ONLY designed to be used with DllCall - we had problems before when people used them as their own custom data storage.

[Kip]

So that basicly throws the whole idea of the table.