Index
2017-03-14 14:23Kurt Wendt : New Excel BREAKS Prior Working Automation!
2017-03-14 14:27Richard Kaye : RE: New Excel BREAKS Prior Working Automation!
2017-03-14 14:40Kurt Wendt : RE: New Excel BREAKS Prior Working Automation!
2017-03-14 17:56Charlie : Re: New Excel BREAKS Prior Working Automation!
2017-03-14 20:44Kurt at VR-FX : Re: New Excel BREAKS Prior Working Automation!
2017-03-15 10:28Alan Bourke : Re: New Excel BREAKS Prior Working Automation!
2017-03-15 20:29Gene Wirchenko : Re: New Excel BREAKS Prior Working Automation!
2017-03-15 20:53Kurt at VR-FX : Re: New Excel BREAKS Prior Working Automation!
2017-03-17 13:41Gene Wirchenko : Re: New Excel BREAKS Prior Working Automation!
2017-03-17 13:53Kurt Wendt : RE: New Excel BREAKS Prior Working Automation!
Back to top
New Excel BREAKS Prior Working Automation!

Author: Kurt Wendt

Posted: 2017-03-14 14:23:18   Link

Good afternoon fellow ProFoxers!

I hope you are faring well - for those of you like me in the NE USA hit by the storm. They sent out emergency communications yesterday from my job - saying office would be closed today - yet, instead of FEET of Snow - I woke up and all the Rain/sleet seems to have melted it down to like 3 or 4 inches tall at best! Well - alas - I digress.

So - here's the deal. Recently I had a User get a problem with a particular option in an application - something that had always worked. Stranger still - as the old saying goes "It works on MY Machine" is also occurring - since the problem would NOT occur on my machine. Even went a step farther, as he had the gal sitting next to him try the same option - and it failed for her. I then went farther. I logged into another machine, and it worked. Went to a QA gal - she tried it - and it work. In the end - a buddy of mine in Systems who deals with networking and user support - he had like 7 different users try it - and it failed for all of them. In the end - his deduction was problem being tied to Excel - as I am running 2010 - and the systems experiencing the problem are 2013.

Short explanation of the actual problem. This app - reads in an Excel file using Automation. Grabs the data in the header area of spreadsheet and fills in var's. Then it takes the main data - a bunch of rows/columns - and pushes the data into a CSV file that it creates via Automation. The 2nd phase shows a screen w/Header info - and displays name of the CSV file. Then asks if you want to Proceed with processing the data. Here in lies the problem. In my case - when I run the option - the CSV file is fine. But, for the users that are having the problem - the CSV file is EMPTY!

Now - before reporting this problem to you all here - I've been doing a bunch of research - as well as Testing various options. I even looked at a prior thread here in this forum - as it was VERY Similar to my own conundrum: "Copy Excel worksheet to another workbook". And, one of the tricks I noticed that was mentioned is that after Copying the range of Cells from the FROM Excel file - and before Pasting into the TO Workbook (that will become the CSV file) - that it was suggested to CLOSE the From Workbook. So - I did that - but, then I get the following error message being thrown: "The object invoked has disconnected from its clients."

I even tried a similar operation by hand (as I have remote access to another PC in my office that has Excel 2013 - so I can test for the problem) - by doing the Copy of the Cells, Closed the workbook - then went to the Other workbook and did Paste - and it worked - NO Error and data was pasted!

As such - I'm rather stumped! It's really SUCH a Drag when changes to Office now crash out Code that previously worked.

A fellow developer has suggested another Kludge - as Gene so adeptly states the term - which is to do a more manual pasting of cell data one by one - literally assigning the values to the Cells instead of by doing the Paste command. I did do a test by simply assigning "Hello World" to a single cell - and that DID work. But, I'd rather a more Elegant solution AND something that knows what the Actual problem is and can fix it with less code. Especially since I worry that this problem may run DEEPER than the users think - and that a BUNCH of other similar options in this application may ALSO Start to fail for all these users!

TIA!

Regards.

Kurt Wendt

Senior Systems Analyst

One New York Plaza - 34th Floor

New York, NY 10004-1936, USA

Tel. +1-212-747-9100

Direct +1-212-405-8246

www.GlobeTax.com

