Apache OpenOffice (AOO) Bugzilla – Issue 97210
Error when opening spreadsheet with VBA that refers to a cell in the spreadsheet
Last modified: 2013-02-24 20:56:48 UTC
Error message when starting spreadsheet with basic code. Message: ----------------------------------------- Basic runtime error. An exception occured. Type com.sun.star.uno.RuntimeException. Message: Can't extract model from basic (its obviously not set yet) therefore don't know the currently selected document. ----------------------------------------- Basic code starts with: Option VBASupport 1 After pressing OK for each basic call, the spreadsheet starts and the code is available. All cells referring to code must be entered again to run the code. After that, the spreadsheet can be used normally. Note: same problem in version 2.4.2
Created attachment 58780 [details] Error Message and used Basic Code
Can you please attach a spreadsheet to which this problem applies?
Created attachment 58795 [details] Sample spreadsheet which gives error messages when opening
-The error message is not only under Vista, but also with XP. -To check, I installed OO office 2.4.2, but this returned the same errors.
Confirming this Issue with * Windows 2000, OOo 2.4.0 * Windows 2000, OOo 3.0 (OOO300m9) * Ubuntu 7.10, OOo-dev 3.1.0 (DEV300m37) When a spreadsheet uses a user defined function, that is realized by VBA and this function refers to some data in a cell of the spreadsheet, the function fails during opening of the spreadsheet. This results in an error message (only in OOo 3.0 and OOo-dev 3.1.0) and the function returns no value (in OOo 2.4.0 as well as in OOo 3.0 and OOo-dev 3.1.0). During opening, when the document´s formulas are recalculated, VBA is running but has no acces to the model yet. After having opened the spreadsheet one can again recalculate all formulas manually by SHIFT+CRTL+F9, which finally delivers correct results by the user defined function. The scope of this issue is, that Excel spreadsheets with user defined functions cannot be used with OOo properly. The same is true for ODS documents that have been created by converting a former Excel document. You can reproduce this problem using the spreadsheet, that I will attach. It contains the following simple VBA code: Option VBASupport 1 function fktFoo() dim varFoo as variant msgbox "Hello" varFoo = activesheet.cells(1,1) '... '... '... fktFoo = varFoo msgbox "Hello again" End function The critical statement is "activesheet.cells(1,1)" where the functions refers to a cell in the spreadsheet. Cell B1 contains the following formula: =FKTFOO() When you open this spreadsheet the formula will be recalculated automatically, but this fails. See the attached screenshot for the exact error message. After this try SHIFT+CRTL+F9 and the recalculation will be successful.
Created attachment 58796 [details] spreadsheet document mentioned above
Created attachment 58797 [details] Screenshot showing the error message
Thanks for fast response! The issue is now solved for me, I added an 'on error' statement before and after reading spreadsheet data. This, together with ctrl+shift+f9 makes it possible to open the spreadsheet without error messages. However, in next releases of OpenOffice it should be better to change the sequence of events during opening such that user defined functions are executed when spreadsheet data is available.
Noel, looks like your construction site ;-) @sweigel: Please don't set target milestones if not confirmed by a developer who commits himself to work on it. Thanks.
there are a couple of problems here 1. using the 'Option VBASupported 1' to trigger the vba support in an ods is definitely unsupported. This option is really only useful when running a native imported document. a) Once a document has been saved as ods key transient information is lost e.g. codenames and other such data. ( I am thinking about supporting this, but... future work ) b) in an ods document vba-mode basic could call non-vba mode code libraries etc. mixing openoffice basic, vba-mode basic and non-mso document is NOT a good idea :-( sorry about that 2. The problem you see is not an vba problem per. se. but to do with how and when openoffice identifies the active document, the 'activesheet.cells' call fails because when activesheet is called unfortunately openoffice hasn't yet being told there is a what the active document is. a) It would seem that the window of a loading document isn't 'Activated' until after the load completes ( but I would have t investigate that further.... after Christmas that is ) b) I would bet if you have a different calc document open and open the problem document you will not get the error ( because it will thing the previously opened document is the active one ) c) Furthermore I would bet the same problem is present in general basic in openoffice for the 'ThisComponent' variable ( in fact vba uses the 'ThisComponent' variable to determine the active docuemtn
Created attachment 62416 [details] another test file
Created attachment 62417 [details] and another
Created attachment 62418 [details] and yet another test document
Some notes for testing, just some ideas that can be used with the test documents attached to this document * all-form-controls.ods This document contains all ( afaik ) form controls in openoffice, additionally there are 2 buttons, one "hide" ( makes all controls invisible ) and the other "sow" makes all the controls visible. a) test initial state when the document is loaded all controls are visible, pressing the "hide" btton should hide all the controls. b) test control state after a repaint force a repaint ( close the window, minimize etc. ) controls should still be invisible. c) test change of view ( ensure model preserves the visibilty state ) switch sheets ( e.g. switch to sheet 2, then back to sheet 1 ) the controls should still be invisible d) test visibility in design mode. If the controls obeyed their model regarding visibility in design mode it would be hard to find invisible controls on the document to modify them ;-) switch to design mode, all controls should become visible. e) test the property browser for form controls while still in design mode set the visibility attribute for a couple of controls to be visible ( note: those controls ), turn off design mode, the controls you set to be visible should have remained visible, the others controls should be ininvisible the above is a basic set of steps, just for illustration of what should be tested, with more imagination more combinations etc. can be tested * odf-some-invisible-persisted.ods This document tests the persisted state of some controls a) open the document, b) ensure that the only controls visible are those in the red boxes c) press the toggle button, the previously invisible controls ( in the blue boxes ) should become visible and vice-versa d) reload the document, state should be as in step b) * hiddenbutton.xls import/export of visibility attribute from MSO form documents a) open the excel document, it contains 2 push buttons, 1 is visible, the other invisible, note only "CommandButton1" is visible b) enter design mode, you should see command button 2 c) in design mode change CommandButton1's visible state to true, export the document as hiddenbutton-modified.xls d) reload document, see that the 2 buttons are visible e) load the document in MSO Excel and verify it is displayed as expected Dialogs/Userforms * DialogStepVistest.ods Tests use visibilty attributes on controls with basic dialogs a) press the button, a Dialog will launch b) verify basic behaviour, each command button is assigned a different step value, the topmost button has a step value of 1, the next 2, and the last one 3. Dialogs display controls that have a step value of 0 or controls that have a step value equal to the present value of the step attribute of the dialog itself. The dialogs step value can be modified using the scroll bar, the dialogs step value is displayed in the numberic field. expected behaviour: Dialog Step 0 all 3 buttons displayed 1 top button displayed 2 middle button displayed 3 bottom button displayed c) while the dialog is executing, clicking the toggle button changes the visible state of the button associated with that step, e.g if you press the toggle button when the dialog step = 1 you will notice that the button on step 1 disappears. Setting the scroll bar to zero you will notice that only the bottom 2 buttons are visibile d) Check after reload, e.g. dismiss the dialog and press the button again to relaunch. state should be as it was in b) again e) test attribute persistence, o use the script browser to edit the dialog o when the dialog is opened, select the topmost button & change its visibilty state to false o select another control, one that is present on all steps e.g. the "toggle Numeric field" button and change its visibility state to false. o Save the document as DialogStepVistest-modified.ods, o Close & reload document, launch dialog from the button o ensure that at step 0, the bottom 2 buttons are displayed, and that at all steps the " toggle Numeric.." f) design mode, Open the dialog editor, notice all invisible controls ( at the current dialog step ) are visible, changing the step should show any invisible controls on that step value, e.g. setting the dialog step to 1 and the top button should still be visible * UserformVisibility.xls test userform import a) load the document b) insert the following code ( the vba code obviously will not work ) Sub Dialog1Show DialogLibraries.LoadLibrary( "Standard" ) oDialog1 = CreateUnoDialog( DialogLibraries.Standard.UserForm1 ) oDialog1.Execute() End Sub c) after lauching the document the opened dialog should contain just a button. open the IDE and in design mode you should see checkbox ( imported in invisible mode ) d) open the document in MSO and verify the checkbox is also invisible
please ignore the previous comment and precious 3 attachments, it should be obvious these were intended for a very different bug :-/