I upgraded to KNIME 3.7.1 yesterday but today noticed that some of my configuration dialog boxes are displaying the wrong settings. The problem seems to mostly impact the nodes that I developed myself - particularly the complicated nodes with many configuration settings. My simple nodes seem to be ok, and I haven’t yet found an out-of-the-box KNIME node that has been impacted.
Here’s a screenshot of an impacted dialog box (note this may seem simple but there are a lot more settings in the other two custom panels):
But instead of showing these settings, the dialog is showing the default values. Note that both string values and numeric values are being impacted:
“Focus Product Only”
“Alter Price by Percentage”
Change Factor: “10.0”
In addition to this problem, I’ve also been impacted by another KNIME 3.7 “Workflow Freeze” issue that may be related. That issue seems to involve “SWT handles” getting exhausted on Windows platforms.
An additional observation. The wrong settings seem to follow a correct setting controlled by a variable. That is to say, the top setting is correct but, as it is controlled by a Flow Variable, it may be causing the following settings to display incorrectly.
Once we’ve run out of SWT handles on Windows, there is no way back except to kill the application, and the application’s UI will be non-responsive (plus, you would see error messages in the log about the application having run out of handles.)
It sounds like you’re saying that the application is responsive (you can open and close dialogs, execute nodes, configure other nodes, etc) but that the widget content for this particular node’s dialog is not correctly reflecting the state - ya?
If this is the case, were i to make a list of suspects, i would say a likely cause would be that an exception is being encountered in the code which is part of the cycle that populates those widgets. Even were there not an exception being logged, since this is SWT and i’ve seen SWT swallow exceptions without making a peep, i would run KNIME from Eclipse in debug mode and add a breakpoint to catch uncaught NPE (to start with) exceptions.
(… and then there’s always the developer-scoundrel’s dirty friend of “a lot of logging statements”)
WRT handing over the workflow, i am technically a contractor as opposed to a FTE - i’ll ask Bernd / Peter whether i am covered by your NDA. (That being said, since you’re technically competent enough to write a custom node, you’ll likely be able to narrow down the culprit through debugging / logging before i’d get to it.)
The problem is intermittent. The configuration dialog works perfectly fine for some workflows, but on other machines running the same workflow the configuration settings are displayed incorrectly.
I’ve never seen the problem before - it only appeared after upgrading to KNIME 3.7.1 and after installing your patch (although that may have been a coincidence). It really freaked me out when I spotted it - hundreds of nodes with incorrect settings - I definitely would have noticed had it been an ongoing problem.
But I don’t think the problem is on my side. I rarely catch exceptions (preferring to fix the root of the problem) and I rely heavily on KNIME’s own dialog controls. The examples I sent are all standard KNIME controls and I don’t have any access to put breakpoints around the KNIME internals.
When I get a chance I’ll try and find an example of the same thing happening to a common KNIME node. In the meantime, when you talk to the KNIME folks please ask them if they’ve got any theories!
It’s definitely not an impossibility that the patch jar introduced an unforeseen problem, the class file differences between the shipping 3.7.1 version of the jar and the patch are NodeContainerFigure and NodeContainerEditPart but NodeContainerEditPart is responsible for kicking off the opening of the node dialog.
That being said, there have not been any other changes to NCEP since the 3.7.1 release (so it would not be the case, for example, that there is some new dialog-opening-affecting code that didn’t exist in the 3.7.1 release jar.)
That being said, *2, recalling from the other thread, you upgraded from 3.5.2 to 3.7.1, and it was in 3.5.2 that you last saw no problems with the settings being picked up in the dialog panes?
FWIW, and three cheers for Java once again, you can put breakpoints in any decompiled class code in Eclipse (and other Java IDEs); sometimes it acts hinky (i’ve noticed with ChemAxon jars for whatever reason) like stopping on a nearby line instead of the one specified in the decompiled version - but you can do it.
… so you could put break points where ever you want (and, you also have to have your own implementations of loadSettingsFrom() in your NodeDialogPane subclasses, no? so you could pick up the trail backwards through the stack from there.)
(Without getting into a debate about the merits of catching exceptions, what i was saying about SWT and exceptions is that SWT does, in some cases, swallow exceptions itself which prevents you from being notified via the usual logging and can be better sussed out with a debugger.)
