Bug when associating parameters of shared nested family

[Anonymous]

I finally managed to isolate a bug that has had me climbing up the walls in frustration. Now to see if I can get confirmation on this:

1 create wall based window family (from factory template)
2 create shared generic model, create some geometry
2a create instance length parameters 'associate' and 'result'
2b create type length parameter 'type'
2c create formula for 'result' = type + associate
2d associate a dimension label with 'type'
4 nest shared family in window family
5 associate the 'associate' instance parameter of the nested shared family with a parameter in the window family, say 'Height'
6 load the window family into a project and place it in a wall
7 group the window and the wall
8 select the nested family and change type parameter 'type'
9 vigorously scratch head at the warning: Changes to groups are only allowed during Edit Group mode. Use Edit Group to make this change.

See zipped sample rvt, 2016 (version 16.0.1185.0 20161004_0715(x64) Update7 for R2)
I do not think it is specific for this version, I have been seeing related warnings for months.

https://www.revitforum.org/architecture-general-revit-questions/34491-bug-when-associating-parameter...

[Alfredo_Medina]

I haven't followed the steps in the computer, but by reading the steps my opinion is that the response from Revit is normal, not a bug, because of your step # 7.

[ToanDN]

Step #3 is the culprit.

[Anonymous]

Hi Toan,

It turned out step 3 was in fact not the culprit, so I left it out for your convenience. I assumed the fact that 4 is more than 2 would be sufficient for most people to follow these steps.

[Anonymous]

Hi Alf, haven't seen you on RFO for a while! How have you been?

Thanks for taking a look. Can you elaborate a little?

- What exactly is it that you think step 7 entails? What I meant, in more detail: select both the wall and the window, then use the 'Group' command to put them both in the same group.

- What exactly is it that you percieve as normal about the warning that appears? Or did you mean something else? I do know that since I started using Revit at version 9.1, it has had a history of providing unhelpful warnings, but this particular specimen is not even remotely accurate. Changing the type from within the group editor, as the warning prompts me to do, still does not work. In fact, it generates the exact same warning, which makes even less sense in this context. That, to me, is worth reporting as abnormal, to see if anyone can confirm or that I am looking at a corrupt file somehow.

[Kimtaurus]

Changes to an element in a group, can only be done while editing the group. Not by selecting the element and making changes.

The warning you received is quite common when working with groups.

[Anonymous]

Hi Kimtaurus,

The point I am trying (and failing?) to make, is that I am not changing an element. I am changing the type of an element. For instance, remove the formula from the 'result' parameter and it works fine, as expected.

I could go into more detail about what I expect is going on, but I would prefer to get some unbiased feedback first. You might think of something I missed.

[Alfredo_Medina]

@Anonymous  Hey, nice to see you here! What? Is there a migration from RFO to this forum? 🙂

Well, I say the problem is your step # 7 because you grouped the elements. Then you try to change one element within the group without starting with Edit Group, then Revit replies saying that you need to edit the group first. I see this as normal.

[Anonymous]

@Alfredo_MedinaWell, to be honest, the only reason I came here too is that I can't find anywhere else to report a bug to Autodesk.

The reason I still see it as a bug is that:

1 I am trying to change the nested type. Without the formula, this works 'normally'.

2 When I do start with Edit Group, and then edit the nested type, this gives me the exact same warning.

I understand you are not being paid to replicate my efforts. Any attempt to do so would only serve to satisfy any curiosity you might have.

I am paying my reseller, but I thought to share with the Revit community first.

[Alfredo_Medina]

Well, @Anonymous , I see that your intention is to report a bug and receive an answer from Autodesk. Then, this is not the place to do that, sorry. This is just a forum with users, not really "Autodesk" itself. Maybe an employee from Autodesk can respond to this thread providing the proper link to report bugs to Autodesk. But we are just users, as any other user in another forum.

[Anonymous]

@Anonymous  Bugs should be reported to Autodesk Support through your support portal.

Yeah, asking here is the same as asking at RFO...both places some Autodesk folk do occasionally stop by though.  More often the ones you want to stop by are at RFO...

