INPUT and OUTPUT functions, OPEN documentation

[Anonymous]

Is there any extensive documentation for the OPEN, INPUT, and OUTPUT, functions? As usual, the legacy documentation that has been brought forward is crystal clear only if you don't need it.

Is there a difference between operational extension and the name of an existing extension? What are specific separation characters of the operational extension. Is the reason that OPEN ('text", filename , "MODE=RO, LIBRARY") works because "text" is defined in the GDL Text I/O Add-on?

Where are other available filters to be found? Are there (should there be) particular ones for csv files and a different one for tab-separated text files and are there ones for .xlsx files, etc.? There is a SEPARATOR= param that can be used in OUTPUT, but no documentation appears for using that with INPUT.

In the INPUT function docs comes this increasingly puzzling line:

...its contents are interpreted by the extension.

There is a clear functional connection between OPEN and INPUT. Can there be be other declarations between the OPEN and INPUT statements? Often such code seems to fail (for me). Can I assume that the extension is the one identified in the OPEN statement?

[Karl Ottenstein]

Hi Didrik,

Like much of the GDL manual, those descriptions are pretty cryptic (I gather you are looking at page 261). Part of what makes what you cite confusing is the word 'extension', which Graphisoft usually describes instead as an 'add-on' (and others as a 'plug-in'). Those statements have no function without the presence of an appropriate add-on.

The place to look to understand these interface statements is at the back of the manual where the various GDL I/O Add-Ons (several of them) are specifically described.

For example, take a look at the GDL Text I/O Add-On section on page 354 (AC 14 US/INT GDL manual) - which is still written rather poorly! There, you see that the OPEN command takes as its first argument a 'filter', which must be the quoted string "TEXT" to access the text i/O add-on. (The syntax should just SHOW "TEXT" there, since it is giving the syntax for the add-on, of course.)

Review the other I/O add-ons there to see how each is set up.

Graphisoft has a GDL Developer Kit which is only available upon specific written request (for reasons I do not understand) - and which allows a 3rd party to create new I/O add-ons, such as accessing a specific kind of database or whatever.

Cheers,
Karl

PS You can see the various GDL add-ons available to you by looking in your application folder inside the Add-Ons>GDL folder. I would have thought that the name of the add-on would be the 'filter'/extension - but apparently an add-on can have any name and somehow publishes its 'filter' name ("text") for access by AC.

[Anonymous]

Got it. Thanks. I had been hoping that there was more. Some of the examples make reference to AC 8, so I was supposing that this was out of date, and hoping that there were undocumented additional things available.

One important thing was understanding that fieldID was not a pointer under user control in quite the same way that recordID is. I was not able to scroll "across a record with a FOR ... NEXT index to pick just the fields I wanted, AND I thought I had to, based on my interpretation of examples on pp. 222, 259-260, and elsewhere. The fieldID is more like a pointer to the first of several fields in a record that one wants to read and then it goes through the matchup with user-supplied variables from that point on. In other words to pick the jth field in the ith record seemed to produce nothing but errors for me.

Also, (syntactic?) failure in the INPUT statement frequently generated errors in the 2D script. I mean, we're talking a one line 2D script, and a one line 3D script -- and no connection between the data being read and any geometry. I recall reading that data in the Master Script is available to the others, and therefore the MS has a privileged position, but that the Parameter Script is read first, so it has a different kind of advantage. So our exercises sometimes involved trying to fix the wrong problem at the wrong time, or at the right time in the wrong place.

[Anonymous]

Karl wrote:
... There, you see that the OPEN command takes as its first argument a 'filter', which must be the quoted string "TEXT" to access the text i/O add-on. (The syntax should just SHOW "TEXT" there, since it is giving the syntax for the add-on, of course.)

Someone in our office had it working just fine using "TXT" -- in line with the interpretation that 'they must mean file extension.' I was not able to get that to happen and was really surprised when he showed me. I was not able to get SEPARATOR = ',' to function properly, but had no trouble with SEPARATOR = '|'. Would you happen to know (before I get to try it) if white space (not only '\t')can serve as a separator?

[ztaskai]

Hi,

Karl answered the questions (as usual), I'd just like to make some additions about the background.

GDL Manual is cryptic at some places, that's for sure. Section 'File Operations' is intended to be this abstact as it just covers the generic elements of the language without specifics about any (GDL) add-ons a.k.a. extensions. Naturally, a better cohesion of this section and the add-on specific sections could be created in some way.

'\t' works for a separator. All steel sections in the ArchiCAD Library use this option. Like this:

open("text", "SHS Cold-Formed(13).txt", "separator='\t', mode=ro, Library")

I'm aware that there is a gap between the abstract and succint documentation GDL Manual offers and between the available books about GDL. We intend to fill this gap with the Basic Library Documentation, but it's an ongoing task which won't be finished soon. I can't think about a way to speed this process up:(

Best regards,

[Anonymous]

Hi Ztaskai,
My present challenge is treatment of data in text files on the way into a GDL object. Using array operations, anything that looks like a number such as "0008125463" is interpreted as a number and the leading zeros are stripped. However "9998125463" is stored in scientific notation and is thereafter useless to me.

On the other hand, if it comes in as text (I use '\t\ as field separator and ' " ' (dbl-quote) as text identifier in Access or Excel on the way out), then the GDL array treats the actual quote marks as part of the data. This makes comparisons clumsy or impossible. So the value of ARRAY might then be '"0008125463"' (the stuff between my single quotes just now). This has been checked both by OUTPUTting to a text file and by querying the GDL array cells directly. For comparisons, it appears that I then have to quote the quoted material, and that has thus far generated errors for me. Initializing the array to text value (ARRAY[1][1] = "") does not help.

I have discovered something in Watson's GDL Handbook regarding nested single and dbl quotes, that may help in this case, but I haven't tried it yet. Some further docs on the phenomenon he describes would be helpful.

[Anonymous]

@didrik
I had exactly the same issue. Reading a value with leading zeros using INPUT function. All my numbers are supposed to have a length of 4

Example of my csv file:

0008,
1234,
5678

The first value is for example: 0008 and I read my csv source file like this:

channel = OPEN ("TEXT", filename, "SEPARATOR = ',', MODE=RO, LIBRARY")
n = INPUT (channel, i, 1, number)

The result of number will be a interpreted by INPUT as a number not a string. To be able to use it as a string of length n (in my case 4) with leading zero's I came up with the following.

! add 10000 (10 to the power of n+1) for allowing leading zeros
number = 10000 + number ! number = 10008

! use STR to convert the whole number to a string
string = STR(number, 5, 0) ! number = '10008'

! use STRSUB to read only the last 4 characters (2 to 5) of string
string = STRSUB(string, 2, 5) ! number = '0008'

I hope this will help some people solving similar issues

[Aaron Bourgoin]

what dogged perseverance. Well done! Thanks.

[Anonymous]

Aaron wrote:
what dogged perseverance. Well done! Thanks.

And THANK YOU, Wilt. I don't know what else to say, after 5 years.