Write Spreadsheet to String Array on another worksheet

[smercurio_fc]

You don't need to put anything. What you need to do is wire it to the corrent input. That's the "Filename", so it should be wired to the "Filename" input, not the "FileFormat" input. I have no idea why you are wiring to the "FileFormat" input.

[krispiekream]

this is what happened when I do as you mentioned.

and it is correct when I use the FileFormat constants

It saves in the correct format and doesnt through me the above error, but the only problem now is that it will not included the 2nd worksheet I added.

[krispiekream]

Alright, problem solved. I SHOUL'VE SAVE WORKSHEET INSTEAD OF WORKBOOK

thank you everyone for helping me get to this point. thank you for being patience with me as well.

Message Edited by krispiekream on 06-10-2010 01:56 PM

[smercurio_fc]

I have never used the FileFormat input of the SaveAs method, and I've saved Excel workbooks just fine. If I have a chance I'll take a look at your code later this afternoon.

[smercurio_fc]

Your code has several flaws and peculiarities:

• Opening references and then not closing them. You do this in the for-loop where you are creating all those Range objects . This will likely prevent Excel from quitting properly.
• Using auto-indexing and wiring to the N. Do one or the other, not both. This is, again, that loop with all the Range objects.
• Using a shift register to count up when you can simply use the iteration count. This is, again, that loop with all the Range objects. The shift register initialized at one with the Increment is unnecessary. Simply use the iteration count with the Increment. 
• What is the Spreadsheet File to String Array VI? Is this doing the same thing that Read From Spreadsheet File does? 
• There's a section of code at the top right which is effectively commented out. What is the purpose of this?
• The wiring of all those constants to the Index Array function is unnecessary. 
• Do not create paths using string operations. Use the path function Build Path.
• Your VI is ridiculously large. This makes it untenable to modify and debug. This is lousy coding style.

[krispiekream]

thank you so much for giving me pointers and help.

i will look into it and come back to this message for help if i still have questions with your suggestions.

[krispiekream]

• Opening references and then not closing them. You do this in the for-loop where you are creating all those Range objects . This will likely prevent Excel from quitting properly.

I think I can see where you are coming from.

If any of my excel program is open, it will cause this to happen.

can you sugguest a way to fix it?

 i thought i am closing it properly because i did saved, and close the workbook.

• Using auto-indexing and wiring to the N. Do one or the other, not both. This is, again, that loop with all the Range objects.

you can't use both? SometimesI dont want to wire to the N, but labview 7 required me to. I am not sure why.

• Using a shift register to count up when you can simply use the iteration count. This is, again, that loop with all the Range objects. The shift register initialized at one with the Increment is unnecessary. Simply use the iteration count with the Increment.

I can see that i could have used the iteration. It is better

• What is the Spreadsheet File to String Array VI? Is this doing the same thing that Read From Spreadsheet File does? 
• I think it is the same. I forgot why my coworker used it, but it is used throughout my main vi
• There's a section of code at the top right which is effectively commented out. What is the purpose of this?
• I commeneted out for no reason. it doesnt serve any purpose if i put the righter headers in or not, so i commented it out.
• The wiring of all those constants to the Index Array function is unnecessary.
• can you show me what you mean?
• Do not create paths using string operations. Use the path function Build Path.
• okay. got it. just curious on why? both works right?
• Your VI is ridiculously large. This makes it untenable to modify and debug. This is lousy coding style.
• this vi is a subvi of the main vi. i didnt want to make subvis for a subvi, does that make sense? 

[smercurio_fc]

---

krispiekream wrote:

• Opening references and then not closing them. You do this in the for-loop where you are creating all those Range objects . This will likely prevent Excel from quitting properly.

I think I can see where you are coming from.

If any of my excel program is open, it will cause this to happen.

can you sugguest a way to fix it?

 i thought i am closing it properly because i did saved, and close the workbook.

---

Yes. Close the references. This is a general ActiveX issue. The references need to be closed in the reverse order in which you opened them. I didn't look in detaill at that loop, but you should be able to replace the duplication inside by using an inner loop.

---

• What is the Spreadsheet File to String Array VI? Is this doing the same thing that Read From Spreadsheet File does? 
• I think it is the same. I forgot why my coworker used it, but it is used throughout my main vi

---

Perhaps this is from an older version of LabVIEW in which that VI was not polymorphic and only one version (the one that dealt with DBLs) existed? Newer versions of LabVIEW don't have this problem, so you can use the built-in VI directly.

---

• The wiring of all those constants to the Index Array function is unnecessary.
• can you show me what you mean?

---

Index Array will automatically index out the first element if you do not wire in an index value. If you resize the function, then all subsequent indices are automatically incremented by one. To start at a specific index you just need to wire the first one, and let the subsequent ones automatically increment by one. For example, to index out elements 5, 6, 7, 8, 9, 10 you can just do this:

 

---

Do not create paths using string operations. Use the path function Build Path.

• okay. got it. just curious on why? both works right?

---

Both work, but the path method is more robust. It is not platform dependent, and can catch invalid paths.

---

• Your VI is ridiculously large. This makes it untenable to modify and debug. This is lousy coding style.
• this vi is a subvi of the main vi. i didnt want to make subvis for a subvi, does that make sense? 

---

No, and that is a poor excuse for not making subVIs.

Message Edited by smercurio_fc on 06-11-2010 05:45 PM

[tbob]

---

krispiekream wrote:

• this vi is a subvi of the main vi. i didnt want to make subvis for a subvi, does that make sense? 

---

I have made subvi's for subvi's for subvi's for subvi's......  Who knows how many levels I've gone.  But my code is very readable and every vi fits on one screen.  Once you know the function of the subvi, you don't need to see its code.  Just a comment on the block diagram about what the subvi does.  It becomes a black box.  This is what makes large code readable and easy to understand.