From 38d4df40a8f4205e6b46a06bccbe498e646464ea Mon Sep 17 00:00:00 2001 From: asv Date: Tue, 1 Mar 2005 10:46:54 +0000 Subject: [PATCH] Rolling back changes (commented out the modifications) made 28.02.05. The fix is not needed because the bug is not reproduced. --- src/GraphExecutor/DataFlowExecutor_PyDynInvoke.cxx | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/GraphExecutor/DataFlowExecutor_PyDynInvoke.cxx b/src/GraphExecutor/DataFlowExecutor_PyDynInvoke.cxx index ee6ed21..6dcdb43 100644 --- a/src/GraphExecutor/DataFlowExecutor_PyDynInvoke.cxx +++ b/src/GraphExecutor/DataFlowExecutor_PyDynInvoke.cxx @@ -158,7 +158,7 @@ PyObject * GraphExecutor::InNode::InitPyDynInvoke( char * PyFuncName , thePyRunMethod = Automaton()->PyFunction( PyFuncName ) ; - thePyRunMethod = NULL; + //thePyRunMethod = NULL; // asv 28.02.05 : VERY BAD fix of the following problem: after change of a function, // the changes are NOT taken into account by Automation - it returns PyObject of the OLD function. // so here we force re-automating the PyObject EVERY TIME, regardless if the function has changed or not. @@ -167,6 +167,8 @@ PyObject * GraphExecutor::InNode::InitPyDynInvoke( char * PyFuncName , // A better solution (to be implemented): store the PyObject NOT in Automation map, but in // InLine node itself! And if the method is changed - remove the PyObject and force to regenerate it. // But this means that PyObject must be stored in Editor's data model. + // asv 01.03.05 : the fix is not needed, the described bug is not reproduced. To investigate: + // WHERE PyObject is removed from Automation map on function change. if ( (*aPythonFunction).length() ) { if ( thePyRunMethod == NULL ) { -- 2.30.2