AutoHotkey Community

It is currently May 25th, 2012, 4:02 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 15 posts ] 
Author Message
 Post subject: Found a bug?
PostPosted: February 13th, 2005, 1:45 am 
Offline

Joined: December 28th, 2004, 12:33 am
Posts: 60
Ok, got a strange problem and found a bug or incorrect documentation, here's the code:

Code:
PromptWindow:
{
  if Debug in promptwindow,all,on
    MsgBox 4112, %WinTitle%, Entering Prompt window routine.
  Loop
  {
    MouseX =
    MouseY =
    MouseColor =
    WinName = EQAutoCrafter - Pixel Setter
    InvisColor = 0xfebaec
    Gui, 2:color, %InvisColor%
    Gui, 2:Font, s20 bold, Verdana
    Gui, 2:Add, Text, w600 cNavy, Please Left Click on %PromptStr%...`n`n  You have 15 seconds...
    Gui, 2:show, x0 y400, %WinName%
    WinWait, A  ; Set the "last found" window for use with the next two commands.
    WinSet, Transcolor, %InvisColor%, %WinName%
    WinSet, AlwaysOnTop, On, %WinName%
    tooltip ontop done
    Sleep 5000
    Gui, 2:-Caption,, %WinName%
    tooltip caption done
    Sleep 5000

    KeyWait LButton, D T15
    Gui 2:Destoy,, %WinName%

;    WinKill %WinName%

    If ErrorLevel
    {
      MsgBox 4132, %WinTitle%, You didn't click on anything`nWould you like to try again?
      ifMsgBox No
        Break
      else
        Continue
    }
    MouseGetPos, MouseX, MouseY
    if ForceY
      MouseY = %ForceY%
    PixelGetColor, MouseColor, %MouseX%, %MouseY%
    if NeedYellow
    {
      if MouseColor != %NeedYellow%
      {
        MsgBox 4130, %WinTitle%, You were trying for the yellow but you didn't get it.`nIt's not required but is preferable.`n`nYou can retry or Ignore it and continue or just Abort and give up.
        IfMsgBox Abort
        {
          MouseColor =
          Break
        }
        ifMsgBox Ignore
          Break
        else
          Continue
      }
    }
  }
  Return
}


Sorry, it's riddled with debugging code and such but I wanted to give you the complete subroutine so you have all the relevant info.

First, when , in my attempt to debug, I added the line Gui Destroy I got the error message that there is no such command. It is fully documented in the docs, missing command or forgot to remove it from the docs when you removed it?

Second, and to me the important question, before I included this code in my main routine it seemed to work just fine, when I added it (and the 2: stuff) to my main program all of a sudden the window is created and all, but when the -caption stuff runs the entire window dissapears from view, not just the caption. Am I doing something wrong?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 14th, 2005, 8:14 am 
Offline

Joined: November 6th, 2004, 11:03 am
Posts: 170
Location: Salt Lake City, UT
1)
Code:
Gui 2:Destroy,, %WinName%

should be just
Code:
Gui 2:Destroy

Destroy was also spelled wrong.

Edit:
2)
Gui Options wrote:
+/-Option1 +/-Option2 ...
One or more options may be specified immediately after the GUI command. For performance reasons, it is better to do this before creating the window; that is, before any use of other sub-commands such as "Gui Add".

AlwaysOnTop [v1.0.25.13+]: Makes the window stay on top of all other windows, which is the same effect as "WinSet AlwaysOnTop".


So you could put
Code:
Gui, 2:+AlwaysOnTop -Caption

Before your other GUI commands, and make that section of code look like this:

Code:
    Gui, 2:+AlwaysOnTop -Caption
    Gui, 2:color, %InvisColor%
    Gui, 2:Font, s20 bold, Verdana
    Gui, 2:Add, Text, w600 cNavy, Please Left Click on %PromptStr%...`n`n  You have 15 seconds...
    Gui, 2:show, x0 y400, %WinName%
    WinSet, Transcolor, %InvisColor%, %WinName%


