Hi Erich, Thanks for the quick reply. I will forward this on to the users who are affected by the problem.
However, can you advise me what is the best way to permanently change the RExcel.xla add-in. They seem to have problems saving the changes. Regards Wayne -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Erich Neuwirth Sent: 16 November 2007 09:53 To: R (D)COM and RExcel server related issues Subject: Re: [Rcom-l] Workaround Time Zone bug RExcel Could you please git into Class Module CTime and change Property Get TimeZoneOffset() As Integer to Property Get TimeZoneOffset() As Long and check if that also solves the problem,. Then I would commit that change. > > Hi Everyone, > > I am being faced with the same bug as as a previous post on the rcom > mailing list: see > http://mailman.csd.univie.ac.at/pipermail/rcom-l/2006-November/001332.html . > > Namely, an RExcel application I have deployed is having trouble coping > with different time zones. We here at Shell are using an older version > of R(D)Com from the bundle RDACCSDSetup2031V1.62.exe on the Rcom > website. Unfortunately, due to circumstances beyond my control I cannot > quickly distribute a new version of R(D)Com to the users were the bug > may be fixed. Neither can I reset the computer clocks as was the quick > fix used by Andrew as specified in his mail post. > > One of the users has found a quick fix, namely, change the RExcel.xla > code when he opens the application in the getarray procedure from > > ' If AllIsDates Then > TimeOffset = Str(GMTOffset() * 3600) > > to the following: > > ' If AllIsDates Then > TimeOffset = Str(GMTOffset() * clng(3600)) > > the clng VBA function converts a value to a long int. At present the > users have to do this fix everytime they restart the application. > > Is it possible to change the code in the RExcel.xla file to this new fix > permanently? If so, is it just a case of opening up RExcel.xla from > C:\Program Files\R\(D)COM Server\xls changing the code and saving it off? > > Normally, I would not advocate this at all! But due to the > circumstances...... > > Or does anyone else have any suggestions for another fix? > > Regards > > Wayne > > > > > > > ---------------------------------------------------------------------------------------- > > Wayne Jones > Statistical Consultant > Shell Global Solutions (UK) > Shell Technology Centre Thornton, P.O. Box 1, Chester CH1 3SH, United > Kingdom > > *Tel:* +44 (0) 151 373 5977* * > *Fax:* +44 (0) 151 373 5384* * > *Mobile:* +44 (0) 7896 536026 > *Email:* [EMAIL PROTECTED] > *Internet:*** www.shell.com/globalsolutions/statisticsandchemometrics > > /Shell Global Solutions (UK) is a division of Shell Research Limited > which has its Registered Office at Shell Centre, London SE1 7NA and is > registered in England & Wales with No.539964./ > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rcom-l mailing list > Rcom-l@mailman.csd.univie.ac.at > http://mailman.csd.univie.ac.at/mailman/listinfo/rcom-l > More information (including a Wiki) at http://rcom.univie.ac.at -- Erich Neuwirth, University of Vienna Faculty of Computer Science Computer Supported Didactics Working Group Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39464 Fax: +43-1-4277-39459 _______________________________________________ Rcom-l mailing list Rcom-l@mailman.csd.univie.ac.at http://mailman.csd.univie.ac.at/mailman/listinfo/rcom-l More information (including a Wiki) at http://rcom.univie.ac.at _______________________________________________ Rcom-l mailing list Rcom-l@mailman.csd.univie.ac.at http://mailman.csd.univie.ac.at/mailman/listinfo/rcom-l More information (including a Wiki) at http://rcom.univie.ac.at
