Author Topic: TimeSpan and the CLR  (Read 4201 times)

stanl

  • Pundit
  • *****
  • Posts: 934
TimeSpan and the CLR
« on: January 24, 2014, 11:54:55 am »
This is based on a recent post in the Main forum where a user wanted to set and increment a time variable. Thought I'd take a whack at the CLR TimeSpan... Got an error, so yet another chance to learn

Code: Winbatch
;trying time span with WB and CLR
t = ObjectClrNew( "System.DateTime")
today = t.Now
Message("",today)


;get error Method Type Signature Not Interop Compatible
;h =  ObjectType("I4",1)
;m =  ObjectType("I4",0)
;s =  ObjectType("I4",0)
;ts = ObjectClrNew( "System.TimeSpan",h,m,s)
;new= today.add(ts)
;Message("",new)

t=0
Exit
 

td

  • Tech Support
  • *****
  • Posts: 3014
    • WinBatch
Re: TimeSpan and the CLR
« Reply #1 on: January 24, 2014, 01:31:45 pm »
The 'more error info' message is poorly worded but it still says it all.  It likely ain't gonna work in WinBatch.  There aren't many of them but some of the 'System' FCL structures don't support being created using the CLR's native early bind COM API.   
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stanl

  • Pundit
  • *****
  • Posts: 934
Re: TimeSpan and the CLR
« Reply #2 on: January 25, 2014, 03:14:59 am »
The 'more error info' message is poorly worded but it still says it all.  It likely ain't gonna work in WinBatch.  There aren't many of them but some of the 'System' FCL structures don't support being created using the CLR's native early bind COM API.

Does this also apply to Plan-B's: i.e. leveraging through Powershell, or creating a .dll from C# code?

DAG_P6

  • Full Member
  • ***
  • Posts: 184
  • WinBatch rocks, and so does Wilson WindowWare!
    • WizardWrx
Re: TimeSpan and the CLR
« Reply #3 on: January 25, 2014, 12:14:21 pm »
While I cannot answer with respect to PowerShell, I have created a couple of COM DLLs in C#, to enable me to import assembly properties into Microsoft Excel. To be sure, there are plenty of rules, limitations, and traps for the unwary, and the process is poorly documented, but it can be done.

Off the top of my head, two of the most important rules are the following.

  • Static methods are unsupported.
  • All objects must have a public default constructor that takes no arguments.
David A. Gray
You are more important than any technology.

td

  • Tech Support
  • *****
  • Posts: 3014
    • WinBatch
Re: TimeSpan and the CLR
« Reply #4 on: January 25, 2014, 11:27:59 pm »
Does this also apply to Plan-B's: i.e. leveraging through Powershell, or creating a .dll from C# code?

A simple C# cover assembly compiled using WinBatch would be one possible solution.  However, since the problem can be easy solved in strait WIL without the assistance of the CLR, it appears to be overkill. 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

DAG_P6

  • Full Member
  • ***
  • Posts: 184
  • WinBatch rocks, and so does Wilson WindowWare!
    • WizardWrx
Re: TimeSpan and the CLR
« Reply #5 on: January 27, 2014, 06:00:40 pm »
Does this also apply to Plan-B's: i.e. leveraging through Powershell, or creating a .dll from C# code?

A simple C# cover assembly compiled using WinBatch would be one possible solution.  However, since the problem can be easy solved in strait WIL without the assistance of the CLR, it appears to be overkill.

I agree. Convert to OADate, and do all the maths you want.
David A. Gray
You are more important than any technology.