icon

Support Forum

[Frage] Python Part interactor, .pal and .pyp workflow

Schlagworte:
  • Allplan
  • 2026
  • Python
  • Parts

Hi,

I am trying to create an editable PythonPart with an Interactor in Allplan and I found some confusing behavior regarding .pyp vs .pal.

My setup:

Stairs_automation.pyp
Stairs_automation.py
Stairs_automation.pal

Inside the interactor constructor I originally loaded the palette like this:

result, self.build_ele_script, self.build_ele_list, self.control_props_list, \
self.build_ele_composite, partn_name, self.file_name = \
self.build_ele_service.read_data_from_pyp(
self.pyp_path + "\\Stairs_automation.pal",
self.str_table_service.str_table,
False,
self.str_table_service.material_str_table
)

Then I create geometry and save it as PythonPart using:

pyp_util = PythonPartUtil()
pyp_util.add_pythonpart_view_2d3d([test]) #test is AllplanBasisElements.ModelElement3D object

pyp_transaction = PythonPartTransaction(
self.coord_input.GetInputViewDocument()
)

pyp_transaction.execute(
AllplanGeo.Matrix3D(),
self.coord_input.GetViewWorldProjection(),
pyp_util.create_pythonpart(self.build_ele),
self.modification_ele_list
)

I was trying to change paths:
#self.build_ele.pyp_file_name = self.pyp_path + "\\Stairs_automation.pyp"
#self.build_ele.pyp_file_name = self.pyp_path + "\\Stairs_automation.pal"

Problem:

- the geometry was NOT even created
- the PythonPart was not editable
- double click did not reactivate the interactor

Then I changed ONLY this:

read_data_from_pyp(
self.pyp_path + "\\Stairs_automation.pyp",#I used test .pyp only for creating PP
...
)

instead of:

read_data_from_pyp(
self.pyp_path + "\\Stairs_automation.pal",
...
)

and suddenly:

geometry is created correctly
PythonPart is editable
double click works
interactor reopens correctly

So now I am confused because in many official Allplan examples I see .pal passed into read_data_from_pyp(...).

I would like to follow Allplan and create PP with .pal in creating palette

Questions:
- What is the correct/recommended workflow?
- Should read_data_from_pyp() always receive the main .pyp instead of .pal?
- What exactly is the role of .pal in editable interactors?
- Why does loading .pal directly break PythonPart creation/reactivation in my case?
- Is .pal only meant as palette definition while .pyp initializes the actual PythonPart metadata (pyp_file_name, hash, parameters, etc.)?

Any clarification would be greatly appreciated.

Thanks!

Hilfreichste Antwort anzeigen Hilfreichste Antwort verbergen

Hi,

Inside the interactor constructor I originally loaded the palette like this:

result, self.build_ele_script, self.build_ele_list, self.control_props_list, \
self.build_ele_composite, partn_name, self.file_name = \
self.build_ele_service.read_data_from_pyp(
self.pyp_path + "\\Stairs_automation.pal",
self.str_table_service.str_table,
False,
self.str_table_service.material_str_table
)

Seems like you are using the very old interactor contract. In this article we actually discourage from using it. So now I have so much questions, but the most important: why do you even want to use this contract? There newest contract does so much for you, your code looks cleaner and in the end you get the same data you can act upon.

I would also like to mention the ScriptObject contract, that is basically even simpler than the interactor. Interactor contract requires your class to have so many methods. In ScriptObject all that methods are optional. And you can still build your own interactor (just inherit from ScriptObjectInteractor), if you really need to go that deep.

Very long time ago, there was an approach to separate the palette (.pal) and the PythonPart-related information (.pyp). But even in that approach you had to had both files (see Drawing File Layout interactor).
Are your .pyp and .pal files identical?

Best regards,
Bart

Hi,

Inside the interactor constructor I originally loaded the palette like this:

result, self.build_ele_script, self.build_ele_list, self.control_props_list, \
self.build_ele_composite, partn_name, self.file_name = \
self.build_ele_service.read_data_from_pyp(
self.pyp_path + "\\Stairs_automation.pal",
self.str_table_service.str_table,
False,
self.str_table_service.material_str_table
)

Seems like you are using the very old interactor contract. In this article we actually discourage from using it. So now I have so much questions, but the most important: why do you even want to use this contract? There newest contract does so much for you, your code looks cleaner and in the end you get the same data you can act upon.

I would also like to mention the ScriptObject contract, that is basically even simpler than the interactor. Interactor contract requires your class to have so many methods. In ScriptObject all that methods are optional. And you can still build your own interactor (just inherit from ScriptObjectInteractor), if you really need to go that deep.

Very long time ago, there was an approach to separate the palette (.pal) and the PythonPart-related information (.pyp). But even in that approach you had to had both files (see Drawing File Layout interactor).
Are your .pyp and .pal files identical?

Best regards,
Bart