Dialog Configuration adapts with connection change


I have one problem with the node dialog updates. My situation is:

  1. Node Dialog is configured with PortObjectSpec, to assign the available include lists.

public void loadAdditionalSettingsFrom(final NodeSettingsRO settings, final PortObjectSpec specs) throws
NotConfigurableException {

} }

Now, when I change the connection of its Input Port to another Node, the configuration can’t update and has the same values as before.
How to solve it??
2. another situation is,
When I simply reload the workflow, it doesn’t need the PortObjectSpec configuration again, while the node is new imported, it needs to load data from the PortObjectSpec. how to test this situations and decide to use PortObjectSpec or not.


One notice:
I tried to set the values empty in the method NodeModel#reset, but it didn’t work.

protected void reset() {
// TODO: generated method stub
m_traceAttrSet.setIncludeList(new String[0]);
m_traceAttrSet.setExcludeList(new String[0]);



I don’t really understand what you actually want to do.

Could you please give a high-level description of what you’re currently doing? Maybe screenshots of your dialog might help to clarify things. What behavior are you expecting when changing the input connection? Did you write that PortObject yourself? What’s the type of m_traceAttrSet?


Hi @Mark_Ortmann,
thanks at first for your reply. I will try to explain my situation more clearly with screen shots.

This is the workflow that I test on.Table2XLogConverter produces one customized Out PortObject and pass it to the second node XLog2Table Convertor. The second node configures its NodeDialog based on the PortObjecSpec of OutPortObject.

This is the NodeDialog for the second node XLog2Table Converter. First Configuration is to choose trace Attribtues, whose value will be store in m_traceAttrSet in the codes.

What is m_traceAttrSet?
m_traceAttrSet is a SettingsModelFilterString used for storing the attribute set. The similar situation is with m_eventAttrSet.
They will be configured in NodeDialog and passed to NodeModel later.
m_traceAttrSet has available choices from the PortObjectSpec.

What I mean Connection Change
The NodeDialog is connected to an OutPortObject, which is customized and has its customized PortObjectSpec coded by me. When the OutPortObject changes due to different configuration, so does the PortObjectSpec, I consider it is a connection change. Because PortObjectSpec changes, the possible choices for SettingsModelFilterString m_traceAttrSet should also be updated.

Problems with Configuration on m_traceAttrSet
There are two situations for the value change of m_traceAttrSet.

  1. when dragging the node and connect it with OutPortObject at the first time. Here, PortObjectSpec should provide the values for the initialization totally.
  2. when reloading from the setting, i.e., reopening the workflow, or simply reconfiguration the node after the exection on it. In this situation, we don’t need to check the PortObjectSpec again, and m_traceAttrSet should show with the old values configured last time.

However, I can’t find a way to detect those two situations and give the corresponding possible set for m_traceAttrSet.



I assume you wrote the include and exclude dialog yourself?

It sounds to me that you want to achieve something similar to what is done by the Column Filter dialog, e.g., Column Filter node. If this is the case looking into DialogComponentColumnFilter2 and SettingsModelColumnFilter2 might be a good starting point.

Does this help to resolve your issue?


Hi @Mark_Ortmann,

Thanks for your reply.
Yap, I have followed the coding style like DialogComponentColumnFilter2 to write my own ComponentFilter, but the SettingsModel are predefined as SettingsModelFilterString. The original codes can be found here for NodeDialog and here for DialogComponentAttributesFilter

After looking through the codes, I find the method listed below might be the key point.

	protected void checkConfigurabilityBeforeLoad(PortObjectSpec[] specs) throws NotConfigurableException {
		// TODO Auto-generated method stub

Is this true?


Hi @Mark_Ortmann,

I think, in simple words, the key to this problem is how to detect the nodes connection changes. The list needs renewing from PortObjectSpec only if its Input connection is changed with the Output Port Object from another node. If there is a signal from node for such connection changes, I can detect it and reload the configuration with PortSpec.
However, is there the signal?? And how to get it?


Hi, this problem gets solved with the following method:

  1. assign the available list in NodeModel#configure(). In this way, it checked automatically every changed state in the connected workflow.
  2. add method in NodeDialog#
public void loadAdditionalSettingsFrom(final NodeSettingsRO settings,
            final PortObjectSpec[] specs) throws NotConfigurableException { }

In this method, the list will be updated with replaceItemList. In this way, it changes the choices in the DialogComponents.
Pay attention that only adding the ListItem in the constructor of NodeDialog is not enough to update the lists with every changes.


1 Like


nice that you found a way how to solve the problem yourself. Basically we don’t encourage changes of the settings during Model#configure, except not settings have been set before.

An easy way to identify if the connection changed is to give your PortObjectSpec an unique ID (UUID).


can you give more details about the unique ID for PortObjectSpec?? I could set it, but how to detect it during the running process??


You wrote your own PortObject spec right? So every spec you create could carry a unique ID <UUID.randomUUID()>. That ID is stored your settings and whenever you opened the dialog you compare the current uuid with the one stored. During configure you can check if the UUID changed, i.e., the input and then check if the old configuration is still valid. You see where I’m going here?

But I probably still don’t understand the problem in enough detail to provide you with the best solution. I rlly thought that adapting the ColumnFilter stuff would actually solve your problem.

yes, I see your point. I thought there was a central monitor that checks the overall connection changes in workflow.
If the check only happens with the dialog open or NodeModel#configure. It doesn’t help so much.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.