[Anonymous]

Hi @Alfredo_Medina,

Reporting a bug is what I try to do when I think I see one. That in no way means that I might no be wrong, and anyone in the community could prove that. Saves the good folks at Autodesk some time. Having said that, I indeed assumed the Autodesk logo at the top would indicate more direct or indirect company involvement, sort of like at the ideas page. I stand corrected.

I applaud your efforts to help users, and I realize you are trying to help as many people as possible within the time you can spare.

I can see where this is headed, and trying to reverse the process would take too much of my time. Does make me wonder what wording I could have used to entice someone to replicate my steps. Tips, anyone?

As soon as my IT manager is back from his vacation, I'll be able to ask him who our contact at the reseller is, and ask them to log a support request at Autodesk. Welcome back in the 20th century.

[ToanDN]

@Anonymous

I now have a chance to open you model and yes, Revit did throw the warning that you have mentioned when I change value "type" of the nested generic model from 560 to something else.  But, when I accepted it then the family got changed properly based on the value I entered, and nothing got deleted even the warning suggested so.  The group stays intact and better yet, from that point I can change the value of "type" without any further warning.

[Anonymous]

@ToanDN

You are right, I had not expected that clicking on 'delete elements' would help. Strange that the warning does not reappear. What exactly gets deleted? I also notice that the value of the 'report' parameter only updates after the Type parameter in the Window family is changed. Changing the Type parameter 'type' in the Generic Model family does not influence the value of 'report' directly.

It would seem that this only helps as long as there is only one instance of the group present.

When I copy the model Group (I'll edit the step by step description), I can no longer ignore the warning.

[Alfredo_Medina]

If there's only one instance of the nested family, Revit will allow the change, as you can read if you proceed to message 2 of 2 with the Expand button of the Warning dialog box. But if you create more instances of the group, then the change won't be allowed.

What I find strange from this question is that you know that a group needs to be edited with Edit Group but you are intentionally skipping that step, but then you get surprised that you receive a warning about it, and then you call this a bug. Well, to avoid warnings, if you need to make changes to the group use the Edit Group button, make the change, and save changes.

And the reason if fails when you do start with the Edit Group button is because the "type" parameter in the nested generic family being a "type" and not an instance". If you change that parameter to be instance, and then you associate that parameter with another parameter in the window family, being instance or type, then you will be able to change the properties of the nested generic model by changing that parameter in the window family. That will work without any errors.

[Anonymous]

@Alfredo_Medina

"you know that a group needs to be edited with Edit Group": here is where this misunderstanding probably originates. To edit a Type of an element it has, to the best of my knowledge, never been necessary to edit a Group. In ToanDS 's video, you do not see him edit a Group. Editing the Group does not change the warning. But now I am repeating myself, and you are repeating yourself. Let's just drop this.

An assumption that you can tell what someone else does an doesn't know is tenuous at best.

I wholehearteldy agree there are any number of things I can do to avoid this particular situation. That is true for most bugs in a mature software.

For the situation that I run into this problem, I already have a solution planned. I hope I am looking at a corrupt file, or that I can wait for a hotfix and muddle trough.

[Alfredo_Medina]

@Anonymous

Did you read my third paragraph?

[Anonymous]

@Alfredo_MedinaI did read your third paragraph. If I ask for help, I take any replies very seriously.

Thank you for informing me there are ways to avoid this behaviour. I already knew that, and that is why I did not ask for a workaround, but someone else might benefit from it.

If you have a window family template that does not exhibit this behaviour, for example, it would be most welcome. Right now I am considering rebuilding from a Generic Wall Based template (which works just fine in this situation but has other repercussions) and reclassify that as a window.

[Alfredo_Medina]

In my opinion, any parameter that one plans to carry over from nested families to hosts, needs to be set as instance. Then, if you want the parameter to be "type" in the project, associate the nested instance parameter of the family to a type parameter in the final host. 

[barthbradley]

Thanks to all that participated in this interesting and thought-provoking “bout”; I enjoyed reading it very much. I think others will find it beneficial as well.

Cheers!