| Summary: | FILEOPEN: sometime import controls in xlsm document don't fire macros | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Noel Power <nopower> |
| Component: | filters and storage | Assignee: | Noel Power <nopower> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | jmadero.dev |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | test file | ||
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 78376 [details] test file Seems sometime we get a situation where an import ole control won't fire, event bindings in vba for ole controls are dynamic, in other words the existence of the appropriately named VBA event handler procedure is enough to ensure that handler is associated/bound to various events of the associated control. However to prevent 'normal' controls behaving the same way there is a mechanism to prevent that event handling being exercised. It's controlled by the 'GenerateVbaEvents' property for each control. The GenerateVbaEvents property is examined by the forms layer when inserting controls. However it seems that in some cases the order in which things are called is not quite expected, e.g. normally we would expect that all the controls are read ( and properties including GenerateVbaEvents applied ) before the forms layer code that examines 'GenerateVbaEvents' ( see OInterfaceContainer::implInsert in forms/source/misc/InterfaceContainer.cxx ) is called. I have come across at least one example where this is causing problem ( see attachment )