GlobeTax does not provide or offer, and this is not, tax, investment or legal advice. This email and any attachments hereto is intended only for use by the addressee(s) and may contain confidential information. If you are not the intended recipient of this email, please immediately notify the sender at +1-212-747-9100 and permanently delete the original and any copies of this email.

_______________________________________________

Post Messages to: ProFox@leafe.com

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/80838F1CA795B14EA1AF48659F35166F18FDB4DC@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.

©2017 Kurt Wendt
Back to top
RE: New Excel BREAKS Prior Working Automation!

Author: Richard Kaye

Posted: 2017-03-14 14:27:04   Link

Despite the tip, did you try not closing the source workbook before you pasted?

--

rk

-----Original Message-----

From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Kurt Wendt

Sent: Tuesday, March 14, 2017 3:23 PM

To: profoxtech@leafe.com

Subject: New Excel BREAKS Prior Working Automation!

Good afternoon fellow ProFoxers!

I hope you are faring well - for those of you like me in the NE USA hit by the storm. They sent out emergency communications yesterday from my job - saying office would be closed today - yet, instead of FEET of Snow - I woke up and all the Rain/sleet seems to have melted it down to like 3 or 4 inches tall at best! Well - alas - I digress.

So - here's the deal. Recently I had a User get a problem with a particular option in an application - something that had always worked. Stranger still - as the old saying goes "It works on MY Machine" is also occurring - since the problem would NOT occur on my machine. Even went a step farther, as he had the gal sitting next to him try the same option - and it failed for her. I then went farther. I logged into another machine, and it worked. Went to a QA gal - she tried it - and it work. In the end - a buddy of mine in Systems who deals with networking and user support - he had like 7 different users try it - and it failed for all of them. In the end - his deduction was problem being tied to Excel - as I am running 2010 - and the systems experiencing the problem are 2013.

Short explanation of the actual problem. This app - reads in an Excel file using Automation. Grabs the data in the header area of spreadsheet and fills in var's. Then it takes the main data - a bunch of rows/columns - and pushes the data into a CSV file that it creates via Automation. The 2nd phase shows a screen w/Header info - and displays name of the CSV file. Then asks if you want to Proceed with processing the data. Here in lies the problem. In my case - when I run the option - the CSV file is fine. But, for the users that are having the problem - the CSV file is EMPTY!

Now - before reporting this problem to you all here - I've been doing a bunch of research - as well as Testing various options. I even looked at a prior thread here in this forum - as it was VERY Similar to my own conundrum: "Copy Excel worksheet to another workbook". And, one of the tricks I noticed that was mentioned is that after Copying the range of Cells from the FROM Excel file - and before Pasting into the TO Workbook (that will become the CSV file) - that it was suggested to CLOSE the From Workbook. So - I did that - but, then I get the following error message being thrown: "The object invoked has disconnected from its clients."

I even tried a similar operation by hand (as I have remote access to another PC in my office that has Excel 2013 - so I can test for the problem) - by doing the Copy of the Cells, Closed the workbook - then went to the Other workbook and did Paste - and it worked - NO Error and data was pasted!

As such - I'm rather stumped! It's really SUCH a Drag when changes to Office now crash out Code that previously worked.

A fellow developer has suggested another Kludge - as Gene so adeptly states the term - which is to do a more manual pasting of cell data one by one - literally assigning the values to the Cells instead of by doing the Paste command. I did do a test by simply assigning "Hello World" to a single cell - and that DID work. But, I'd rather a more Elegant solution AND something that knows what the Actual problem is and can fix it with less code. Especially since I worry that this problem may run DEEPER than the users think - and that a BUNCH of other similar options in this application may ALSO Start to fail for all these users!

TIA!

Regards.

Kurt Wendt

Senior Systems Analyst

_______________________________________________

Post Messages to: ProFox@leafe.com

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/BN4PR10MB0913FA53050E065F6FEC0BE8D2240@BN4PR10MB0913.namprd10.prod.outlook.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.

©2017 Richard Kaye
Back to top
RE: New Excel BREAKS Prior Working Automation!

Author: Kurt Wendt

Posted: 2017-03-14 14:40:39   Link

RK - of course! That's what the original code essentially does!

So - here is a cut down version of the original code (yeah - I really should have posted this initially, was going to do so - but I forgot to include it!):

oWorkBook.Activate

rangeA = '"A7:D'+ALLTRIM(STR(lastrow))+'"'

oRange = oExcel.ActiveSheet.RANGE(&rangeA)

