Opened 2 years ago

Closed 16 months ago

#14700 closed enhancement (fixed)

Allow to receive a multidimensional SafeArray as a result of wxAutomationObject call

Reported by: PB Owned by:
Priority: low Milestone:
Component: wxMSW Version: stable-latest
Keywords: Cc:
Blocked By: Blocking:
Patch: yes


This is related to #14637, particularly (comment 4)

It would be also nice to do something about the TODO in wxConvertOleToVariant()...

I propose a solution contained in the attached patch, it is a kludge but I really can't think of anything better.

Actually, having returned SafeArray only when it has more than one dimension might not be always for the best, e.g. when you get the values of MS Excel's Range.Value, this way you can get either a wxVariant with the list type if the Range has just one row or wxVariant with wxVariantDataSafeArray type if it has more - so you have to have two different code paths handling the returned values in the user code. But having two options, e.g. wxOleConvertVariant_ReturnSafeArrayAlways, wxOleConvertVariant_ReturnSafeArrayMultiDOnly may seem like an overkill...

The wxOleConvertVariant flags could be used for other "hacks", e.g. the one that attempts to fix wxAutomationObject::Invoke() breaking the contract and silently modifying its input parameters declared as const while still preserving the backward compatibility, also demonstrated in the attached patch.

As this just a proposal of a solution, I haven't written doxygen documentation for it yet.

Attachments (1)

wxOleConvertVariantFlags.patch download (16.2 KB) - added by PB 2 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 2 years ago by vadz

  • Keywords API decision-needed added
  • Milestone changed from 2.9.5 to 3.0
  • Status changed from new to confirmed

I agree with adding flags to the conversion functions, this seems to be a natural way of customizing their behaviour. But I'm not sure if having the flags in the object itself is a good idea, ideally it would make more sense to pass them to Invoke(). But this would, of course, mean modifying all the functions using it to take the flags too which is not ideal neither :-(

What do other people using OLE Automation code in wx think about this? What would be the most convenient way to say that you want to receive arrays as arrays?

comment:2 follow-up: Changed 2 years ago by vadz

  • Keywords docs-needed added; decision-needed removed
  • Milestone 3.0 deleted

I guess we'd have to go with this solution as nobody else proposed a better one.

OTOH it's not 3.0-critical, so while I'd apply the patch if you can complete it (i.e. add documentation and perhaps some tests?), I'm removing the milestone.

comment:3 in reply to: ↑ 2 Changed 2 years ago by PB

Replying to vadz:

I guess we'd have to go with this solution as nobody else proposed a better one. OTOH it's not 3.0-critical, so while I'd apply the patch if you can complete it (i.e. add documentation and perhaps some tests?), I'm removing the milestone.

So, which flags are to be added, just wxOleConvertVariant_ReturnSafeArray, which would be in effect only when the SAFEARRAY returned by COM call has more than one dimension, or...?

comment:4 Changed 2 years ago by vadz

I think it would be better, i.e. less surprising, to always return safe array when this flag is set. Why should 1D and 2D cases be treated differently? As long as it only happens when this flag is given, i.e. not by default, I don't see any problem with doing the logical thing and always returning a safe array.

comment:5 Changed 2 years ago by PB

  • Keywords API docs-needed removed

I have replaced the patch with the one with added documentation and a few basic tests. Please review carefully.

Not sure if those tests are actually of any use, but if they are to be added, I'm sure that the tests bakefile must be further modified. When testing if the tests compile, I just added the new file manually to VS 2008 solution, noticing the solution doesn't link against the core library?

Changed 2 years ago by PB

comment:6 Changed 16 months ago by vadz

Although this normally shouldn't be applied to 3.0 any more, as it's a new feature and not a bug fix, I feel it was my fault for letting it unattended for so long and the patch looks almost perfect to me (just required a few fixes to the test), so I'm going to take the risk of applying it now.

Thanks again for your work on this and other wxAutomationObject improvements!

comment:7 Changed 16 months ago by VZ

  • Resolution set to fixed
  • Status changed from confirmed to closed

(In [75004]) Add wxOleConvertVariant_ReturnSafeArrays flag for better SAFEARRAY handling.

While we can't change the type of wxVariant to which SAFEARRAYs are converted
by default, it's much more convenient to work with the variant objects of the
correct type, i.e. using wxVariantDataSafeArray, when dealing with SAFEARRAYs,
so add a flag which can be set to tell a wxAutomationObject to behave in this

Closes #14700.

Note: See TracTickets for help on using tickets.