LOCK Not Locking!

[Anonymous]

I have several LOCK functions in my Master Script that are meant to lock parameters depending on other values. I have at least 3 of them that won't lock the parameter. I've checked it from every angle -- spelling, punctuation, syntax, order of evaluation, extraneous code, etc. -- and nothing has solved the problem, they just will not lock. I've spent at least 3 hours trying to solve this problem.

The following code is used in a dozen places, only using different parameter names each time.

IF DCA_Deadbolt = `-` THEN
PARAMETERS DCA_Deadbolt_Qty = `-`
LOCK `DCA_Deadbolt_Qty`
ELSE
IF DCA_Deadbolt_Qty = `-` THEN
PARAMETERS DCA_Deadbolt_Qty = `1`
IF TypeChar <> `D` THEN
PARAMETERS TempVal = "HELLO" ! This line works
LOCK `DCA_Deadbolt_Qty` ! This line DOESN'T
ENDIF
ENDIF
ENDIF

The test line with TempVal works, which tells me the IF function preceeding it is working correctly. There is absolutely no reason the LOCK function shouldn't work. Is this a bug, or am I missing something? I realize it's Friday afternoon, but I can't be THAT delirious.

[Anonymous]

F. wrote:
In the moment the PARAMETERS statement is executable in master script TypeChar is unequal to "D". In a later execution of the master-script, when the LOCK command would work, TypeChar is equal to "D" and the line is not executed, because the IF-THEN is not true.

I just tested that idea by putting the value of TypeChar into a test parameter right before attempting the LOCK and TypeChar is being set appropriately. I tested TypeChar in other situations to make sure it was switching to other appropriate values -- it seems to be working correctly in all scenarios.

[Frank Beister]

I moved all the code that deals with PARAMETERS and LOCK to the Parameter Script -- no luck, it still misbehaves.

As you mentioned, this does not help for all these problems.

I made a short view to your door, but it's too 'blown up' to understand it in a short time. All I can say is: There is too much parameter-script - stuff in the master script. Put all these VALUES into theit right place!

Using PARAMETERS in master is sometimes a good move, but first you should try it in the parameter script.
In case the PARAMETERS-command is ignored, because the interpreter is in the "wrong" circumstance, the parameter will not be changed either.
I prefer:

val1="new value"
PARAMETERS val1=val1

In GDL Technical Standards is a recommendation to declare parameters in master. This does not mean to put all PARAMETERS-stuff into the master!
This means, if e.g. the size of object-part is not adjustable by a parameter but calculated by other parameters and this size is used in 2D and 3D THEN its is useful to declare it in master. You don't have to do it twice.

I'm not sure how this squares with DNC's view that most of that stuff should be in the Master Script.

As I said at other places I do not agree in this point with DNC.

To transfer to my example above. I split the two lines:

! MASTER-Script
!
val1="new value"

! PARAMETER-Script
!
PARAMETERS val1=val1

If I understand this thread correctly, the Master Script is run repeatedly, where the Parameter Script is only run in certain instances. If so, it would seem that you would put it in the Parameter Script for speed, or the Master Script for constant validation.

In most cases it will not remarkable decrease speed, if there are lots only once executed statements in the master. But you should not put there file access. This will decrease speed in deed.

My masters in large objects are not tiny too, but I try to keep them clean of stuff, which is not necessary to be there.

[Anonymous]

Just in case, there is some additional info about "Script type specific issues"
here

[James Murray]

F. wrote:
In case the PARAMETERS-command is ignored, because the interpreter is in the "wrong" circumstance, the parameter will not be changed either.
I prefer:

val1="new value"
PARAMETERS val1=val1

I do this too, and I've observed many cases where it was needed (a problem went away), but I've never understood it. I understand that the parameters script is only executed in limited circumstances, but is it also true that PARAMETERS commands in the Master Script are ignored when in non-parameter-script circumstances?