oRange.SELECT

oRange.COPY()

oWorkBook2.Activate

oExcel.ActiveSheet.Paste

jdate=ALLTRIM(STR(ROUND(julian(DTOC(DATE())),0)))

mCSVname = csvpath+'BO'+jdate

mCSVname = FORCEEXT(mCSVname,"csv")

oExcel.ActiveWorkBook.SAVEAS (mCSVname,xlCSV)

oExcel.ActiveWorkBook.CLOSE(.F.) && the .F. parameter will prevent the dialogue box

Regards,

Kurt Wendt

Senior Systems Analyst

Tel. +1-212-747-9100

www.GlobeTax.com

-----Original Message-----

From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Richard Kaye

Sent: Tuesday, March 14, 2017 3:27 PM

To: profoxtech@leafe.com

Subject: RE: New Excel BREAKS Prior Working Automation!

Despite the tip, did you try not closing the source workbook before you pasted?

--

rk

-----Original Message-----

From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Kurt Wendt

Sent: Tuesday, March 14, 2017 3:23 PM

To: profoxtech@leafe.com

Subject: New Excel BREAKS Prior Working Automation!

Good afternoon fellow ProFoxers!

I hope you are faring well - for those of you like me in the NE USA hit by the storm. They sent out emergency communications yesterday from my job - saying office would be closed today - yet, instead of FEET of Snow - I woke up and all the Rain/sleet seems to have melted it down to like 3 or 4 inches tall at best! Well - alas - I digress.

So - here's the deal. Recently I had a User get a problem with a particular option in an application - something that had always worked. Stranger still - as the old saying goes "It works on MY Machine" is also occurring - since the problem would NOT occur on my machine. Even went a step farther, as he had the gal sitting next to him try the same option - and it failed for her. I then went farther. I logged into another machine, and it worked. Went to a QA gal - she tried it - and it work. In the end - a buddy of mine in Systems who deals with networking and user support - he had like 7 different users try it - and it failed for all of them. In the end - his deduction was problem being tied to Excel - as I am running 2010 - and the systems experiencing the problem are 2013.

Short explanation of the actual problem. This app - reads in an Excel file using Automation. Grabs the data in the header area of spreadsheet and fills in var's. Then it takes the main data - a bunch of rows/columns - and pushes the data into a CSV file that it creates via Automation. The 2nd phase shows a screen w/Header info - and displays name of the CSV file. Then asks if you want to Proceed with processing the data. Here in lies the problem. In my case - when I run the option - the CSV file is fine. But, for the users that are having the problem - the CSV file is EMPTY!

Now - before reporting this problem to you all here - I've been doing a bunch of research - as well as Testing various options. I even looked at a prior thread here in this forum - as it was VERY Similar to my own conundrum: "Copy Excel worksheet to another workbook". And, one of the tricks I noticed that was mentioned is that after Copying the range of Cells from the FROM Excel file - and before Pasting into the TO Workbook (that will become the CSV file) - that it was suggested to CLOSE the From Workbook. So - I did that - but, then I get the following error message being thrown: "The object invoked has disconnected from its clients."

I even tried a similar operation by hand (as I have remote access to another PC in my office that has Excel 2013 - so I can test for the problem) - by doing the Copy of the Cells, Closed the workbook - then went to the Other workbook and did Paste - and it worked - NO Error and data was pasted!

As such - I'm rather stumped! It's really SUCH a Drag when changes to Office now crash out Code that previously worked.

A fellow developer has suggested another Kludge - as Gene so adeptly states the term - which is to do a more manual pasting of cell data one by one - literally assigning the values to the Cells instead of by doing the Paste command. I did do a test by simply assigning "Hello World" to a single cell - and that DID work. But, I'd rather a more Elegant solution AND something that knows what the Actual problem is and can fix it with less code. Especially since I worry that this problem may run DEEPER than the users think - and that a BUNCH of other similar options in this application may ALSO Start to fail for all these users!

TIA!

Regards.

Kurt Wendt

Senior Systems Analyst

[excessive quoting removed by server]

_______________________________________________

Post Messages to: ProFox@leafe.com

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/80838F1CA795B14EA1AF48659F35166F18FDB531@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.

©2017 Kurt Wendt
Back to top
Re: New Excel BREAKS Prior Working Automation!

Author: Charlie

