Data records with Array

[Jemboy]

Hi, 

About 25 years ago I used to use (Turbo) Pascal about the sameway I use AutoIt now. Building little tools to make life easier.
I remember, Turbo Pascal had data records, you could use with arrays and if memory serve me, you could even save en read the records to/from a file.

See example at: http://pascal-programming.info/lesson11.php

A Record is a datastructure with some variables in it, making it easy to manipulate.
You could send or return a record to/from a function, so you don't have to work with global variables when you have to return multiple variabeles.

You could read a bunch of recordsets as an array and just use MyArray [1].Name and MyArray[1].Surname,
instead of MyArray[1][0] and MyArray[1][1] etc. making the source easier to read.

 

My question, is something like records implemented into Autoit, is there somekind of UDF that will do the trick or
is these feature somehow planned for the future?

Regards,

Jem.

P.s. sorry for using the link, but I started explaining this record thing and found that the link eplainded it better than I could ever do!

 

 

 

 

 

 

 

[RTFC]

Check out DllstructCreate and related functions in the Helpfile

[Melba23]

Jemboy,

You could look at the experimental Map datastructure - this thread explains all that is publicly available about them.

Personally I still tend to use arrays and Enums to make the code easier to follow:

#include <MsgBoxConstants.au3>

Enum $eName, $eSurname ; Set to 0, 1



Global $aNames[2][2] = [["Fred", "Bloggs"], ["Dora", "Smith"]]

For $i = 0 To 1
    MsgBox($MB_SYSTEMMODAL, "First", $aNames[$i][$eName] & " " & $aNames[$i][$eSurname])
Next

M23

[jvanegmond]

AutoIt beta added a Maps feature which is an excellent drop in replacement for this. It's not identical, you won't have any compile time checking done on the names used, but it's definitely a handy thing to have and may solve your use case.

Dim $myBookRec[]

$myBookRec.Title  = 'Some Book'
$myBookRec.Author = 'Victor John Saliba'
$myBookRec.ISBN   = '0-12-345678-9'
$myBookRec.Price  = 25.5

ConsoleWrite('Here are the book details:' & @CRLF)
ConsoleWrite(@CRLF)
ConsoleWrite('Title:  ' & $myBookRec.Title & @CRLF)
ConsoleWrite('Author: ' & $myBookRec.Author & @CRLF)
ConsoleWrite('ISBN:   ' & $myBookRec.ISBN & @CRLF)
ConsoleWrite('Price:  ' & $myBookRec.Price & @CRLF)

[JohnOne]

You could also use a scripting dictionary object, which I suspect pascal may have been using.

[jchd]

The nearest AutoIt construct is DllStruct but note that you have to declare each of them explicitely if you want to make an array of them.

Maps aren't close to Pascal records.

[FaridAgl]

A dev suggested DllStruct?

[jchd]

A dev??? What do you mean?

[RTFC]

@jemboy: you can stick a struct directly into an array, and then access specific fields within the struct, for any desired record within scope, with DllstructGetData/SetData:

Local Const $tagSTRUCT1 = "struct;int var1;byte var2;uint var3;char var4[128];endstruct"
$maxrecords=10

; create data struct for each record
Global $records[$maxrecords+1]
For $rc=1 To $maxrecords
    $records[$rc] = DllStructCreate($tagSTRUCT1)
Next
$records[0]=Ubound($records)-1

; load some content
DllStructSetData($records[1],"var4","lastname1")
DllStructSetData($records[2],"var4","lastname2")
DllStructSetData($records[3],"var4","lastname3")

; retrieve a field for a specific record
$myrecord=2
MsgBox(0,"struct in rec " & $myrecord,DllStructGetData($records[$myrecord],"var4"))

 

Edited June 7, 2015 by RTFC

[FaridAgl]

A dev??? What do you mean?

Sorry, my miss.

[Melba23]

RTFC,

While I appreciate that you can use Structs to store data, this has always been strongly opposed by the Devs on the grounds that the internals of Structs are not documented other than as a way to pass parameters when calling a DLL.  I kept this quote from Jon when the subject was raised a while ago:

The big worry - and something Valik pointed out in priv-devchat - is that without doubt people will [..] create some hybrid datatypes that are vaguely documented and unsupported. They'll be used with other features in unsupported ways and then we get trapped when we try and change some behaviour that was undefined anyway. They'll definately be used outside of the scope of just being passed to DllCall.

So I would absolutely NOT recommend using them in this way - and certainly not expecting any form of support, or sympathy if they suddenly no longer work as expected.

M23

[RTFC]

@M23:Sorry, I was unaware of this discussion and that the approach I suggested was frowned upon. However, using structs themselves as containers for multiple fields of different type is documented, and they offer quick access to individual members. I personally use them in various languages for storing associated bits of data; I wasn't aware I was falling foul of canonical use of AutoIt in this.

Edited June 7, 2015 by RTFC
typo

[jchd]

If DllStruct stop working the way they work today there will be more than unexpected behaviors. For instance would _WinAPI_WriteFile stop working when it's passed a DllStruct, which is readily used in some standard includes and Wrapper, to say the least? That is exactly what the OP could be using DllStruct for. Also would the large number of DllStructs used in other WinAPI calls stop working?

For me DllStructs are containers which can hold data under a strict format definable by users with well documented basic types. Maybe both Valik and Jon feared completely different [mis]uses, but certainly not this one.

[RTFC]

