A fix for a bug was integrated. The bug: Python function (body) was changed, but...

diff --git a/src/GraphExecutor/DataFlowExecutor_PyDynInvoke.cxx b/src/GraphExecutor/DataFlowExecutor_PyDynInvoke.cxx
index 4a553e4228567673a55d78f9b3f2582549ed7fb5..ee6ed2168a7c5e01e1b9dfd093e7bb369cd97c41 100644 (file)
--- a/src/GraphExecutor/DataFlowExecutor_PyDynInvoke.cxx
+++ b/src/GraphExecutor/DataFlowExecutor_PyDynInvoke.cxx
@@ -155,7 +155,19 @@ PyObject * GraphExecutor::InNode::InitPyDynInvoke( char * PyFuncName ,
 
   if ( strlen( PyFuncName ) ) {
     Automaton()->PyLock() ;
+    
     thePyRunMethod = Automaton()->PyFunction( PyFuncName ) ;
+    
+    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.
+    // Once again - it is a very bad solution, it fully discards the whole idea of automation,
+    // here is it done as a quick fix for a bug. 
+    // 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.
+    
     if ( (*aPythonFunction).length() ) {
       if ( thePyRunMethod == NULL ) {
        unsigned int i ;