Posted: 2017-03-14 17:56:08   Link

I suggest you put an oExcel.DisplayAlerts = .F. right after you

instantiate the oExcel object (if you don't have it already).

Also, as a testing idea, you could do an oExcel.Visible right after the

.Paste (and comment out the rest of the code) to see if that step

worked. Of course that means you kinda need to be on a machine where it

is failing.

Good ol' MS "Where do you want your problem today?"

-Charlie

On 3/14/2017 3:40 PM, Kurt Wendt wrote:

> RK - of course! That's what the original code essentially does!

>

> So - here is a cut down version of the original code (yeah - I really should have posted this initially, was going to do so - but I forgot to include it!):

> oWorkBook.Activate

> rangeA = '"A7:D'+ALLTRIM(STR(lastrow))+'"'

> oRange = oExcel.ActiveSheet.RANGE(&rangeA)

> oRange.SELECT

> oRange.COPY()

>

> oWorkBook2.Activate

> oExcel.ActiveSheet.Paste

>

> jdate=ALLTRIM(STR(ROUND(julian(DTOC(DATE())),0)))

> mCSVname = csvpath+'BO'+jdate

> mCSVname = FORCEEXT(mCSVname,"csv")

>

> oExcel.ActiveWorkBook.SAVEAS (mCSVname,xlCSV)

> oExcel.ActiveWorkBook.CLOSE(.F.) && the .F. parameter will prevent the dialogue box

>

>

> Regards,

> Kurt Wendt

> Senior Systems Analyst

>

>

> Tel. +1-212-747-9100

> www.GlobeTax.com

>

>

> -----Original Message-----

> From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Richard Kaye

> Sent: Tuesday, March 14, 2017 3:27 PM

> To: profoxtech@leafe.com

> Subject: RE: New Excel BREAKS Prior Working Automation!

>

> Despite the tip, did you try not closing the source workbook before you pasted?

>

> --

>

> rk

> -----Original Message-----

> From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Kurt Wendt

> Sent: Tuesday, March 14, 2017 3:23 PM

> To: profoxtech@leafe.com

> Subject: New Excel BREAKS Prior Working Automation!

>

> Good afternoon fellow ProFoxers!

>

> I hope you are faring well - for those of you like me in the NE USA hit by the storm. They sent out emergency communications yesterday from my job - saying office would be closed today - yet, instead of FEET of Snow - I woke up and all the Rain/sleet seems to have melted it down to like 3 or 4 inches tall at best! Well - alas - I digress.

>

> So - here's the deal. Recently I had a User get a problem with a particular option in an application - something that had always worked. Stranger still - as the old saying goes "It works on MY Machine" is also occurring - since the problem would NOT occur on my machine. Even went a step farther, as he had the gal sitting next to him try the same option - and it failed for her. I then went farther. I logged into another machine, and it worked. Went to a QA gal - she tried it - and it work. In the end - a buddy of mine in Systems who deals with networking and user support - he had like 7 different users try it - and it failed for all of them. In the end - his deduction was problem being tied to Excel - as I am running 2010 - and the systems experiencing the problem are 2013.

>

> Short explanation of the actual problem. This app - reads in an Excel file using Automation. Grabs the data in the header area of spreadsheet and fills in var's. Then it takes the main data - a bunch of rows/columns - and pushes the data into a CSV file that it creates via Automation. The 2nd phase shows a screen w/Header info - and displays name of the CSV file. Then asks if you want to Proceed with processing the data. Here in lies the problem. In my case - when I run the option - the CSV file is fine. But, for the users that are having the problem - the CSV file is EMPTY!

>

> Now - before reporting this problem to you all here - I've been doing a bunch of research - as well as Testing various options. I even looked at a prior thread here in this forum - as it was VERY Similar to my own conundrum: "Copy Excel worksheet to another workbook". And, one of the tricks I noticed that was mentioned is that after Copying the range of Cells from the FROM Excel file - and before Pasting into the TO Workbook (that will become the CSV file) - that it was suggested to CLOSE the From Workbook. So - I did that - but, then I get the following error message being thrown: "The object invoked has disconnected from its clients."

>

> I even tried a similar operation by hand (as I have remote access to another PC in my office that has Excel 2013 - so I can test for the problem) - by doing the Copy of the Cells, Closed the workbook - then went to the Other workbook and did Paste - and it worked - NO Error and data was pasted!

>

> As such - I'm rather stumped! It's really SUCH a Drag when changes to Office now crash out Code that previously worked.

>

> A fellow developer has suggested another Kludge - as Gene so adeptly states the term - which is to do a more manual pasting of cell data one by one - literally assigning the values to the Cells instead of by doing the Paste command. I did do a test by simply assigning "Hello World" to a single cell - and that DID work. But, I'd rather a more Elegant solution AND something that knows what the Actual problem is and can fix it with less code. Especially since I worry that this problem may run DEEPER than the users think - and that a BUNCH of other similar options in this application may ALSO Start to fail for all these users!

>

> TIA!

>

> Regards.

> Kurt Wendt

> Senior Systems Analyst

>

>

[excessive quoting removed by server]

_______________________________________________

Post Messages to: ProFox@leafe.com

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/d30cac05-4260-6d6a-80e4-bb53dd8d9030@verizon.net

** 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.

©2017 Charlie
Back to top
Re: New Excel BREAKS Prior Working Automation!

Author: Kurt at VR-FX

Posted: 2017-03-14 20:44:29   Link

OK - since you DID ask. FYI - I actually Step thru the code - and when I

do - everything works fine! That's why its an even stranger conundrum!!!

Also - as previously mentioned - I actually Was testing on a machine

that has the problem. And, even on there - when stepping thru the code -

the problem then does NOT occur...

:-(

-K-

P.S. I will be essentially offline for next 2 days - am attending a 3D

Printing conference in NYC and not going to work. Assuming its not

postponed ANOTHER day due to the stupid weather!

On 3/14/2017 6:56 PM, Charlie wrote:

>

> I suggest you put an oExcel.DisplayAlerts = .F. right after you

> instantiate the oExcel object (if you don't have it already).

>

> Also, as a testing idea, you could do an oExcel.Visible right after

> the .Paste (and comment out the rest of the code) to see if that step

> worked. Of course that means you kinda need to be on a machine where

> it is failing.

>

> Good ol' MS "Where do you want your problem today?"

>

> -Charlie

>

>

> On 3/14/2017 3:40 PM, Kurt Wendt wrote:

>> RK - of course! That's what the original code essentially does!

>>

>> So - here is a cut down version of the original code (yeah - I really

>> should have posted this initially, was going to do so - but I forgot

>> to include it!):

>> oWorkBook.Activate

>> rangeA = '"A7:D'+ALLTRIM(STR(lastrow))+'"'

>> oRange = oExcel.ActiveSheet.RANGE(&rangeA)

>> oRange.SELECT

>> oRange.COPY()

>>

>> oWorkBook2.Activate

>> oExcel.ActiveSheet.Paste

>>

>> jdate=ALLTRIM(STR(ROUND(julian(DTOC(DATE())),0)))

>> mCSVname = csvpath+'BO'+jdate

>> mCSVname = FORCEEXT(mCSVname,"csv")

>>

>> oExcel.ActiveWorkBook.SAVEAS (mCSVname,xlCSV)

>> oExcel.ActiveWorkBook.CLOSE(.F.) && the .F. parameter will

>> prevent the dialogue box

>>

>>

>> Regards,

>> Kurt Wendt

>> Senior Systems Analyst

>>

>>

>> Tel. +1-212-747-9100

>> www.GlobeTax.com

>>

>>

>> -----Original Message-----

>> From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of

>> Richard Kaye

>> Sent: Tuesday, March 14, 2017 3:27 PM

>> To: profoxtech@leafe.com

>> Subject: RE: New Excel BREAKS Prior Working Automation!

>>

>> Despite the tip, did you try not closing the source workbook before

>> you pasted?

>>

>> --

>>

>> rk

>> -----Original Message-----

>> From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of

>> Kurt Wendt

>> Sent: Tuesday, March 14, 2017 3:23 PM

>> To: profoxtech@leafe.com

>> Subject: New Excel BREAKS Prior Working Automation!

>>

>> Good afternoon fellow ProFoxers!

>>

>> I hope you are faring well - for those of you like me in the NE USA

>> hit by the storm. They sent out emergency communications yesterday

>> from my job - saying office would be closed today - yet, instead of

>> FEET of Snow - I woke up and all the Rain/sleet seems to have melted

>> it down to like 3 or 4 inches tall at best! Well - alas - I digress.

>>

>> So - here's the deal. Recently I had a User get a problem with a

>> particular option in an application - something that had always

>> worked. Stranger still - as the old saying goes "It works on MY

>> Machine" is also occurring - since the problem would NOT occur on my

>> machine. Even went a step farther, as he had the gal sitting next to

>> him try the same option - and it failed for her. I then went farther.

>> I logged into another machine, and it worked. Went to a QA gal - she

>> tried it - and it work. In the end - a buddy of mine in Systems who

>> deals with networking and user support - he had like 7 different

>> users try it - and it failed for all of them. In the end - his

>> deduction was problem being tied to Excel - as I am running 2010 -

>> and the systems experiencing the problem are 2013.

>>

>> Short explanation of the actual problem. This app - reads in an Excel

>> file using Automation. Grabs the data in the header area of

>> spreadsheet and fills in var's. Then it takes the main data - a bunch

>> of rows/columns - and pushes the data into a CSV file that it creates

>> via Automation. The 2nd phase shows a screen w/Header info - and

>> displays name of the CSV file. Then asks if you want to Proceed with

>> processing the data. Here in lies the problem. In my case - when I

>> run the option - the CSV file is fine. But, for the users that are

>> having the problem - the CSV file is EMPTY!

>>

>> Now - before reporting this problem to you all here - I've been doing

>> a bunch of research - as well as Testing various options. I even

>> looked at a prior thread here in this forum - as it was VERY Similar

>> to my own conundrum: "Copy Excel worksheet to another workbook".

>> And, one of the tricks I noticed that was mentioned is that after

>> Copying the range of Cells from the FROM Excel file - and before

>> Pasting into the TO Workbook (that will become the CSV file) - that

>> it was suggested to CLOSE the From Workbook. So - I did that - but,

>> then I get the following error message being thrown: "The object

>> invoked has disconnected from its clients."

>>

>> I even tried a similar operation by hand (as I have remote access to

>> another PC in my office that has Excel 2013 - so I can test for the

>> problem) - by doing the Copy of the Cells, Closed the workbook - then

>> went to the Other workbook and did Paste - and it worked - NO Error

>> and data was pasted!

>>

>> As such - I'm rather stumped! It's really SUCH a Drag when changes to

>> Office now crash out Code that previously worked.

>>

>> A fellow developer has suggested another Kludge - as Gene so adeptly

>> states the term - which is to do a more manual pasting of cell data

>> one by one - literally assigning the values to the Cells instead of

>> by doing the Paste command. I did do a test by simply assigning

>> "Hello World" to a single cell - and that DID work. But, I'd rather a

>> more Elegant solution AND something that knows what the Actual

>> problem is and can fix it with less code. Especially since I worry

>> that this problem may run DEEPER than the users think - and that a

>> BUNCH of other similar options in this application may ALSO Start to

>> fail for all these users!

>>

>> TIA!

>>

>> Regards.

>> Kurt Wendt

>> Senior Systems Analyst

>>

>>

[excessive quoting removed by server]

_______________________________________________

Post Messages to: ProFox@leafe.com

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/cc2f6a04-26ea-80f6-f516-b301b9df238a@optonline.net

** 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.

©2017 Kurt at VR-FX
Back to top
Re: New Excel BREAKS Prior Working Automation!

Author: Alan Bourke

Posted: 2017-03-15 10:28:42   Link

Maybe try making sure you have disposed of your Excel object before

attempting to open the CSV.

Or maybe sleep the VFP thread for a couple of seconds to give things a

chance to flush.

declare integer sleep in "kernel32" long dwmilliseconds

sleep(2000)

I assume you have Excel hidden during this. Maybe introduce a flag that

will make it visible during this process when run onsite so you can see

if it is calving at a particular point for the users.

--

Alan Bourke

alanpbourke (at) fastmail (dot) fm

_______________________________________________

Post Messages to: ProFox@leafe.com

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/1489591722.2819230.912258648.5862D0D3@webmail.messagingengine.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.

©2017 Alan Bourke
Back to top
Re: New Excel BREAKS Prior Working Automation!

Author: Gene Wirchenko

Posted: 2017-03-15 20:29:39   Link

At 18:44 2017-03-14, Kurt at VR-FX <vrfx@optonline.net> wrote:

>OK - since you DID ask. FYI - I actually Step thru the code - and

>when I do - everything works fine! That's why its an even stranger conundrum!!!

>

>Also - as previously mentioned - I actually Was testing on a machine

>that has the problem. And, even on there - when stepping thru the

>code - the problem then does NOT occur...

>

>:-(

This has the smell of a race condition. You might not be able

to get at the actual cause. You may have to -- shudder --

kludge. If someone comes up with a non-kludge, use that in preference to this.

On a misbehaving system, try adding a sleep(10000) between each

statement. Does the problem still occur?

If so, come up with something else to stick in a delay that

gets rid of the problem. If it is response-related, try a

keyboard-messagebox() sequence.

If not or after finding an alternative delay method, start

removing the delays until you find where the problem triggers. Keep

that one. You might shave the time down some, too. (I selected 10

seconds as overkill*.)

After getting it to the minimal number of delays, try removing

them all. This might work. Why? Who knows?

* Gene's Law of Overkill: First, you have to kill. Only then can you

overdo it.

[snip]

Sincerely,

Gene Wirchenko

_______________________________________________

Post Messages to: ProFox@leafe.com

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/376e34ca9cfd68e87e35b52bc5f234aa@mtlp000083

** 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.

©2017 Gene Wirchenko
Back to top
Re: New Excel BREAKS Prior Working Automation!

Author: Kurt at VR-FX

Posted: 2017-03-15 20:53:18   Link

Hey there Gene!

Guess great minds thing alike! Yup - been there - done that! Did the

Wait command - but, alas - to no avail...

Am working alternate kludge - but, today & tomorrow am in a 3D PRinting

conference - so back to this problem on Fri...

-K-

On 3/15/2017 9:29 PM, Gene Wirchenko wrote:

> At 18:44 2017-03-14, Kurt at VR-FX <vrfx@optonline.net> wrote:

>> OK - since you DID ask. FYI - I actually Step thru the code - and

>> when I do - everything works fine! That's why its an even stranger

>> conundrum!!!

>>

>> Also - as previously mentioned - I actually Was testing on a machine

>> that has the problem. And, even on there - when stepping thru the

>> code - the problem then does NOT occur...

>>

>> :-(

>

> This has the smell of a race condition. You might not be able to

> get at the actual cause. You may have to -- shudder -- kludge. If

> someone comes up with a non-kludge, use that in preference to this.

>

> On a misbehaving system, try adding a sleep(10000) between each

> statement. Does the problem still occur?

>

> If so, come up with something else to stick in a delay that gets

> rid of the problem. If it is response-related, try a

> keyboard-messagebox() sequence.

>

> If not or after finding an alternative delay method, start

> removing the delays until you find where the problem triggers. Keep

> that one. You might shave the time down some, too. (I selected 10

> seconds as overkill*.)

>

> After getting it to the minimal number of delays, try removing

> them all. This might work. Why? Who knows?

>

> * Gene's Law of Overkill: First, you have to kill. Only then can you

> overdo it.

>

> [snip]

>

> Sincerely,

>

> Gene Wirchenko

>

>

[excessive quoting removed by server]

_______________________________________________

Post Messages to: ProFox@leafe.com

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/77f4f6e5-db95-1949-d063-63f051a759bb@optonline.net

** 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.

©2017 Kurt at VR-FX
Back to top
Re: New Excel BREAKS Prior Working Automation!

Author: Gene Wirchenko

Posted: 2017-03-17 13:41:12   Link

At 18:53 2017-03-15, Kurt at VR-FX <vrfx@optonline.net> 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

_______________________________________________

Post Messages to: ProFox@leafe.com

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/394089965b9bdf0d4d39aaf5acf4cb0a@mtlp000083

** 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.

©2017 Gene Wirchenko
Back to top
RE: New Excel BREAKS Prior Working Automation!

Author: Kurt Wendt

Posted: 2017-03-17 13:53:32   Link

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:profoxtech-bounces@leafe.com] On Behalf Of Gene Wirchenko

Sent: Friday, March 17, 2017 2:41 PM

To: profoxtech@leafe.com

Subject: Re: New Excel BREAKS Prior Working Automation!

At 18:53 2017-03-15, Kurt at VR-FX <vrfx@optonline.net> 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: ProFox@leafe.com

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/80838F1CA795B14EA1AF48659F35166F18FDBC92@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.

©2017 Kurt Wendt