Best practice when using PowerShell and other languages

This topic contains 4 replies, has 2 voices, and was last updated by Profile photo of Dave Wyatt Dave Wyatt 1 year, 9 months ago.

  • Author
    Posts
  • #22526
    Profile photo of Travis Hubbard
    Travis Hubbard
    Participant

    I am currently working on an automation project that involves using PowerShell and AutoIT to automate a process. I'm using PS whenever possible but there are certain things like GUI manipulation that AutoIT really excels at.

    My question is what are some ways in which I can essentially have these two languages talk to each other? For instance, I run a PS script that executes several user defined functions then calls an AutoIT exe to do some GUI manipulation. The main PS script then needs a way to determine when (or if) the AutoIT process has completed so that the PS script can continue.

    Should I do something crude like create temp files based on the status of various steps? Is there a better way?

    Apologies if this was too basic of a question. I am a beginner with PowerShell and not a programmer by trade.

    Thanks in advance,
    Travis

  • #22527
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    If I remember correctly, AutoIT has an ActiveX interface which might suit your needs better. If it works, you could take advantage of its GUI manipulation functionality without ever leaving your PowerShell script. That said, COM objects are not always the easiest (or fastest) things to use from PowerShell, so it might take some trial and error to figure it out.

  • #22552
    Profile photo of Travis Hubbard
    Travis Hubbard
    Participant

    Thanks Dave,

    I've looked at the AutoIT ActiveX interface you referenced. Lets say AutoIT didn't have this capability. Would a person in that situation resort to using the creation of temp files and checking for their existence?

  • #22553
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    That's something you'd have to answer on a case-by-case basis. Some applications might be intended for command-line use and have output that you could capture and parse, others might require some other method (such as creating some sort of output file, as you mentioned.) Either way, it's likely to be a much larger pain in the butt than using a PowerShell cmdlet would be, since you are no longer getting rich objects out of the command.

  • #22554
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    That's something you'd have to answer on a case-by-case basis. Some applications might be intended for command-line use and have output that you could capture and parse, others might require some other method (such as creating some sort of output file, as you mentioned.) Either way, it's likely to be a much larger pain in the butt than using a PowerShell cmdlet would be, since you are no longer getting rich objects out of the command.

You must be logged in to reply to this topic.