Why does parameter update works differently for doors in 25+

[Barry Kelly]

I hope I can explain this clearly.

Sample version 22 objects are attached.

I have a door object that works perfectly fine in version 22.

It has a parameter list of widths (parameter A) and a matching parameter list of door leaf sizes sizes and a parameter for the number of door.

I have used GLOB_MODPAR_NAME to say when the number of door leaf is changed, the overall width (A) should change as well - simply the number of door x the door leaf width.

I have simplified the code to what is in the attached objects (parameter script).

values "size" 0.72,0.82!,custom

values "a" 0.72*numdoor,
	0.82*numdoor!,				!!!!! if I un-comment these two lines
	!custom						!!!!! then it will work correctly



if GLOB_MODPAR_NAME = "numdoor" then
	a=size*numdoor
	PARAMETERS a=a
endif

So it is very straight forward.

If I change the parameter for the number of doors, the value of A should change.

Which it does perfectly in version 22.

Now exactly the same objects used in version 25 - the door does not work properly.

Change the number of doors in the parameter to 2, the object settings show the correct value in the object settings, press OK, the info box briefly shows the correct value and then it changes to the firs value in the value list for A.

It should not do this.

i.e A =820, number of doors  =  1 and door leaf width (size) = 820.

Change the number of doors to 2, then A should become 1640.

Instead it becomes 1440, which is 2 times first value in size list.

Oddly if I create an object with exactly the same code, it works in both 22 and 25.

Object and door object are attached - pleas try for yourself.

If I add a 'custom' size to the parameter list for A, then is also works, but the problem is I would rather not allow a custom size for A.

I want a fixed list of sizes.

This is what I see in 22.

But in version 25+ it does not work.

Does anyone know of a reason why it does not work?

@Peter Baksa if you have time to look at this it would be appreciated.

Attached is a short video as well.

22 is on the left, 25 is on the right.

Pause at 19 seconds and you will see info box shows 1640 for width (A) then changes to 1440.

Barry.

[Peter Baksa]

Hi Barry,

This is a bug, I will report it. A workaround may be that you round the custom value to the closest allowed one. And it is possible to show only certain values of a parameter with ui_infield{3}.

[Barry Kelly]

---

@Peter Baksa wrote:

This is a bug, I will report it.

---

Thanks Peter.

I thought it was odd that it works for an object but not a door (and it used to work before).

I seem to have solved it by taking the updating of 'A' parameter out of the IF_GLOBMODPAR_NAME routine, and then adding the VALUES list for 'A' after this.

There is probably something wrong with that method, but it seems to be working (fingers crossed).

Barry.

[mthd]

Does it really need to be so complicated in a workflow using standard door sizes to go to simple double doors ? How much time did it take to edit the script and make this post ? I would have a builder chasing my tail if I take too long in doing a simple task like this. I can’t afford to fudge around with scripts that waste valuable time just like @Barry Kelly has done here.

Why not just a have a change to double door tab in the dialogue box ? Then you don’t have to check every new version to see if it still works.

I guess coming from an estimating background with builders on your back makes me think like this. I should have become an Architect so I have plenty of time to fiddle with the app.

[Barry Kelly]

---

@mthd wrote:

Does it really need to be so complicated in a workflow using standard door sizes to go to simple double doors ? How much time did it take to edit the script and make this post ? I would have a builder chasing my tail if I take too long in doing a simple task like this. I can’t afford to fudge around with scripts that waste valuable time just like @Barry Kelly has done here.

Why not just a have a change to double door tab in the dialogue box ? Then you don’t have to check every new version to see if it still works.

---

Everything still needs to be scripted in the objects.

This problem is also peculiar to the way I have scripted my own door object.

I am sure in the default Graphisoft objects it is handled differently and won;t be a problem (I don't use the Graphisoft doors and windows).

I think the Graphisoft objects may even have separate objects for single and double doors.

Mine is all in one, even does 3 or 4 door frames for built in robes.

I spend the time trying to get my objects working as efficiently as I can because I have 40 other people in the office that use them.

I am in the fortunate position that it is my job to makes other peoples' jobs as easy as possible.

A smaller office or single operator may not have the luxury to be able to mess around scripting objects.

Barry.

[mthd]

Yes and using multiple doors for robes is also common in my area too.

I see that having a good office template makes sense in your particular workflow scenario. Having a knowledge of scripting is quite helpful for programming common default elements like doors, windows etc.

Cheers !

[Late]

Hi @Peter Baksa 

Attached Window update problem has similar behavior with valuelists and might be relative to this bug, isn't it. Please find explanation picture below to help you find a solution to the problem. Or let us know if workaround exist...

Best regs!

[Peter Baksa]

Hi Late,

Custom values an be mixed with pre-defined ones:

values "a" 1.1, 1.5, range [1, 3], custom

[Late]

Yes I know but it's not the issue here and doesn't solve it either.

Purpose is separate clear pre-set values (eg catalogue) and free input each other for user. Both cases need to control parameter A to stretching window right on 2D/3D (otherwise you can use two different parameters).

It's strange and very harmful that everything works fine in preview (see bug description #3) but not after clicking OK (#4) and you need to re-do it (#5-6).

regs