7 Messages
Digest #3005
Messages
Fri Mar 14, 2014 7:58 am (PDT) . Posted by:
rajarjrtj
Hi Randy,
Haven't had this problem before over 4 years of usage.
I have your excellent! SMF addin running on a workbook that is connected to IB API. For some reason, today the {RCHGetYahooHistory} tables appear to update/re-compute every 2000ms that the IB API updates, which is not typical, and which has increased the workbook computation time from ~ 1 second, to 90+ seconds. Unfortunately, it is now unusable for interday ALGO use.
Any help would be greatly appreciated. Thanks
Haven't had this problem before over 4 years of usage.
I have your excellent! SMF addin running on a workbook that is connected to IB API. For some reason, today the {RCHGetYahooHistory
Any help would be greatly appreciated. Thanks
Fri Mar 14, 2014 8:26 am (PDT) . Posted by:
"Randy Harmelink" rharmelink
The RCHGetYahooHistory() formulas should be non-volatile, unless you've
made them volatile. You aren't using something like NOW() or TODAY() to set
a date, are you?
Otherwise, have you had a recent update of the API? Possibly it's
generating a "recalculate all" with each update?
A workaround might be to convert all of the RCHGetYahooHistory() functions
into values, so that they don't recalculate. The underlying data isn't
going to change during the day anyway.
On Fri, Mar 14, 2014 at 7:58 AM, <rajarjrtj@yahoo.com> wrote:
>
> Haven't had this problem before over 4 years of usage.
>
> I have your excellent! SMF addin running on a workbook that is connected
> to IB API. For some reason, today the {RCHGetYahooHistory} tables appear to
> update/re-compute every 2000ms that the IB API updates, which is not
> typical, and which has increased the workbook computation time from ~ 1
> second, to 90+ seconds. Unfortunately, it is now unusable for interday ALGO
> use.
>
> Any help would be greatly appreciated. Thanks
>
made them volatile. You aren't using something like NOW() or TODAY() to set
a date, are you?
Otherwise, have you had a recent update of the API? Possibly it's
generating a "recalculate all" with each update?
A workaround might be to convert all of the RCHGetYahooHistory() functions
into values, so that they don't recalculate. The underlying data isn't
going to change during the day anyway.
On Fri, Mar 14, 2014 at 7:58 AM, <rajarjrtj@yahoo.com> wrote:
>
> Haven't had this problem before over 4 years of usage.
>
> I have your excellent! SMF addin running on a workbook that is connected
> to IB API. For some reason, today the {RCHGetYahooHistory
> update/re-compute every 2000ms that the IB API updates, which is not
> typical, and which has increased the workbook computation time from ~ 1
> second, to 90+ seconds. Unfortunately, it is now unusable for interday ALGO
> use.
>
> Any help would be greatly appreciated. Thanks
>
Fri Mar 14, 2014 9:04 am (PDT) . Posted by:
rajarjrtj
Thanks for the response.
No, I haven't placed anything in the formulae to make volatile. Also, I haven't updated the API for at least a month. Everything that I control in the workbook is unchanged from yesterday when the array tables would update only when opening the workbook or forcing recalculation.
It is very strange to me that the issue started today, without any known changes. To no avail, I even did a system restore to 2 days ago, and tried a previous version of the workbook from last week that was known to function properly.
Do you think that a user modification in the addin code could prevent the recalculation?
No, I haven't placed anything in the formulae to make volatile. Also, I haven't updated the API for at least a month. Everything that I control in the workbook is unchanged from yesterday when the array tables would update only when opening the workbook or forcing recalculation.
It is very strange to me that the issue started today, without any known changes. To no avail, I even did a system restore to 2 days ago, and tried a previous version of the workbook from last week that was known to function properly.
Do you think that a user modification in the addin code could prevent the recalculation?
Fri Mar 14, 2014 5:18 pm (PDT) . Posted by:
"Randy Harmelink" rharmelink
I'm not sure how. That's why I suggested converting them to values.
On Fri, Mar 14, 2014 at 9:04 AM, <rajarjrtj@yahoo.com> wrote:
> Do you think that a user modification in the addin code could prevent the
> recalculation?
>
On Fri, Mar 14, 2014 at 9:04 AM, <rajarjrtj@yahoo.com> wrote:
> Do you think that a user modification in the addin code could prevent the
> recalculation?
>
Fri Mar 14, 2014 11:56 pm (PDT) . Posted by:
lawleesh
Hi Randy
Could you pls help me with the formula to get Div yield from this page?
http://www.marketwatch.com/investing/Stock/C6L?countrycode=SG http://www.marketwatch.com/investing/Stock/C6L?countrycode=SG
thanks
LL
Could you pls help me with the formula to get Div yield from this page?
http://www.marketwatch.com/investing/Stock/C6L?countrycode=SG http://www.marketwatch.com/investing/Stock/C6L?countrycode=SG
thanks
LL
Sat Mar 15, 2014 12:04 am (PDT) . Posted by:
"Randy Harmelink" rharmelink
Hmmm. They don't use a table to display the data. This appears to work:
=smfConvertData(smfGetTagContent("
http://www.marketwatch.com/investing/Stock/C6L?countrycode=SG",
"p",1,"Div Yield"))
On Fri, Mar 14, 2014 at 11:56 PM, <lawrence.leesh@gmail.com> wrote:
>
> Could you pls help me with the formula to get Div yield from this page?
>
> http://www.marketwatch.com/investing/Stock/C6L?countrycode=SG
>
>
=smfConvertData(smfGetTagContent("
http://www.marketwatch.com/investing/Stock/C6L?countrycode=SG",
"p",1,"Div Yield"))
On Fri, Mar 14, 2014 at 11:56 PM, <lawrence.leesh@gmail.com> wrote:
>
> Could you pls help me with the formula to get Div yield from this page?
>
> http://www.marketwatch.com/investing/Stock/C6L?countrycode=SG
>
>
Tidak ada komentar:
Posting Komentar