Bug 39680 - EDITING, Loops in Python Listener macro does not execute
Summary: EDITING, Loops in Python Listener macro does not execute
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.3.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Not Assigned
Depends on:
Reported: 2011-07-29 23:05 UTC by Onyeibo
Modified: 2013-11-24 22:03 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

a python listener macro that monitors A1 and adds/removes sheets based on its values (2.41 KB, text/x-python)
2011-07-29 23:05 UTC, Onyeibo

Note You need to log in before you can comment on or make changes to this bug.
Description Onyeibo 2011-07-29 23:05:32 UTC
Created attachment 49738 [details]
a python listener macro that monitors A1 and adds/removes sheets based on its values

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?
Comment 1 Onyeibo 2011-07-30 10:42:19 UTC
I have confirmed this to be a bug.  It is possible that this anomaly was introduced during packaging, so I'm filing a duplicate report at Fedora bug tracker for LibreOffice.

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 2 David Tardon 2011-07-31 23:43:51 UTC
The type of oEv.Source.Value is float (exactly as the description of method com.sun.star.sheet.XCell.getValue says) and it seems that range() does not like that. Everything works fine after retyping the value to int.