Requires AHK 1.0.25.13+


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 15th, 2005, 4:23 pm 
Offline

Joined: December 28th, 2004, 12:33 am
Posts: 60
Ok, so maybe it wasn't replied to earlier to save me the embarassment *sigh*, sorry about that. You guys should never have to find my typos.

I'm back to working on this routine now, here is the code that I took it from, note the comment about the -caption having to be after the transparent stuff. That's why it was there instead of at the top. This code snippet came out of the docs somewhere I think but I can't recall where. EDIT: Found it, it's at the bottom of the GUI doc and the below is now a cut and paste from there.

Code:
; Example: On-screen display (OSD):
CustomColor = EEAA99  ; Can be any RGB color (it will be made transparent below).
Gui, Color, %CustomColor%
Gui, Font, s24
Gui, Add, Text, vMyText cLime, XXXXX YYYYY  ; XX & YY serve to auto-size the window.
Gui, Show, x0 y400
WinWait, A  ; Set the "last found" window for use with the next two commands.
; Make all pixels of this color transparent and make the text itself translucent (150):
WinSet, TransColor, %CustomColor% 150
WinSet, AlwaysOnTop, On
; Remove the borders. Due to a quirk in Windows, this must be done after transparency:
Gui, -Caption
SetTimer, UpdateOSD, 500
return



I will continue to play with this for a while but the original code segment does make the window completely dissapear when the caption option is applied (after correcting the spelling of Destroy), which of course is not as intended.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 15th, 2005, 7:50 pm 
Offline

Joined: December 28th, 2004, 12:33 am
Posts: 60
Ok, I'm quite sure I REALLY found a bug this time... hehehe, I have searched my entire application for the WinActivate command, it is used only in this one spot. Here is the routine that has it.

Code:
SendEQ:
{
  IfWinActive %WinTitle%
  {
    WinActivate %EQWinTitle%
    WinWaitActive %EQWinTitle%,,1
    If %ErrorLevel%
    {
      MsgBox Unable to make EQ the Active Window.
      Return
    }
  }
  send %SendEQkey%
  Return
}


I have buttons on a GUI that when pressed with the mouse call this routine, they are also hotkey'd and this is how I am using them with reference to this bug. I have the Gui set with:

Code:
  Gui, Show, x40 w252 h388 NoActivate, %WinTitle%


so as you can see the application starts without ever getting focus, I then press a key that represents a button and the mouse is popped on top of the GUI window and because the focus is wrong the keystroke never makes it to the app and the error message box in the above routine comes up. This ONLY happens the first time a key is pressed, after that it all works as intended. I have also tried giving he GUI focus then removing focus and pressing the key for the first time, the result is the same.

If there is any more info I can give you on this let me know.

PS. Still trying to resolve the dissapearing window that started this thread. *sigh* That code worked great until I added it to my app and put the 2: in each GUI command. I'll keep playing with it.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 15th, 2005, 10:37 pm 
Offline

Joined: December 28th, 2004, 12:33 am
Posts: 60
I seem to have found another bug, I have been using a hotkey to run my program to test it, I just changed it to use SetWorkingDir at the top of the main script, this works fine in all instances but one, when it is triggered with a hotkey it is unable to find the #include files. I assume that AutoHotkey itself is ignoring the change or refusing the command to prevent other problems. If it's not a mistake (bug) it should be documented in SetWorkingDir.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 16th, 2005, 12:36 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Watcher wrote:
so as you can see the application starts without ever getting focus, I then press a key that represents a button and the mouse is popped on top of the GUI window and because the focus is wrong the keystroke never makes it to the app and the error message box in the above routine comes up. This ONLY happens the first time a key is pressed, after that it all works as intended.
Please post the shortest possible test script that an reproduce this problem on any system. Thanks.

