Bug 726907

Summary: Loops in Python Listener macro does not execute
Product: [Fedora] Fedora Reporter: Onyeibo Oku <twohotis>
Component: libreofficeAssignee: Caolan McNamara <caolanm>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 15CC: caolanm, dtardon, ltinkl
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-01 06:22:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
a python listener macro that monitors A1 and adds/removes sheets based on its values none

Description Onyeibo Oku 2011-07-30 18:14:55 UTC 
Description of problem:
I'm testing a simple python listener macro for Calc (see attachment).  I have
the script at <home>/.libreoffice/3/user/Scripts/python/era/

The script attaches a listener to cell A1 which monitors its values then
adds/removes sheets to the workbook accordingly. The macro allows a minimum of
2sheets. At values 0 and 1, nothing should happen but at the value of 2, an
extra sheet is required. Likewise, reducing from a value of 5 to 1 or 0 should
remove 4 sheets preserving the default 2sheets.

The macro works well (as is) with the 'FOR' loop commented-out/disabled. To
test the algorithm, I'm using E1 for visual feedback to see what should happen
when the loops are activated. It works fine.  However, activating the loops
produce an entirely different result. The logic fails in unexpected ways
because the loop does not execute. I'm running this on Fedora 15.

I have also tried 'WHILE' loops. The result was more dramatic. It crashed
LibreOffice completely. Is there a limitation on the use of loops within
listeners or am I right in seeing this behaviour as that of a nasty bug?

Version-Release number of selected component (if applicable):
3.3.1

How reproducible:
Been like this on this machine for 3-4days.

Steps to Reproduce:
1. Install libreoffice-calc with libreoffice-pyuno
2. put the attached python script in <home>/.libreoffice/3/user/Scripts/python/era/ (create missing folders as necessary)
3. Start Calc and type-in 2 in A1 (make sure there are three sheets ... Sheet1, Sheet2, Sheet3)
4. Goto Tools Menu -> macros -> run-macro -> My Macros -> era -> *
5. Run Start() from the Macro dialog
5. Type 4 in A1
  
Actual results:
Nothing

Expected results:
Two more sheets should be added

Additional info:
I have confirmed this to be a bug.  It is possible that this anomaly was
introduced during packaging.  I have also filed a similar report here: https://bugs.freedesktop.org/show_bug.cgi?id=39680

CONFIRMATION:
-------------
I downloaded OpenOffice 3.3.0 tarball from
http://download.services.openoffice.org/files/stable/3.3.0/OOo_3.3.0_Linux_x86-64_install-rpm-wJRE_en-US.tar.gz,
and installed it using the setup binary.  I created 'python' directory
'<home>/.openoffice.org/3/user/Scripts/python/era/ and put the attached python
script there.  Started OOo and fired up the script.  It worked, 100% as
designed!

This exonerates the macro script and leaves LibreOffice as the source of the
anomaly
Comment 1 Onyeibo Oku 2011-07-30 18:16:31 UTC 
Created attachment 515983 [details]
a python listener macro that monitors A1 and adds/removes sheets based on its values
Comment 2 David Tardon 2011-08-01 06:22:37 UTC 
It works fine with the following change:

@@ -19,7 +19,7 @@ class myListener(XModifyListener, unohel
         self.formerVal = numOfSheets-1
     
     def modified(self, oEv):
-        currentVal = oEv.Source.Value
+        currentVal = int(oEv.Source.Value)
         self.diff = currentVal - self.formerVal
         if (self.formerVal < self.minSheets) and (currentVal < self.minSheets):
             sheetManager("Reserve", "") #pass

It seems that the type of oEv.Source.Value changed from int to float and range() does not like that. That is actually not an error, as the description of method com.sun.star.sheet.XCell.getValue is "returns the floating point value of the cell." It is even possible that the change was in Python, as the tarball from openoffice.org site contains bundled python 2.3, which might allow floats as arguments to range().

Btw, I do think you should use instance variables for diff and formerVal.