Yes/No parameter glitch

Yes/No parameter glitch

MattKincaid
Advocate Advocate
1,339 Views
8 Replies
Message 1 of 9

Yes/No parameter glitch

MattKincaid
Advocate
Advocate

I'm seeing something odd when trying to set the value of Yes/No shared parameters.  If I open a transaction and set a parameter to "yes", then set it to "no" in the same transaction, then close the transaction, the final value of the parameter is always the opposite of what it was before the transaction.  In other words, the value just flips every time.  I'd expect it to always be "no" since that's the last value it was set to.

 

If I set it to yes, then no, in two separate transactions things work like I would expect.  Last in wins.  I only see this with Yes/No parameters, not other kinds of parameters.  This is Revit 2021 (have not tried other versions).

 

Is this expected behavior or a bug?

 

Thanks!

0 Likes
Accepted solutions (1)
1,340 Views
8 Replies
Replies (8)
Message 2 of 9

mr.engineer.aec
Advocate
Advocate

 What value you set for yes and for no in your script ?

I don't have any problem with set yes/no.

You should upload some code  for our review

0 Likes
Message 3 of 9

MattKincaid
Advocate
Advocate

I'm using 1 for yes and 0 for no.  Using the Set(int32) method.  Is there a better way?  I don't have the code handy but will try to upload when I'm back in the office.  Thanks for the reply!

0 Likes
Message 4 of 9

Kevin.Lawson.PE
Advocate
Advocate
Accepted solution

Hmm, that sounds bizarre. Calling doc.Regenerate() in between setting and resetting the parameter might help? 

-Kevin Lawson, PE
www.rippleengineeringsoftware.com
Revit heating and cooling load calculations in one click!
0 Likes
Message 5 of 9

MattKincaid
Advocate
Advocate

Right?!  Totally bizarre.  Yes, calling doc.Regenerate in between results in the final parameter value being the last value it was set to in the code.  Committing a transaction is supposed to call Regenerate automatically anyway, so that's consistent.

 

But I'd prefer to not have to regenerate every time I set a parameter.  The code I'm working with calls Set a few hundred times, so I worry all those regenerate calls would be a performance problem.  But I haven't actually benchmarked it, so maybe it's not as slow as I think.

 

@mr.engineer.aec   Here's the code you wanted to review.  Thanks!

 

    Private Sub TestYesNoParameter(parameter As Parameter)

        Using transaction = New Transaction(Doc, "TestYesNoParameter")
            transaction.Start()

            Dim a = parameter.Set(1)
            Dim b = parameter.Set(0)

            Dim status = transaction.Commit()

        End Using


    End Sub

 

0 Likes
Message 6 of 9

Kevin.Lawson.PE
Advocate
Advocate

It's not as slow as you think. I apply doc.Regenerate() liberally because it makes weird things work as expected and I haven't noticed much of a slowdown, even when running a few hundred/thousand times. 

 

-Kevin Lawson, PE
www.rippleengineeringsoftware.com
Revit heating and cooling load calculations in one click!
0 Likes
Message 7 of 9

MattKincaid
Advocate
Advocate

I just tried it and it seems to work well.  Thanks for the solution!  I wish there was a way to add that to the parameters documentation, so others could find it too. 

0 Likes
Message 8 of 9

RPTHOMAS108
Mentor
Mentor

Out of interest what would be the circumstance where you need to set the same parameter multiple times within the same transaction? The parameter only ever has one final value, I think I would be establishing that prior to even starting a transaction, since you can't rely on values during a transaction. 

 

You see this with location point when you create new instances, if you then try to rotate by that location point in the same transaction it will rotate about XYZ.Zero (not the location where the instance was inserted).

 

I believe it is just normal that values are updated during Regeneration (that is automatically called after transaction completes). Probably this is due to behaviour of refence types and value types in that it only (by design) expects you to set once but if setting a referece type it inherantly changes upstream as all ref types do. Not really seen this so can't say for sure.

0 Likes
Message 9 of 9

MattKincaid
Advocate
Advocate

I believe an appropriate term is spaghetti code?

 

I have some code that loops through a bunch of parameters and sets them based on some logic. It sets Parameter A,  then Parameter B,  then Parameter C, etc....  However, my Addin is designed such that not all families will have Parameter B.  So my loop checks whether Parameter B exists and, if not, it just sets Parameter A again, with the value for Parameter B.  All parameters are set in one transaction.

 

I'm sure  there are cleaner ways do to it.  Was just trying to write something quickly : ).

 

 

0 Likes