Quote:
I just changed it to use SetWorkingDir at the top of the main script, this works fine in all instances but one, when it is triggered with a hotkey it is unable to find the #include files.
Since each #Include is processed before the script begin running, SetWorkingDir has no effect on it. Try specifying absolute paths instead, or ensure that the script is always started with the same *initial* working directory.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 16th, 2005, 12:37 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Watcher wrote:
so as you can see the application starts without ever getting focus, I then press a key that represents a button and the mouse is popped on top of the GUI window and because the focus is wrong the keystroke never makes it to the app and the error message box in the above routine comes up. This ONLY happens the first time a key is pressed, after that it all works as intended.
Please post the shortest possible test script that an reproduce this problem on any system. And please mention the AutoHotkey version number. Thanks.

Quote:
I just changed it to use SetWorkingDir at the top of the main script, this works fine in all instances but one, when it is triggered with a hotkey it is unable to find the #include files.
Since each #Include is processed before the script begin running, SetWorkingDir has no effect on it. Try specifying absolute paths instead, or ensure that the script is always started with the same *initial* working directory.[/quote]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 17th, 2005, 12:51 am 
Offline

Joined: December 28th, 2004, 12:33 am
Posts: 60
Chris wrote:
Please post the shortest possible test script that an reproduce this problem on any system. And please mention the AutoHotkey version number. Thanks.


Version is v1.0.26.00

Sorry but this is as short as I could get it, a cut and paste of this should demonstrate the problem... well issue.

Code:
EQWinTitle = EverQuest II
WinTitle = MyApp

  Gui, +AlwaysOnTop +ToolWindow
  Gui, Add, Button, x6 y290 w40 h30 vBuff1, Buff1
  Gui, Show, x40 w252 h388 NoActivate, %WinTitle%
Key1Speed = 7
  ControlSetText Buff1, %Key1Speed%, %WinTitle%
GoSub InstallHotkeys
GoSub ReInstallHotkeys

Return ;  End of autoexecute

GuiEscape:
ButtonExit:
GuiClose:
ExitApp


ReinstallHotkeys:
{
  ;  Turn off all hotkeys
  GoSub TurnOffHotkeys

  ;  Get the assigned value of buff1-6 and turn them on
  Loopcount = 0
  ButtonList = %Key1Speed% ;,%Key2Speed%,%Key3Speed%,%Key1Dur%,%Key2Dur%,%Key3Dur%
  Loop Parse, ButtonList, CSV
  {
    Loopcount++
    GuiControl,, Buff%Loopcount%, %A_LoopField%
    CurrHotkey = $%A_LoopField%
    Hotkey, %CurrHotkey%, On
  }
  Return
}

InstallHotkeys:
{
  HotKeyList = 1,2,3,4,5,6,7,8,9,0,-,=
  Loop Parse, HotKeyList, CSV
  {
    CurrHotkey = $%A_LoopField%
    Hotkey, %CurrHotkey%, ClickButton
    Hotkey, %CurrHotkey%, off
  }
  Return
}

TurnOffHotkeys:
{
  HotKeyList = 1,2,3,4,5,6,7,8,9,0,-,=
  Loop Parse, HotKeyList, CSV
  {
    CurrHotkey = $%A_LoopField%
    Hotkey, %CurrHotkey%, off
  }
  Return
}

ClickButton:
{
  ;   Strip the $, click on the key in the interface.
  StringReplace MyHotkey, A_ThisHotkey, $
  ControlClick %MyHotkey%, %WinTitle%,,Left, 1, D
  ControlClick %MyHotkey%, %WinTitle%,,Left, 1, U
  Return
}

ButtonBuff1:
{
  ;   Get the value of the button and call SendEQ to send it.
  GuiControlGet Buff1
  SendEQkey = %Buff1%
  GoSub SendEQ
  Return
}

