Hide Forgot
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
Created attachment 515983 [details] a python listener macro that monitors A1 and adds/removes sheets based on its values
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.