Hi!!! This was a great report. I have submitted a fix in the master of Pharo-COM.
Basically the problem was to free twice the BSTR in the Variant. It was being free in the access to the value and in the free of the struct. Why it works with other BSTR when they are smaller, I cannot know. I have added another smoke test using Word Can you try the fix? Thanks, both for helping me with the reports, they were great. On Wed, Apr 8, 2020 at 9:37 AM PBKResearch <pe...@pbkresearch.co.uk> wrote: > > Tomaz, that was my understanding from the VBA piece you cited yesterday. So > presumably it must be something in Pharo-Com which imposes the limits we have > seen. I am OK at the moment, because all this work is just an exploration of > possibilities; I can wait until you and Pablo have sorted it out. But from > the results of your tests, a maximum of 16K in 64-bit systems must be a > serious limitation, so something in Pharo-Com needs fixing. > > > > For my immediate work, I shall continue exporting the full text using > MailItem.SaveAs; my further processing uses files I have exported manually in > this way, so it’s not a problem. > > > > Thanks > > > > Peter Kenny > > > > From: Pharo-users <pharo-users-boun...@lists.pharo.org> On Behalf Of Tomaž > Turk > Sent: 08 April 2020 07:58 > To: Any question about pharo is welcome <pharo-users@lists.pharo.org> > Subject: Re: [Pharo-users] Automation of MS Office from Pharo > > > > Thanks, Stephane, for the acknowledgement. Peter, as I understand, the limits > in COM BSTR data type are defined by the header's length prefix (which is 4 > bytes) and software implementatios - for instance, string data type in Visual > Basic for Applications is described as "a variable-length string can contain > up to approximately 2 billion (2^31) characters", which is in line with the > BSTR header. I'm not sure if the OS architecture (32 and 64 bit) influences > these values. > > > > Best wishes, > > Tomaz > > > > -- Pablo Tesone. teso...@gmail.com