SendEQ:
{
  IfWinActive %WinTitle%
  {
    WinActivate %EQWinTitle%
    WinWaitActive %EQWinTitle%,,1
    If %ErrorLevel%
    {
      MsgBox Unable to make EQ the Active Window.
      Return
    }
  }
  send %SendEQkey%
  Return
}



Chris wrote:
Since each #Include is processed before the script begin running, SetWorkingDir has no effect on it. Try specifying absolute paths instead, or ensure that the script is always started with the same *initial* working directory.


Right, answers are always so obvious when told to you ) I was trying to get it ready to give to some Alpha testers and didn't want my hard coded paths in there. I understand the situation now.

PS. I keep going back to the code that started this thread with no luck on a resolution.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 17th, 2005, 1:14 am 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Watcher wrote:
I have searched my entire application for the WinActivate command, it is used only in this one spot. Here is the routine that has it.
I ran the test script you provided above. Since the window titled "EverQuest II" does not exist, it produces the error message. But this seems to be the expected outcome, so if there's still a problem please clarify.

Quote:
so as you can see the application starts without ever getting focus, I then press a key that represents a button and the mouse is popped on top of the GUI window and because the focus is wrong the keystroke never makes it to the app and the error message box in the above routine comes up. This ONLY happens the first time a key is pressed, after that it all works as intended. I have also tried giving he GUI focus then removing focus and pressing the key for the first time, the result is the same.
Can you give instructions on how to reproduce this behavior using the script you gave above (keeping in mind that I do not have the game). In other words, what hotkeys or buttons do I push after starting the script.