That is, if the parameter script is not run, ignore all PARAMETERS statements in the MS?

I think this is weird, but it would explain why the assignment+PARAMETERS construction works.

[Frank Beister]

When I decided to make it in this 'double' way, I mentioned, that the parameters do not change their value after a PARAMETERS val="change" statement. It is a longer time ago and it was difficult to proof the below following theory, because PRINT and TEXT2 do not work in all running circumstances. I tried to reproduce in AC9, but did not get it again, so maybe the behaviour has now changed.

Each object has, stored in its GSM-file, the standard values of a parameter. In the project database (=plan) for each parameter of each instance of the placed object the value is stored again. In earlier times we could see this very fine by doing a PLAN DUMP (missing in AC8.x+). This values can only changed, when you are in settings dialog or you are graphical editing the parameters. (In last case of course not by the PARAMETERS statement)

So far so good. Now my theory:

When running the script (before starting the MS) for all parameters will be created variables: Same name and same value as stored in the project database. And here comes the point: All changes to your "parameter" as A=A/2 will affect to the variable. But with the PARAMETERS statement you change the value of the storage of parameter in the project database and THIS does not affect to the variable. After finishing this (first) run of the script the next run will start with the new value, set by the parameters-statement, but the rest of the first script will end with the old value. Depending of the necessarity of having the new value this can cause problems.

Can you follow this? I differ between parameters (globals and this one out of the parameter-list) and variables (created at runtime).

So I make it twice: Change the variable AND the parameter.

[Anonymous]

If you haven't seen it yet, I posted a wish for Graphisoft to publish script evaluation information so we don't have to theorize about how the interpreter works. You can find it here http://archicad-talk.graphisoft.com/viewtopic.php?t=7153.

[Barry Kelly]

Jay wrote:
I have several LOCK functions in my Master Script that are meant to lock parameters depending on other values. I have at least 3 of them that won't lock the parameter. I've checked it from every angle -- spelling, punctuation, syntax, order of evaluation, extraneous code, etc. -- and nothing has solved the problem, they just will not lock. I've spent at least 3 hours trying to solve this problem.

The following code is used in a dozen places, only using different parameter names each time.

IF DCA_Deadbolt = `-` THEN
PARAMETERS DCA_Deadbolt_Qty = `-`
LOCK `DCA_Deadbolt_Qty`
ELSE
IF DCA_Deadbolt_Qty = `-` THEN
PARAMETERS DCA_Deadbolt_Qty = `1`
IF TypeChar <> `D` THEN
PARAMETERS TempVal = "HELLO" ! This line works
LOCK `DCA_Deadbolt_Qty` ! This line DOESN'T
ENDIF
ENDIF
ENDIF

The test line with TempVal works, which tells me the IF function preceeding it is working correctly. There is absolutely no reason the LOCK function shouldn't work. Is this a bug, or am I missing something? I realize it's Friday afternoon, but I can't be THAT delirious.

Not quite sure why the LOCK isn't working - must have something to do with the fact you are trying to lock the variable being used in the IF statement and you are changing the value of it from when you started the IF statement (just a guess!).

Move it outside and this will work.

i.e.

IF DCA_Deadbolt = `-` THEN
PARAMETERS DCA_Deadbolt_Qty = `-`
LOCK `DCA_Deadbolt_Qty`
ELSE
IF DCA_Deadbolt_Qty = `-` THEN
PARAMETERS DCA_Deadbolt_Qty = `1`
ENDIF
ENDIF

IF TypeChar <> `D` AND DCA_Deadbolt_Qty = `1` THEN
PARAMETERS TempVal = "HELLO" ! This line works
LOCK `DCA_Deadbolt_Qty` ! This line DOESN'T
ENDIF


If you have the GDL object open for editing then you must click on another variable before 'DCA_Deadbolt_Qty' will lock.
In the object properties of a placed object it locks as soon as you change it.

Barry.