ScheduleDefinition.AddField throws exception adding shared parameter to Key Schedule

[harrymattison]

Using the API to add a shared parameter to a regular schedule works fine.

But with the same macro, ScheduleDefinition.AddField throws an exception when run on a Key Schedule: "The field specified by schedulableField may not included in this ScheduleDefinition."

Using the Revit UI, these same shared parameters can be added to the Key Schedule

RVT with document macros is attached. Activate the "Wall Schedule" and run the macro to see it work. Activate the "Wall Style Schedule" and run the macro to get the exception.

		public void test()
		{
			Document doc = this.ActiveUIDocument.Document;
			ViewSchedule vs = doc.ActiveView as ViewSchedule;
			ScheduleDefinition def = vs.Definition;
			ExternalDefinition extDef = MakeSharedParameter(this.Application);
			
			using (Transaction t = new Transaction(doc, "D"))
			{
				t.Start();
				
				SharedParameterElement spe = SharedParameterElement.Create(doc, extDef);
				SchedulableField schedulableField = new SchedulableField(ScheduleFieldType.Instance, spe.Id);				
				try
				{
					ScheduleField scheduleField = def.AddField(schedulableField);
				}
				catch (Exception ex)
				{
					TaskDialog.Show("e", ex.Message);
				}	
				t.Commit();
			}
		}

[jeremy_tammik]

Dear Harry,

Thank you for your report, clear description and sample material.

Sorry to hear about this.

I logged the issue REVIT-196966 [ScheduleDefinition.AddField throws exception adding shared parameter to Key Schedule] with our development team for this on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.

You are welcome to request an update on the status of this issue or to provide additional information on it at any time quoting this change request number.

This issue is important to me. What can I do to help?

This issue needs to be assessed by our engineering team and prioritised against all other outstanding change requests. Any information that you can provide to influence this assessment will help. Please provide the following where possible:

• Impact on your application and/or your development.
• The number of users affected.
• The potential revenue impact to you.
• The potential revenue impact to Autodesk.
• Realistic timescale over which a fix would help you.
• In the case of a request for a new feature or a feature enhancement, please also provide detailed Use cases for the workflows that this change would address.

This information is crucial. Our engineering team has limited resources and must focus their efforts on the highest impact items. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.

Best regards,

Jeremy

[jeremy_tammik]

Dear Harry,

First response: The shared parameters can only be added to the key schedule when they are bonded. That's why UI can do that but the API code cannot. Further analysis is required by the shared parameter team to determine if this behavior is by design.

Best regards,

Jeremy

[jeremy_tammik]

Dear Harry,

A second response, from Dave Fagerstrom (do you happen to know him from your Autodesk days?):

I reviewed this with the team and the issue is that the schedule expects a parameter to already be bound to a category and to have type or instance set prior to being added to the schedule.  In Revit UI you cannot create a parameter that does not have these set, as it's part of the process of creating a project or shared parameter.

In this instance, if I'm understanding correctly, if creating new parameters for the schedule that are not already in the project, you will need to complete their creation by setting what category(ies) they apply to and their type/instance setting.  You may also want to set a PPG if you want to see these in the UI later on (they may default to Other).  Once this data is set adding it to the schedule should work as normal.

I hope this clarifies.

Cheers,

Jeremy