RE: LabVIEW to Excel wierdness
Hi Alvin, Sounds to me like you need to try and get back to a system that runs your original setup, i.e. Excel 2000 whatever OS you previously used. I have some experience of ActiveX calls to Excel, but have not yet tested old apps with the new version of Excel. My suspicion would be that it is the Excel upgrade that has caused this issue. It also sounds like part of the problem is that the file itself is not opening - can you set the ActiveX property to 'visible' so that you can prove to yourself that the file is correctly opening before going any further with your investigations? Best wishes, Chris Harden. Test System Design Engineer. -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 18 March 2004 16:45 To: [EMAIL PROTECTED] Subject: LabVIEW to Excel wierdness Dear Folks, I have a LabVIEW app that writes report data out to disk as a tab-delimited text file, then triggers an Excel macro. The excel macro is an auto-open macro, so I have a vi which opens the macro.xla file, then an ActiveX call from LV that tells Excel to run the auto-open macro. This has worked fine in the past, for previous projects, but on a recent project (in which I copied over the same vi's from the old project) I could not get it to work. Now labview opens the text file in excel, opens the macro.xla file, then instead of running the macro Excel just closes both files and nothing seems to happen. I tried several different things with timing, thinking maybe the text file wasn't completely open when the macro was triggered, or some such, but to no avail. I put a pop-up message box in the macro at the start, and that works, it pops up, but after I dismiss it I see the same behavior. This morning, I loaded my old app, and to my surprise it no longer worked either. The only change in Excel is I recently upgraded to Office XP, so now it is Excel 2002 vs maybe Excel 2000 before. I have had to fiddle with the ActiveX calls before for changes in Excel, but I tried all the usual fiddling (delete and redrop the invoke/property nodes, change the property to something else and back again, recompile the vi) made no difference. Does anyone else have any experience with this? I am really doing very little with ActiveX, just having Excel open a text file, open a macro file, and run the xlauto_open macro, then waiting until the number of open worksheets goes to 0 so I can close Excel. Thanks in advance, Alvin Alvin W. Moore Jr. Measurement Systems Programmer Research, Development, and Engineering Corning Cable Systems Hickory, NC This e-mail and any files transmitted with it (E-mail) is intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the addressee(s), any disclosure, reproduction, copying, distribution or other use of the E-mail is prohibited. If you have received this E-mail in error, please delete it and notify the sender immediately via our switchboard or return e-mail. Neither the company nor any individual sending this E-mail accepts any liability in respect of the content (including errors and omissions) and timeliness of the E-mail which arise as a result of transmission. If verification is required, please request a hard copy version
RE: LabVIEW to Excel wierdness
Alvin, Although I don't have a direct answer to your question, I had a similar frustrating experience with LabVIEW and Excel earlier this year. I was seeing strange Excel/ActiveX behavior that took almost a week to isolate and fix. In my case (using Excel 2000) I was making updates from LabVIEW via ActiveX and had different behavior in LabVIEW vs. a LabVIEW Application (built executable). In the built executable Excel would lock up, but in the LabVIEW environment it worked fine. After fighting with it for several days I found the cause to be the way I was handling a worksheet refnum. In one section of my code I had a refnum going to a case structure where 2 different operations occurred; in one case I used the Activesheet property whereas the other I used a user defined sheetname. To make a long story short, the case structure worked fine in LabVIEW, but not when built as an application. I ended up doing both operations in series and ignoring the information I wasn't looking for. One way I could detect the problem was when I looked in the task manager I would see Excel open when it should have been closed. So as a long shot suggestion, I guess I'm saying that I've also see behaviors in LV/Excel that seem to cause latent issues that are very hard to isolate. Perhaps you are seeing the same issues I saw since you are opening and closing worksheets. If that's no help, at least take some solace in knowing someone else feels your pain. Let me know if you want more information about what I saw and how I fixed it. John John W. Morrissey[EMAIL PROTECTED] Principal Test Engineer Sycamore Networks 220 Mill Road Chelmsford, MA 01824 (USA) Tel (978) 367-8041Fax (978) 250-9405 Pager [EMAIL PROTECTED]
Re: LabVIEW to Excel wierdness - Solution
Dear Folks, Thanks to everyone who replied to my question about LabVIEW and Excel and ActiveX (repeated below). I did some more testing and playing around with it. It seemed that both the text worksheet and the Excel macro were opening and running, but the macro was acting as if no worksheet was open and just quitting. I was using the Excel auto_open function, in that a macro named auto_open should run immediately when the spreadsheet that contains it is opened. This worked from the explorer, but does not from a spreadsheet opened via Active-X. So, I had another ActiveX call to actually trigger that auto_open macro. One of LabVIEW's examples was for running a specific macro via Active-X. I tried that and it works, so now I'm using that. This has the disadvantage that now my program has to keep track of the macro sheet name and macro name, but at this point I just want it to work. One response I got from Richard Hill, with some vi's from Duane Cousino, mentioned some differences between Excel 97 and XP. I think the real solution might be that even though I open that text file in Excel, I need to explicitly activate that sheet via ActiveX (only in the XP version, the 97 version did not require this), before calling the auto_open macro. However, I have yet to try this. Thanks again to all who responded. Alvin Alvin W. Moore Jr. Measurement Systems Programmer Research, Development, and Engineering Corning Cable Systems Hickory, NC Previous Message Dear Folks, I have a LabVIEW app that writes report data out to disk as a tab-delimited text file, then triggers an Excel macro. The excel macro is an auto-open macro, so I have a vi which opens the macro.xla file, then an ActiveX call from LV that tells Excel to run the auto-open macro. This has worked fine in the past, for previous projects, but on a recent project (in which I copied over the same vi's from the old project) I could not get it to work. Now labview opens the text file in excel, opens the macro.xla file, then instead of running the macro Excel just closes both files and nothing seems to happen. I tried several different things with timing, thinking maybe the text file wasn't completely open when the macro was triggered, or some such, but to no avail. I put a pop-up message box in the macro at the start, and that works, it pops up, but after I dismiss it I see the same behavior. This morning, I loaded my old app, and to my surprise it no longer worked either. The only change in Excel is I recently upgraded to Office XP, so now it is Excel 2002 vs maybe Excel 2000 before. I have had to fiddle with the ActiveX calls before for changes in Excel, but I tried all the usual fiddling (delete and redrop the invoke/property nodes, change the property to something else and back again, recompile the vi) made no difference. Does anyone else have any experience with this? I am really doing very little with ActiveX, just having Excel open a text file, open a macro file, and run the xlauto_open macro, then waiting until the number of open worksheets goes to 0 so I can close Excel. Thanks in advance, Alvin Alvin W. Moore Jr. Measurement Systems Programmer Research, Development, and Engineering Corning Cable Systems Hickory, NC
