topic Re: LOCK Not Locking! in Libraries & objects

LOCK Not Locking!

Anonymous — Fri, 10 Jun 2005 22:39:02 GMT

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.

Re: LOCK Not Locking!

Anonymous — Sat, 11 Jun 2005 01:39:32 GMT

Have you tried the script in the Parameter Script?

Re: LOCK Not Locking!

__archiben — Sat, 11 Jun 2005 03:00:10 GMT

try with double and single quotes as well as the back ticks?

LOCK "DCA_Deadbolt_Qty"

(by the way - the single, double and back ticks around the parameter value all lock for me . . . .)

~/archiben

Re: LOCK Not Locking!

Frank Beister — Mon, 13 Jun 2005 06:43:18 GMT

PARAMETERS and LOCK should first of all be part of the parameters script. They do not work in all context!

Where does TypeChar come from? Maybe TypeChar<>"D" in the moment PARAMETERS works in master and LOCK does not. In a later iteration of the master script, when LOCK would work, maybe TypeChar="D".

As I wrote here a few times: The scripts are executed more than once, esp. the MASTER. And not all stements work in each run. So put in the MASTER as far as possible just common expressions, which are necessary for all script types.

Have you tried
LOCK `DCA_Deadbolt_Qty`
without any dependance of another expression?

Re: LOCK Not Locking!

Anonymous — Mon, 13 Jun 2005 19:21:02 GMT

F. wrote:
Where does TypeChar come from?

It was defined at the beginning of the Master Script.

TypeChar = STRSUB(DCA_Type, 1, 1) !DCA_Type is a string code

F. wrote:
Maybe TypeChar<>"D" in the moment PARAMETERS works in master and LOCK does not. In a later iteration of the master script, when LOCK would work, maybe TypeChar="D".

Refer back to my first email. The line immediately preceeding the LOCK line works exactly as expected. The LOCK line is ignored. There are no other LOCK statement after this one, and there are no other LOCK statements in any other script.

F. wrote:
Have you tried
LOCK `DCA_Deadbolt_Qty`
without any dependance of another expression?

Yes, I tried it as the very last line in the Master Script and it worked just fine. The statement LOCK `DCA_Deadbolt_Qty` is only used in two other situations, both of which occur before the failing instance, and both of those function properly.

My next post (after a meeting I must attend) will include the GDL and an explanation about how to test the faulty line.

Re: LOCK Not Locking!

Frank Beister — Tue, 14 Jun 2005 06:47:36 GMT

The line immediately preceeding the LOCK line works exactly as expected. The LOCK line is ignored.

This I wanted to explain to you. There is no problem with the syntax of your LOCK command. I try it again. Would be easier in German. 😉

Most commands are allowed in Master-Skript, but they do not work in each context. If they make no sense (from the view of the gdl interpreter) they will be just ignured. Example:

LINE2 0,0,1,1
BLOCK 1,2,3

Changing to the floor plan view first the master script is executed, then the 2D-Script. The line of the master will be visible, the block, of course, not. In the 3D-window the block, but not the line is visible.

Lets modify the script:

IF doyouwant="yes" THEN
LINE2 0,0,1,1
BLOCK 1,2,3
ENDIF

Works as well as the first example. Some more:

IF GLOB_CONTEXT=2 THEN doyouwant="yes" ELSE doyouwant="no"

! [... anycode]

IF doyouwant="yes" THEN
LINE2 0,0,1,1
BLOCK 1,2,3
ENDIF

Now the block will not be visible anywhere, but the line in 2D.

Transferred to your problem:

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.

The Master-Script is executed many times, before the complete object is calculated. Just in the settings dialog:

E.g.:
Master > Parameter > parameter-reset > Master > User interface > parameter-reset > Master > 2D-view

I am asking GS a long time to give us a list, which parameters do work in which context in the master and how the scripts are executed exactly!

P.S. the scripts above are not tested. Maybe there are some minor syntax faults.

Re: LOCK Not Locking!

Frank Beister — Tue, 14 Jun 2005 07:02:29 GMT

Or try this one:

IF GLOB_CONTEXT=2 THEN
PROJECT2 3,270,2
ROTx 45 : ROTy 45
BLOCK 1,2,3
ENDIF

Block is visible in 2D, but not in 3D or settings dialog. And it is visible in case the BLOCK-command is after the PROJECT2-command. Do you see, what I mean?

To help with your problem we need to see more of your code, because the "fault" is not as near to the LOCK-command.

Re: LOCK Not Locking!

Anonymous — Tue, 14 Jun 2005 14:59:43 GMT

Wow! That is interesting (in a painful way)! I would think that TypeChar = STRSUB(DCA_Type, 1, 1) would be set regardless -- it's the first code line in the Master Script.

The attached GDL is the problem door. If you search for LOCK PROBLEM you will find one of the offending LOCK lines. To get the problem to rear it's ugly head, perform the following steps in the Parameters section of the settings dialog:

1 - Insert an instance of the door.
2 - Open the settings dialog, go to the Parameters section and expand the DCA Door Parameters title.
3 - Set Leaf Material to SCWD, and Leaf Type to NL.
4 - Scroll down to Lock Type. If Lock Type is a dash, there is not lock on the door, so the Lock Quantity is also a dash and it is locked.. If you choose a Lock Type, you automatically have a Lock Quantity of 1. I want to lock the quantity so the user knows it's the only option.

The reason I don't just lock it and leave it is because there is the possibility of a Dutch door being specifed -- which can have up to 2 locks on it. Wherever you see TypeChar = `D` or TypeChar <> `D` I'm checking to see if it's a dutch door.

It seems pretty simple to me, but what a pain this has been!

Re: LOCK Not Locking!

Anonymous — Tue, 14 Jun 2005 17:36:01 GMT

Hello Jay

I also had big problems with the "Lock" function on several parameters in the Master Script, also on a Door, also with a If Then Statement.
Incidentally I have had also had problem with the function "Hideparameter" in Master Script.

I have try a lot of things and the only solution which works every time is to have them in the Parameter Script and only there. Same way for "Hideparameter".

I can't test your door because I stay in AC81, but I am almost sure that your problem is there…

Re: LOCK Not Locking!

Anonymous — Tue, 14 Jun 2005 18:40:21 GMT

Fmr wrote:
...the only solution which works every time is to have them in the Parameter Script and only there.

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

Thanks anyway!

I'm not sure how this squares with DNC's view that most of that stuff should be in the Master Script. 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.

Hmmm...

Re: LOCK Not Locking!

Anonymous — Tue, 14 Jun 2005 19:08:09 GMT

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.

Re: LOCK Not Locking!

Frank Beister — Wed, 15 Jun 2005 07:44:09 GMT

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.

Re: LOCK Not Locking!

Anonymous — Thu, 16 Jun 2005 12:21:44 GMT

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

Re: LOCK Not Locking!

James Murray — Thu, 16 Jun 2005 20:05:03 GMT

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.

Re: LOCK Not Locking!

Frank Beister — Fri, 17 Jun 2005 11:44:50 GMT

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.

Re: LOCK Not Locking!

Anonymous — Fri, 17 Jun 2005 14:51:04 GMT

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.

Re: LOCK Not Locking!

Barry Kelly — Wed, 22 Jun 2005 04:13:46 GMT

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.