Jump to content

_GUICtrlToolbar_ClickButton() & Send() functions reliability?


JohnFK
 Share

Recommended Posts

Hi, I have some experience with AutohotKey but decided to move over to AutoIT recently and I'm currently trying to get my first program to work. So I hope for your understanding if I'm presenting stupid questions...

I'm trying to use AutoIT to control two Windows programs that have a similar kind of user interface as AutoIT programs have; i.e. a popup menu opening from a Windows Taskbar icon. So far I can control the two programs per se, but sometimes (randomly) the commands do not get thru. 

I have noticed that if I block input for the time I send the commands (with _GUICtrlToolbar_ClickButton() and Send()) and put a 200 ms sleep between sending the commands, the likelihood of getting the commands thru increases. However the reliability is still far from 100%.

I wonder what is the beginner's error I'm guilty to, and I would greatly appreciate any help...

A sample code follows below.

Func AutoProtDisable()

    local $iButton

    BlockInput(1)
    Sleep($I_AutoProt_Sleep)


    if StringInStr($I_AutoProtDISA, "OSA:") then
        Do
            $iButton = Get_SysTray_IconText($G_osaSearchtext)
        Until $iButton <> 0

        $x=StringLeft(StringTrimLeft($I_AutoProtDISA, StringInStr($I_AutoProtDISA, "OSA:")+3), 1)
        if StringInStr($G_AutoProtOSA_Controls, $x) Then
            ; MsgBox(0, "", "Executing OSA Autoprot DISABLE =>" & $x & "<=")
            Sleep($I_AutoProt_Sleep)
            _GUICtrlToolbar_ClickButton($hSysTray_Handle, $iButton, "right", False, 1, 0)
            Sleep($I_AutoProt_Sleep)
            Send("P")
            Sleep($I_AutoProt_Sleep)
            Send($x)
        Else
            MsgBox($MB_ICONWARNING+$MB_SYSTEMMODAL,$TITLE, "Unknown Control in OSA AutoProt DISABLE config: " & $x & ".", 5)
        EndIf
    Else
        ; MsgBox(0,"", "OSA AutoProt DISABLE Control not in config file.", 2)
    EndIf

    if StringInStr($I_AutoProtDISA, "WFC:") then
        Do
            $iButton = Get_SysTray_IconText($G_wfcSearchtext)
        Until $iButton <> 0

        $x=StringLeft(StringTrimLeft($I_AutoProtDISA, StringInStr($I_AutoProtDISA, "WFC:")+3), 1)
        if StringInStr($G_AutoProtWFC_Controls, $x) Then
            ; MsgBox(0, "", "Executing WFC Autoprot DISABLE =>" & $x & "<=")
            Sleep($I_AutoProt_Sleep)
            _GUICtrlToolbar_ClickButton($hSysTray_Handle, $iButton, "right", False, 1, 0)
            Sleep($I_AutoProt_Sleep)
            Send("P")
            Sleep($I_AutoProt_Sleep)
            Send($x)
        Else
            MsgBox($MB_ICONWARNING+$MB_SYSTEMMODAL,$TITLE, "Unknown Control in WFC AutoProt DISABLE config: " & $x & ".", 5)
        EndIf
    Else
        ; MsgBox(0,"", "WFC AutoProt DISABLE Control not in config file.", 2)
    EndIf

    BlockInput(0)
    Sleep($I_AutoProt_Sleep)

EndFunc

 

Link to comment
Share on other sites

  • 1 month later...

It seems that the reliability for sending keystrokes to System Tray applications is very low for some time after login, i.e. when various processes within the user's session start, which obviously means also more activity at the System Tray. Seems to be a total hit-and-miss (and mostly miss)...

I wonder if anyone has found a way to use AutoIT to reliably send some input to System Tray programs - a way that works also at times when there is some other activity in the System Tray?

 

Link to comment
Share on other sites

Thank you for your kind suggestion, @Nine!

Could you please guide me one step further? I went quickly thru the UIAutomation contents but at the moment I'm not quite sure which UDFs you specifically point to...

What I'm trying to achieve is to send some commands to SysTray Apps in a controlled way.

The functions I have used have been mainly first _GUICtrlToolbar_ClickButton() to open the SysTray app's popup menu and then use Send() to send the necessary commands. When the system is idle, all commands go thru relatively likely when I use Sleep() between some Send() function calls. What bothers me is that this arrangement does not seem to be 100% reliable, but instead occasionally some commands do not go thru where they should go but instead have some undesired side effects, i.e. they may start some other (seemingly random) Windows application or command and send the command characters there instead.

And the situation seems to go much worse if I try to send the commands to the SysTray apps when there is some other system activity, for example soon after logging the user in, when several other applications are being started up - some of them being naturally SysTray apps...

Link to comment
Share on other sites

There is no perfect general strategy when manipulating SysTray icons and applications.  I always try to avoid them as much as I can.  But when I do not have the choice, I prefer using UIAutomation to launch the application from the SysTray.

 

Link to comment
Share on other sites

Thank you for your reply again.

The SysTray apps that I want to control are existing commercial and/or freeware apps made by other people / companies, and I only want to use their user interfaces via AutoIT.

So I understand correctly that UIAutomation UDFs do not provide me with any tools to do the things I want to do more reliably than the standard AutoIt mechanisms? If they do provide, could you please guide me one step towards the correct direction? I was still not able to get the idea on how to use them in my use case...

Link to comment
Share on other sites

It is more reliable in the sense that it is grabbing objects that are persistent.  Using Toolbar UDF, it is based on index and it can change rapidly overtime if new apps are brought/removed into/from the SysTray. 

As for the tools, I do not recall seing something that would do everything on every SysTray applications.  UIAutomation is just an API that you can use to automate applications.  I was hearing from you that you had difficulties with standard GUI API.  But I may misunderstood you wrong.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...