Issue 97210 - Error when opening spreadsheet with VBA that refers to a cell in the spreadsheet
Summary: Error when opening spreadsheet with VBA that refers to a cell in the spreadsheet
Status: CONFIRMED
Alias: None
Product: App Dev
Classification: Unclassified
Component: vba (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: ms_interoperability
Depends on:
Blocks:
 
Reported: 2008-12-12 15:54 UTC by wj_vd_linden
Modified: 2013-02-24 20:56 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Error Message and used Basic Code (24.83 KB, application/vnd.oasis.opendocument.text)
2008-12-12 15:59 UTC, wj_vd_linden
no flags Details
Sample spreadsheet which gives error messages when opening (59.12 KB, text/plain)
2008-12-13 14:22 UTC, wj_vd_linden
no flags Details
spreadsheet document mentioned above (7.66 KB, application/vnd.oasis.opendocument.spreadsheet)
2008-12-13 16:34 UTC, Stefan Weigel
no flags Details
Screenshot showing the error message (13.25 KB, image/png)
2008-12-13 16:36 UTC, Stefan Weigel
no flags Details
another test file (12.79 KB, text/plain)
2009-05-21 22:34 UTC, noel.power
no flags Details
and another (21.00 KB, application/vnd.ms-excel)
2009-05-21 22:35 UTC, noel.power
no flags Details
and yet another test document (25.00 KB, application/vnd.ms-excel)
2009-05-21 22:36 UTC, noel.power
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description wj_vd_linden 2008-12-12 15:54:05 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
Comment 1 wj_vd_linden 2008-12-12 15:59:58 UTC
Created attachment 58780 [details]
Error Message and used Basic Code
Comment 2 Stefan Weigel 2008-12-12 18:39:09 UTC
Can you please attach a spreadsheet to which this problem applies?
Comment 3 wj_vd_linden 2008-12-13 14:22:22 UTC
Created attachment 58795 [details]
Sample spreadsheet which gives error messages when opening
Comment 4 wj_vd_linden 2008-12-13 15:41:42 UTC
-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.
Comment 5 Stefan Weigel 2008-12-13 16:33:23 UTC
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.
Comment 6 Stefan Weigel 2008-12-13 16:34:46 UTC
Created attachment 58796 [details]
spreadsheet document mentioned above
Comment 7 Stefan Weigel 2008-12-13 16:36:30 UTC
Created attachment 58797 [details]
Screenshot showing the error message
Comment 8 wj_vd_linden 2008-12-14 11:04:44 UTC
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.
Comment 9 ooo 2008-12-17 14:07:56 UTC
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.
Comment 10 noel.power 2008-12-22 11:38:49 UTC
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  
 
Comment 11 noel.power 2009-05-21 22:34:35 UTC
Created attachment 62416 [details]
another test file
Comment 12 noel.power 2009-05-21 22:35:22 UTC
Created attachment 62417 [details]
and another
Comment 13 noel.power 2009-05-21 22:36:24 UTC
Created attachment 62418 [details]
and yet another test document
Comment 14 noel.power 2009-05-21 22:37:27 UTC
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

Comment 15 noel.power 2009-05-22 08:35:00 UTC
please ignore the previous comment and precious 3 attachments, it should be
obvious these were intended for a very different bug :-/