How to use an object as a parameter?

[DChild]

Hi,

I'm trying to populate several sheets in an Excel Workbook.  But it doesn't appear that a subroutine or a function with the workbook parameter is allowed.

When I try to use the workbook object inside the subroutine, there's an error that


    Ole object does not exist, or period is used instead of a comma


If I use the workbook object outside of the subroutine, then it works fine.


In the following, wb is the workbook object.

Code Select Expand


#DefineSubroutine Populate_Sheet( s_Type, s_FileName, wb )

ws = wb.Sheets( s_Type )    ; <-- This is where the error occurs.  The is a sheet with the value of s_Type, and this line works outside of the subroutine.
ws.Activate



;...
;...
;...
#EndSubroutine




wb_ThisWorkbook = o_Excel.ActiveWorkbook
wb_ThisWorkbook.SaveAs( "c:\Projects\WinBatch\data\whodat.xlsx" )


s_FileDate = Populate_Sheet( s_Type, s_FileName, wb_ThisWorkbook )



[td]

If you are using a less than about nine year old version of WinBatch there is nothing special about passing a COM Automation object to a subroutine. 

I tried your example and if the subroutine was passed valid information it worked the same way the workbook object member from the mainline script did. If the subroutine was passed invalid information it failed the same way the main line version failed with the same information.

You might want to run your script in the WinBatch Studio debugger and examine the variable values as you step though your script.  You may find that you are stepping on a variable or not initializing a variable or whatever.

[DChild]

Td,

Yeah, I'm probably misdiagnosing the cause.  The object in question, has the same numeric value before the script, that is has inside the script.  And the Winbatch version is the latest one.

It's gotta be some other kind of setup problem.

Would you be able to post the snippet that you're using?

[DChild]

Interesting.  Although the error takes place on the line where we are assigning the worksheet, it's actually referring to a subsequent line, the 7th line in the procedure.  This happens, even if we put breakpoints on each line, before that line; the error still occurs on the first line in the procedure.

Good enough, should be able to work through it, now.

[DAG_P6]

In 2011 and 2012, I developed an application that freely passed around a COM object, in some cases three or four calls deep into a call stack. The application gave me plenty of challenges, but losing access to the COM object wasn't among them.