OK - one last tidbit of info. IT now seems its due to a Patch/Update. All these users experiencing the problems - they have been using Excel 2013 for a WHILE! So - it seems problem is not intrinsic to Excel 2013 itself - but, rather - a recent patch/update that broke something!
Anyway - I'm outta here. TGIF!!! Regards, Kurt Wendt Senior Systems Analyst Tel. +1-212-747-9100 www.GlobeTax.com -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Kurt Wendt Sent: Friday, March 17, 2017 2:54 PM To: [email protected] Subject: RE: New Excel BREAKS Prior Working Automation! Gene - thanks again for your feedback - and your humor. So - I am trying to press onwards with this problem today. The Kludge I mentioned before - was to literally read EACH Cell from the Source spreadsheet - then push that value into the proper cell of the Target spreadsheet. And, here's where it gets REALY Strange. If I run this operation on MY regular work PC - it works fine. I even stepped thru the code - to check the value of the " Val_2_Copy" var. - and it has a proper value. However, on the machine that I Remote into - which has Excel 2013 instead of 2010 (which mine has) - the value of the " Val_2_Copy" var. actually contains NULL! WTF?!?! That's Nuts - doesn't make Sense - all due to the Excel version. Anyway - here is the specific code/kludge which I am attempting to use to copy of the data of the Cells: FOR Col_No = 0 TO 3 && Columns A thru D Column_Code = CHR(65 + Col_No) FOR Row_Cntr = 1 TO rowcount && This is the Dest File Rows Source_Row = Row_Cntr + 6 Source_range = '"'+Column_Code + ALLTRIM(STR(Source_Row))+'"' Dest_range = '"'+Column_Code + ALLTRIM(STR(Row_Cntr))+'"' oWorkBook.Activate Val_2_Copy = oExcel.ActiveSheet.RANGE(&Source_range).VALUE oWorkBook2.Activate oExcel.ActiveSheet.RANGE(&Dest_range).VALUE = Val_2_Copy ENDFOR ENDFOR Any input would be GREATLY Appreciated - since, at this point - I seem to be Banging my head against a Wall! I did have ONE thought. Could there possibly be a new setting in Excel that STOPS direct access of data via Automation??? I know - it's a Shot-in-the-Dark... Regards, Kurt Wendt Senior Systems Analyst Tel. +1-212-747-9100 www.GlobeTax.com -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Gene Wirchenko Sent: Friday, March 17, 2017 2:41 PM To: [email protected] Subject: Re: New Excel BREAKS Prior Working Automation! At 18:53 2017-03-15, Kurt at VR-FX <[email protected]> wrote: >Hey there Gene! > >Guess great minds thing alike! Yup - been there - done that! Did the >Wait command - but, alas - to no avail... So do similarly deluded fools, but as that use case has nothing, nothing to do with us, I will press on. >Am working alternate kludge - but, today & tomorrow am in a 3D PRinting >conference - so back to this problem on Fri... You stated that the code worked on a computer that it did not work on normally. Something about running the debugger did it. It is possible that I/O had something to do with it. Maybe, it has to be explicit. Some forms of the wait command will not wait, such as: wait "Hello!" window nowait What you are looking for is a condition that will break the problem. *Then*, you refine it. I may be telling you what you already know, but do so in case you have overlooked something. [snip] Sincerely, Gene Wirchenko [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/80838f1ca795b14ea1af48659f35166f18fdb...@drexch02.corp.globetax.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
