Skip to main content
G
gpedros8-Gravel
8-Gravel
March 9, 2022
Solved

Restricted Parameters Table

  • March 9, 2022
  • 1 reply
  • 1641 views

Hi,

I've create a restricted parameters table of fastners and it's working nice as expected. The only issue I'm having is, that I want the restricted parameters table to follow the part without having the file read each time Creo is started. I know it works with a restricted parameters file (not restricted parameters table) when you save the part. With the restricted parameters table, when saved off, it keeps the parameter name with only the last selected option from the drop-down list.

Is there a way to accomplish this?

Thanks

Best answer by sacquarone

Hello @gpedros 

 

Yes. This was what @MartinHanak suggested. No need anyway, as I give PTC Technical Support's answer here in this post.

 

What you're facing is a current limitation. When driving presence of parameters with pre-defined values coming from tables in restricted parameter files, according to guidance documented in article 66567, the names and values of parameters are walwyas read dynamically in the file where restricted_val_definition config.pro option points to.

 

In other words:

  • If system CAN access this file:
    • it's possible to create and modify parameters , based on the row selected in the table
    • Possible then for new and legacy objects
  • If system CANNOT access this file:
    • In new objects, the tables are not available when creating parameters (which makes sense obvioulsy)
    • in legacy objects where parameter driven by table were existing:
      1. The existing definition (which was produced when table was accessible) is persisted
      2. But it's not possible to access the table, because system does not find it anymore (tables are not supposed to be stored in parts, they are supposed to be always accessed dynamically on disk, where restricted_val_definition config.pro option points to).

         

This is illustrated in little movie below.

 

Based on above considretaion:

  • This use case is NOT eligible to be reported to our R&D as a SPR, because system works as expected technically in this use case
  • But we nevertheless understand what you have behind in mind (sharing objects with partners who do not have access to the restricted parametr definition file for example), and makes sense therefore to be reported as a new Idea in our PTC Community (for eventual considreation later by our Product Managers when building sepcs of our future versions)

 

Regards,

 

Serge

1 reply

M
MartinHanak24-Ruby III
24-Ruby III
March 9, 2022

Hi,

please discuss the issue with PTC Support.

S
sacquarone21-Topaz IAnswer
21-Topaz I
March 9, 2022

Hello @gpedros 

 

Yes. This was what @MartinHanak suggested. No need anyway, as I give PTC Technical Support's answer here in this post.

 

What you're facing is a current limitation. When driving presence of parameters with pre-defined values coming from tables in restricted parameter files, according to guidance documented in article 66567, the names and values of parameters are walwyas read dynamically in the file where restricted_val_definition config.pro option points to.

 

In other words:

  • If system CAN access this file:
    • it's possible to create and modify parameters , based on the row selected in the table
    • Possible then for new and legacy objects
  • If system CANNOT access this file:
    • In new objects, the tables are not available when creating parameters (which makes sense obvioulsy)
    • in legacy objects where parameter driven by table were existing:
      1. The existing definition (which was produced when table was accessible) is persisted
      2. But it's not possible to access the table, because system does not find it anymore (tables are not supposed to be stored in parts, they are supposed to be always accessed dynamically on disk, where restricted_val_definition config.pro option points to).

         

This is illustrated in little movie below.

 

Based on above considretaion:

  • This use case is NOT eligible to be reported to our R&D as a SPR, because system works as expected technically in this use case
  • But we nevertheless understand what you have behind in mind (sharing objects with partners who do not have access to the restricted parametr definition file for example), and makes sense therefore to be reported as a new Idea in our PTC Community (for eventual considreation later by our Product Managers when building sepcs of our future versions)

 

Regards,

 

Serge

    Terms & ConditionsAccessibility statement