wxAutoExcel
2.0.0
|
In this tutorial it is assumed that you have built wxAutoExcel library in required configurations and added it to your project, as described in docs/install.md.
It is also assumed you #include <wx/wxAutoExcel.h>
and are #using namespace wxAutoExcel
.
The tutorial is very brief and it is recommended to check out the bundled samples, starting with the Minimal sample.
Classes and methods
wxAutoExcel classes are named the same as MS Excel VBA classes, except their names start with wxExcel, e.g., Range is wxExcelRange
. Method names are the same as those of underlying MS Excel class, e.g., Range.Activate is wxExcelRange::Activate()
. Properties are are implemented as methods, prefixed with Get
and/or Set
, e.g. Range.Value is wxExcelRange::GetValue()
and wxExcelRange::SetValue()
. All wxAutoExcel classes are derived from wxExcelObject
. This class has several utility methods, their names end with an underscore so they can be easily distinguished from the methods that wrap the underlying MS Excel class methods and properties. Notable exceptions to this rule are wxExcelApplication::CreateInstance()
and wxExcelApplication::GetInstance()
.
Starting a new instance
Attaching to any running instance
This works analogically to wxAutomationObject::GetInstance()
, i.e., you can pass flags which affect its behaviour, such as the (default) wxAutomationInstance_CreateIfNeeded
. If you attempt attaching to a running instance this way, and there is more than one instance running, you cannot affect which one you get.
Attaching to an instance with a specified workbook open
Showing Excel window
MS Excel launched in automation mode has its window hidden, so you need to tell it to show itself if needed.
Closing the application
Once you are done with the application, do not want to use any of its objects and wish to close it.
If you want to use wxAutoExcel with Excel localised into languages other than English, I recommend setting its automation LCID to US English, e.g.
and you should be able to use English names of formulas and styles etc. regardless of the Excel user language. The LCID will be inherited by all "children" of the object. This unfortunately does not work in all cases and can have some side effects, see the matching entry in docs/FAQ.md.
Adding a new workbook
Opening an existing workbook
Obtaining ActiveWorkbook
Obtaining Worksheets collection and enumerating worksheets
Adding a worksheet
Simply adding a worksheet, it will be placed after the last existing worksheet
Adding a worksheet in the front of all others
Obtaining a range
See the bundled samples for more complex examples of obtaining ranges.
Reading and writing to/fro a range
See the bundled samples for more complex examples. See the bulkdata sample for an example on how to efficiently transfer a large number of values, using wxSafeArray
.
Formatting a range
Check the bundled charts sample for more examples.
Adding an embedded chart
Adding a chart sheet
Customising chart elements
wxWidgets error handling in wxAutomationObject
When an OLE automation call performed by wxAutomationObject
fails, wxWidgets tells the user with wxLogError()
, see ShowException()
in WXWIN/src/msw/ole/automatn.cpp
). This behaviour may not be most desirable, as the user probably does not understand the error message and the error information is not propagated to the calling code created by the application programmer. Unfortunately, the only way to prevent displaying the error to the user is to suppress logging with wxLogNull
. Creating a wxLogNull
instance suppresses all logging for the calling thread, so it has to be used with caution.
wxAutoExcel error handling
By default, wxAutoExcel in the release mode (i.e., when NDEBUG
is defined) prevents errors described above to be shown to user by wxWidgets, the setting is controlled by WXAUTOEXCEL_SHOW_WXAUTOMATION_ERROR
defined in wxAutoExcel_setup.h
. How wxAutoExcel itself behaves when an error is encountered is controlled by a wxAutoExcel-wide setting, see wxExcelObject::SetErrorMode_()
and wxExcelObject::GetErrorMode_()
. It is highly recommended to use wxAutoExcelObjectErrorModeOverrider
class to control how the errors are dealt with instead of calling the two methods. For example, one can have this code before and at the same scope with the part with wxAutoExcel calls, as the programmer may be interested in seeing the error message while the user is probably not.
When calling a method or property of a wxAutoExcel class wrapping a MS Excel object, the application programmer can learn whether the call succeeded by calling its operator bool()
. This operator returns true if the object has a valid automation interface and the last call (method or property) on it succeeded, false otherwise.