Hello Pablo

Success! I have rerun one of the troublesome cases, with no problem. I then re-ran the test on the latest 16 messages, collecting all the HTML outputs in an array, which took just over 5 secs total; quicker than I expected. The longest texts, from the most verbose newsletters, run from 267K to over 300K, so that is where they ran into the limit we found yesterday.

I now know that I can pass the HTML to the XMLHTMLParser in memory, without saving to file first; this will be more convenient. Thanks for the prompt help.

@Guillermo - All this is a proof of possibility, it will need to be combined with other bits I am working on to make the automated system I want. I shall let you know when it is worked out - but it won't be in the next few days!

Thanks to all

Peter Kenny

-----Original Message-----
From: Pharo-users <pharo-users-bounces@lists.pharo.org> On Behalf Of Guillermo Polito
Sent: 08 April 2020 09:20
To: Toma�� Turk <tomaz.turk@ef.uni-lj.si>; Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] Automation of MS Office from Pharo

Cool, thanks to the three :)

@Peter, I���d like if you tell us at the end if you had success at automating you mail workflow ^^

> El 8 abr 2020, a las 10:15, Toma�� Turk <tomaz.turk@ef.uni-lj.si> escribi��:
>
> Thanks Pablo for your quick response! I tested 32 and 64 bit images with >1.000.000 strings and it works just fine.
>
> Best wishes,
> Tomaz
>
>
> ------ Original Message ------
> From: "tesonep@gmail.com" <tesonep@gmail.com>
> To: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>
> Cc: "Toma�� Turk" <tomaz.turk@ef.uni-lj.si>
> Sent: 8.4.2020 9:54:35
> Subject: Re: [Pharo-users] Automation of MS Office from Pharo
>
>> 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 <peter@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-bounces@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.
>> tesonep@gmail.com
>
>