Good Object, ... Bad Object

[Anonymous]

The object below is the Master Script of a (non-placeable) macro. Check script for Master, 3D, and 2D show GDL script ok. Yet when saving the macro object, an error is reported in the 2D script. "Error! There are errors in the 2D script. If used in ...." Is that because the non-placeable macro should nevertheless have a non-empty 2D script?

The 2D, 3D, and Parameter Scripts are empty. There are only the obligatory parameters found in the macro's main window.

One of the downsides to placing material in the Master Script is that "errors flow downhill," and may result in no 2D symbol &/or no 3D object display. In this case errors that may not exist may still flow downhill.

!	DECLARATIONS

mID  = ""
Q_ID = ""
Oc_Source = ""
Ps_No = ""
Ps_OSCrank = ""
Gade = ""
Oc_Name = ""
Psn_Status = ""
PsnChangeNote = ""
Ofice_Type = ""
Pl_gl_verbal = ""
At_Sts = ""


DIM STF[1000][12]
STF[1][1] = ""

i_m = 1			! This must be initialized to 1, otherwise
				! INPUT stmt below will cause 
n1_m = 0 
ch1_m = 0
file1_m = "STFSTUF.txt"
file2_m = "STFSTUF_DataValidation.txt"

!	WORK

ch1_m = OPEN ("TEXT", file1_m, "SEPARATOR='\t', MODE=RO, LIBRARY")

DO 
	n1_m = INPUT (ch1_m, i_m, 1, mID, Q_ID, Oc_Source, Ps_No, Ps_OSCrank, Gade, Oc_Name, Psn_Status, PsnChangeNote, Ofice_Type, Pl_gl_verbal, _At_Sts)
	
	STF[i_m][1] = mID 
	STF[i_m][2] = Q_ID		
	STF[i_m][3] = Oc_Source
	STF[i_m][4] = Ps_No
	STF[i_m][5] = Ps_OSCrank
	STF[i_m][6] = Gade
	STF[i_m][7] = Oc_Name
	STF[i_m][8] = Psn_Status
	STF[i_m][9] = PsnChangeNote
	STF[i_m][10] = Ofice_Type
	STF[i_m][11] = Pl_gl_verbal
	STF[i_m][12] = At_Sts

	i_m = i_m + 1

WHILE n1_m > 0

CLOSE ch1_m

[Barry Kelly]

Does the file you are trying to open (STFSTUF.txt) actually exist in the loaded library?

From the GDL reference guide - "LIBRARY: If this keyword is present, the data file must be in the loaded library."

Barry.

[Anonymous]

Yes, Barry. That file is in the loaded library. With fresh eyes, this morning, I've checked things again.

I am using the library in expanded mode. That text file is in the LIBR folder in the same folder as the macro and as the "main" object that calls it will be. At posting time, I had not actually "run" the object, only checked its script in the GDL object creation environment. At posting time there was no main object to call that macro.

Since then, I have created a brief main routine that CALLs the macro. The main "doesn't do anything" just calls the macro and sits there. This is proving troublesome. Early in the macro I've declared rows_m and cols_m. After closing the channel in the macro, I have added:

rows_m = VARDIM1(STF)
cols_m = VARDIM2(STF)
END STF

in anticipation of passing these back to the main object.

On the main's CALLing side, I have sent over values from rows to rows_m and from cols to cols_m and have used the CALL stmt with RETURNED_PARAMETERS STF. The range of resulting error messages indicates some fundamental misunderstandings on my part, somewhere. I wonder if END is a problem here in the macro's Master Script? One point is that the CALLing object error message switches the case of the variable: it says that COLS_M isn't a valid parameter name and cites the CALL stmt. I'm not sure what's not valid about it, since it(s lowercase version) plainly exists in the macro. Normally variables are cited back in the same case as they occur in the scripts, even if underneath case doesn't matter.

[Anonymous]

I have been having problems with spurious errors in GDL lately where there is an error reported at some line but the code is letter perfect. I can fix it sometimes by cutting the text and pasting it back in or others by deleting and retyping. It seems like a long shot but perhaps this is related.

[Anonymous]

Thanks Matthew. Little by little over the last few weeks, I have been edging ever closer to a similar conclusion, so much so that I am increasingly taking screen shots of "stuff you wouldn't believe unless you saw it." Happily, I guess, it's usually been an error between the keyboard and the chair. Unfortunately, in other cases the screen shots simply don't capture the context like a proper debugger might, and they'll evoke the usual response, "so?" Even in this case, I expect that eventually I'll discover {my, an} error.

This was one of those attempts to clear the slate and start from scratch using what I think I had learned, freshly typing in everything. It reminded me that sometimes "a blank sheet of paper" is not the writer's worst nightmare, but a real organizing blessing. That, of course, turned to mud rapidly.

[ztaskai]

Hi,

didrik wrote:
On the main's CALLing side, I have sent over values from rows to rows_m and from cols to cols_m and have used the CALL stmt with RETURNED_PARAMETERS STF. The range of resulting error messages indicates some fundamental misunderstandings on my part, somewhere.

I don't see these rows and cols parameters used in the script.

didrik wrote:
I wonder if END is a problem here in the macro's Master Script?

I guess not. It plainly disables the running of all other scripts of the macro object (which, I guess, was your intention).

didrik wrote:
One point is that the CALLing object error message switches the case of the variable: it says that COLS_M isn't a valid parameter name and cites the CALL stmt. I'm not sure what's not valid about it, since it(s lowercase version) plainly exists in the macro. Normally variables are cited back in the same case as they occur in the scripts, even if underneath case doesn't matter.

Don't be bothered by the character case of the parameter name - GDL isn't either. Achieving case-insensitivity is done by making everything uppercase inside, hence the uppercase reference in the error message. On the other hand, ArchiCAD surely has a reason not to find that parameter. There can be several reasons for that: mistyping the parameter name at any point, calling a different macro than you're looking at or the parameters having incompatible types.

One more thing: no file operation is done at check script. So it doesn't tell you much that check script says 'No Error'. Unfortunately, objects with file operations have to be tested in a project.

Regs,

[Anonymous]

I'll have to go back and review the context. I probably did not include everything, since there is a Master_GDL script as well.

This was already so long ago, in terms of things I've tried and time spent on it. However, back then I suspected that END stmt should not be in a Master Script. I now know this (from other documentation that came to light).

Removal of END made no difference. The concept might have been to narrow in on the source of error, by trying to run just one script at a time. Unfortunately, the "check script" facility is often less help that we need it to be, and in some cases, misleading.