Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 726907 - Loops in Python Listener macro does not execute
Loops in Python Listener macro does not execute
Product: Fedora
Classification: Fedora
Component: libreoffice (Show other bugs)
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-07-30 14:14 EDT by Onyeibo Oku
Modified: 2011-08-01 02:22 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-08-01 02:22:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
a python listener macro that monitors A1 and adds/removes sheets based on its values (2.64 KB, text/x-python)
2011-07-30 14:16 EDT, Onyeibo Oku
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 39680 None None None Never

  None (edit)
Description Onyeibo Oku 2011-07-30 14:14:55 EDT
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):

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:

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

I downloaded OpenOffice 3.3.0 tarball from
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

This exonerates the macro script and leaves LibreOffice as the source of the
Comment 1 Onyeibo Oku 2011-07-30 14:16:31 EDT
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 02:22:37 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.