@jchd: thanks. I was sort of hoping/expecting you'd see it that way too. But I think Melba's point in removing my post was more specifically aimed at the example script I posted, which could be/was apparently construed as subverting the proper AutoIt way of defining a single struct in a stand-alone variable for Dll parsing, and thereby (inadvertently) advertising a type of usage that the devs would rather discourage. Your broader definition certainly fits my own coding style, though. But I don't know enough about AutoIt's internal workings to be able to judge whether the devs' concerns are legitimate here. Let's just leave it at that. After all, I was only trying to help the OP, and such a fundamental, universal data container as a struct seemed a more obvious suggestion (to me) than a beta feature.

Edited June 7, 2015 by RTFC

[Melba23]

RTFC,

Melba's point in removing my post

Just to be clear, I have not removed anything at all in this thread - all I did was highlight the opinion of the language author, which I thought might be of interest to any reading.

  I don't know enough about AutoIt's internal workings to be able to judge whether the devs' concerns are legitimate here

However the Devs do know and they discourage such usage - that is good enough for me. But I said above, there is nothing to stop you doing whatever you want - just expect neither support nor sympathy if there is an internal change which still allows Structs to be used for calling DLLs but breaks any code you have previously written.

M23

Edit: Another (ex)Dev who also thinks it is a bad idea: 

Edited June 7, 2015 by Melba23

[jchd]

The main points remains that the OP asked for an AutoIt construct similar in essential properties to the Pascal record and this does have an answer: DllStruct are just doing that, keeping in mind that they are an equivalent to C structs but not to C typedefed structs.

What DllStructs are not suitable for is when one expects to use them for, say, masquerading the inner layout of objects or similar acrobatic tricks. This is the kind of sideways use that I believe Valik and Jon had in mind. That or doing tricks with the stack or even more dangerous misuse. Agreed, AutoIt isn't the language of choice to rewrite Stuxnet.

I'd like to see a rebutal to the fact that they can be used (and are used today) to pass data to _WinAPI_WriteFile and from _WinAPI_ReadFile as an opaque binary container (address and size). This is all the OP wanted and I see no reason why such legitimate use should be discouraged.

Yet again I must warn against the fact that, contrary to Pascal records, assigning an existing DllStruct to another variable doesn't create a distinct copy of the DllStruct, but a clone of the original struct based at the same address.

Local $tBuf = DllStructCreate('dword')
DllStructSetData($tBuf, 1, 1234)
ConsoleWrite(DllStructGetData($tBuf, 1) & @LF)
Local $tBufCopy = $tBuf
DllStructSetData($tBuf, 1, 5678)
ConsoleWrite(DllStructGetData($tBufCopy, 1) & @LF)

 

[LarsJ]

I think the OP asked for something like this:

Local $tagMyRecord = "int Integer;double Real;char String[128]"
Local $aMyArray[3] = [ DllStructCreate( $tagMyRecord ), _
                       DllStructCreate( $tagMyRecord ), _
                       DllStructCreate( $tagMyRecord ) ]

$aMyArray[0].Integer = 1234
$aMyArray[0].Real    = 1234.12
$aMyArray[0].String  = "This is string 0"
$aMyArray[1].Integer = 5678
$aMyArray[1].Real    = 5678.56
$aMyArray[1].String  = "This is string 1"
$aMyArray[2].Integer = 9090
$aMyArray[2].Real    = 9090.90
$aMyArray[2].String  = "This is string 2"

ConsoleWrite( $aMyArray[0].Integer & @LF )
ConsoleWrite( $aMyArray[0].Real    & @LF )
ConsoleWrite( $aMyArray[0].String  & @LF )
ConsoleWrite( $aMyArray[1].Integer & @LF )
ConsoleWrite( $aMyArray[1].Real    & @LF )
ConsoleWrite( $aMyArray[1].String  & @LF )
ConsoleWrite( $aMyArray[2].Integer & @LF )
ConsoleWrite( $aMyArray[2].Real    & @LF )
ConsoleWrite( $aMyArray[2].String  & @LF )

 

[RTFC]

@Melba:When I was reading this thread yesterday, the post with my example had somehow disappeared, and as this occurred right after you posted your response, I interpreted this (wrongly, as it now turns out) as you having made the decision to remove that entry. Sorry for the confusion. And I take the point about lack of future support, but this basically holds for any part of the language (I remember _Iif() disappearing). But I'm with jchd on structs; I cannot imagine that one would restrict their usage to transient dll I/O receptacles only. Using them as semi-permanent data records in memory would seem fair use to me, and in keeping with all other languages that support them. I also have difficulty imagining how dll-associated use could be kept intact while use as a more permanent storage container would disappear. Whether or not it is wise to stick a struct in an array cell is a far more thorny (and technical) issue, and I'll take it from you that the devs have good reason to discourage this. I was certainly not aware of this. But (at least for my applications) it would be a fairly trivial patch to avoid such usage, if support for it were to be discontinued.

As an aside, I cannot find any mention in the Helpfile that structs should not be used as aggregate data containers in general, but maybe I'm looking in the wrong places.

@jchd: I find struct pointer cloning in the way you describe a highly useful feature, actually; it allows separate UDFs to use their own internal referencing conventions to alter a shared data space, and provided these UDFs are part of the same executing thread, you don't need a mutex..

@LarsJ: interesting notation; never used that.

Edited June 8, 2015 by RTFC

[Melba23]

RTFC,

No problem - I was just trying to make sure every one had the "bigger picture".  I agree with you that there seems little problem with using Structs in this manner, but that there are some risks associated with so doing as the undocumented internals of AutoIt could change at some time in the future.

I cannot find any mention in the Helpfile that structs should not be used as aggregate data containers

Which I would take as a good hint that they were not intended as such - but that there is no specific prohibition against so doing. And I feel that is a good summary of what this thread has concluded.

M23

[RTFC]

Thanks for the clarification.