 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
Watcher
Joined: 27 Dec 2004
Posts: 60
|
 Posted: Sun Feb 13, 2005 12:45 am Post subject: Found a bug? |
 |
|
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? |
|
| Back to top |
|
 |
ranomore
Joined: 06 Nov 2004
Posts: 170
Location: Salt Lake City, UT
|
| Posted: Mon Feb 14, 2005 7:14 am Post subject: |
|
|
1)
| Code: | Gui 2:Destroy,, %WinName%
|
should be just
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+ |
|
| Back to top |
|
|
Watcher
Joined: 27 Dec 2004
Posts: 60
|
| Posted: Tue Feb 15, 2005 3:23 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Watcher
Joined: 27 Dec 2004
Posts: 60
|
| Posted: Tue Feb 15, 2005 6:50 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Watcher
Joined: 27 Dec 2004
Posts: 60
|
| Posted: Tue Feb 15, 2005 9:37 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10716
|
| Posted: Wed Feb 16, 2005 11:36 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10716
|
| Posted: Wed Feb 16, 2005 11:37 am Post subject: |
|
|
| 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] |
|
| Back to top |
|
|
Watcher
Joined: 27 Dec 2004
Posts: 60
|
| Posted: Wed Feb 16, 2005 11:51 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10716
|
| Posted: Thu Feb 17, 2005 12:14 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Watcher
Joined: 27 Dec 2004
Posts: 60
|
| Posted: Thu Feb 17, 2005 12:36 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Watcher
Joined: 27 Dec 2004
Posts: 60
|
| Posted: Thu Feb 17, 2005 1:44 am Post subject: |
|
|
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
}
|
|
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10716
|
| Posted: Thu Feb 17, 2005 1:13 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10716
|
| Posted: Thu Feb 17, 2005 1:38 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Watcher
Joined: 27 Dec 2004
Posts: 60
|
| Posted: Thu Feb 17, 2005 2:17 pm Post subject: |
|
|
| 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. 
| 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  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.  |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10716
|
| Posted: Thu Feb 17, 2005 11:18 pm Post subject: |
|
|
| This issue has been fixed in today's update. Thanks again. |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