Quote:
I keep going back to the code that started this thread with no luck on a resolution.
I didn't run the script at the top of this topic because it didn't look complete and ready to run. If this is still a problem, a short script (or the one at the top if it's ready to run) would help me isolate it.

Thanks for your patience.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 17th, 2005, 1:36 am 
Offline

Joined: December 28th, 2004, 12:33 am
Posts: 60
Chris wrote:
I ran the test script you provided above. Since the window titled "EverQuest II" does not exist, it produces the error message. But this seems to be the expected outcome, so if there's still a problem please clarify.


Chris wrote:
Can you give instructions on how to reproduce this behavior using the script you gave above (keeping in mind that I do not have the game). In other words, what hotkeys or buttons do I push after starting the script.

That is exactly the problem, try this.

Code:
1. Start your favorite editor
2. Start above code snippet.  (it should NOT take focus)
3. Put focus on editor
4. Press 7 key.


What SHOULD happen is that you press 7 and your editor gets that and the 7 button appears to have been pressed, but focus should never change to the code snippet at all, it should not take it when it is started and it should not take it when a hotkey is pressed.

What does happen is that it pulls focus on the first press of the 7 key, then it tries to pass focus to another program (because it has focus which it should never have gotten) then (correctly) generates the error.

After the first press where it messes up, put focus back in your editor, now you can press 7 as often as you'd like and it does what it should have done the first (and every) time.

Sorry if this is a bit confusing but it's a little hard to explain.

Chris wrote:
I didn't run the script at the top of this topic because it didn't look complete and ready to run. If this is still a problem, a short script (or the one at the top if it's ready to run) would help me isolate it.

Ok, I will post a new complete piece of code that you can run to test this.

Chris wrote:
Thanks for your patience.


Are you kidding? Was that a joke? You write this amazing app, you give it away for free and then, just to blow all our minds you fully support it at no cost more effectively than pay-for services do! ANY time you reply to one of my messages I am VERY grateful. This should be said more often by me and I'm sure most others here agree.

While on that subject the support of all the others here is greatly appreciated by me, SmartGUI is a great app that I appreciate being offerred for free as well.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 17th, 2005, 2:44 am 
Offline

Joined: December 28th, 2004, 12:33 am
Posts: 60
Ok, this is a complete code snippet that will demonstrate the problem. I don't think you can do it wrong so just run it. What I am trying to demonstrate is that the 2nd window dissapears when the -caption option is applied... obviously not what I need nor (I think) what's intended.

Code:
WinTitle = MyApp

  Gui, +AlwaysOnTop +ToolWindow
  Gui, Add, Button, x6 y290 w40 h30 vBuff1, Buff1
  Gui, Show, x40 w252 h388 NoActivate, %WinTitle%
Key1Speed = 7
  ControlSetText Buff1, %Key1Speed%, %WinTitle%

; This is just to make it so you don't have to change focus (since my app doesn't)
; Trying to make the simulation accurate although focus seems irrelivant.
SetTimer DoPrompt, 1000

Return ;  End of autoexecute

GuiEscape:
ButtonExit:
GuiClose:
ExitApp

; I put this in a loop, you can press the mouse key to trigger the loop
DoPrompt:
{
  SetTimer DoPrompt, off
  PromptStr = Here's your prompt
  GoSub PromptWindow
  Return
}

PromptWindow:
{
  Loop
  {
    MouseX =
    MouseY =
    MouseColor =
    WinName = PromptWin
    InvisColor = 0xfebaec
    Gui, 2:color, %InvisColor%
    Gui, 2:Font, s20 bold, Verdana
    Gui, 2:Add, Text, w600 cNavy, Please Left Click on the %PromptStr%...`n`n  You have 15 seconds...
    Gui, 2:show, x0 y400, %WinName%
    WinSet, Transcolor, %InvisColor%, %WinName%
    WinSet, AlwaysOnTop, On, %WinName%
    ToolTip ontop done: window will dissapear now
    Sleep 2000
    Gui, 2:-Caption,, %WinName%

    KeyWait LButton, D T15
    ELevel = %ErrorLevel%

    Gui 2:Destroy
  }
  Return
}


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 17th, 2005, 2:13 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Watcher wrote:
What SHOULD happen is that you press 7 and your editor gets that and the 7 button appears to have been pressed, but focus should never change to the code snippet at all, it should not take it when it is started and it should not take it when a hotkey is pressed.
This appears to be caused by the fact that ControlClick sometimes activates the target window as a side-effect. Although this seems unavoidable, there are probably ways you can achieve the same result without using ControlClick. For example, when the user presses the "7" hotkey, perform the same subroutine as the button would do if pressed directly. Alternatively, add +Disabled to the Gui:
Gui, +AlwaysOnTop +ToolWindow +Disabled
However, this might cause more problems than it solves.

Quote:
After the first press where it messes up, put focus back in your editor, now you can press 7 as often as you'd like and it does what it should have done the first (and every) time.
This appears to be a quirk in the behavior of the OS. Another way to work around it might be to get the first ControlClick out of the way early so that subsequent ones do not activate the button window. Perhaps the first click can be just a test click, sent by the script to do nothing.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 17th, 2005, 2:38 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Watcher wrote:
Ok, this is a complete code snippet that will demonstrate the problem.
This is definitely a bug and will be fixed in the next update. Thanks for posting the example.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 17th, 2005, 3:17 pm 
Offline

Joined: December 28th, 2004, 12:33 am
Posts: 60
Chris wrote:
This appears to be caused by the fact that ControlClick sometimes activates the target window as a side-effect.


More specifically it activates the target window as a side-effect the first time only, once that is over the problem is gone. It's something I can live with though. :lol:

Chris wrote:
This is definitely a bug and will be fixed in the next update. Thanks for posting the example.


Oh Cool, I found a bug :twisted: I know you put out updates fairly often, is there any idea on an ETA at this time? Not a big deal, just curious.

Thanks for checking that out Chris. :D


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: February 18th, 2005, 12:18 am 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
This issue has been fixed in today's update. Thanks again.


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: BrandonHotkey, ogrish, Pulover, rbrtryn, vsub, Zaelia and 26 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group