When I'm trying to set combobox to precise item, combobox is jumping to the next one item - "1.4301" to "1.4301_4N" (I can understand it's because similar beggining, prefixes).
Also another combobox is jumping from "1,5" to "5" (I can understand it's because of comma).
I'm using ControlSend, %matcombo%, %gmat%, Job. Where matcombo is controlNN of combobox, and gmat is variable from other form but value always exist in combobox.
How to set precise item in combobox and avoid this behaviour?
Combobox Bug Topic is solved
Combobox Bug
Last edited by BriHecato on 03 Apr 2018, 16:59, edited 1 time in total.
Re: Combobox issue
Why don't you want to use Control, ChooseString, ...?
Re: Combobox issue
Thanks alot - this solve my second "comma" problem, but still first problem persist.
As in documentation: "Sets the selection (choice) in a ListBox or ComboBox to be the first entry whose leading part matches String."
My items in this combo are (in order):
And when my %gmat% variable is "1.4301" - both Control and ControlSend commands make combobox set on "1.4301_4N" ... why? It's the next entry!
As in documentation: "Sets the selection (choice) in a ListBox or ComboBox to be the first entry whose leading part matches String."
My items in this combo are (in order):
Code: Select all
-All-
1.4301
1.4301_4N
1.4301_BA
...
Re: Combobox issue
Congratulations!
You've found a bug in script_autoit.cpp (the source containing code/functions originally written for AutoIt):This is sending a CB_SELECTSTRING message to the control. The third parameter (wParam) has to be -1 instead of 1 to search the entire list. 1 starts the search at the third list entry.
You should change the topic's title to "Combobox bug".
You've found a bug in script_autoit.cpp (the source containing code/functions originally written for AutoIt):
Code: Select all
else // ComboBox or single-select ListBox.
if (!SendMessageTimeout(control_window, msg, 1, (LPARAM)aValue, SMTO_ABORTIFHUNG, 2000, &dwResult)
|| dwResult == CB_ERR) // CB_ERR == LB_ERR
goto error;
You should change the topic's title to "Combobox bug".
Re: Combobox issue
- There's another *really important* problem with ChooseString. Basically, it's not working on newer OSes.
- E.g. on Windows 7, it *appears* to change the chosen item, but the external program does not register the change.
- E.g. open Notepad, do 'File, Save', use ChooseString to change the encoding from ANSI to UTF-8, and save the file, then choose Save As..., this will show that the file has been saved as ANSI, not UTF-8, the change in ComboBox selection will not have been registered.
- The code below notifies the program, and fixes the issue.
- (Note: If you send key presses to the ComboBox, that can also 'notify' the window.)
- E.g. on Windows 7, it *appears* to change the chosen item, but the external program does not register the change.
- E.g. open Notepad, do 'File, Save', use ChooseString to change the encoding from ANSI to UTF-8, and save the file, then choose Save As..., this will show that the file has been saved as ANSI, not UTF-8, the change in ComboBox selection will not have been registered.
- The code below notifies the program, and fixes the issue.
- (Note: If you send key presses to the ComboBox, that can also 'notify' the window.)
Code: Select all
;based on:
;GUI COMMANDS: COMPLETE RETHINK - AutoHotkey Community
;https://autohotkey.com/boards/viewtopic.php?f=5&t=25893&p=132424#p132424
q:: ;Notepad - set ComboBox to UTF-8 (visual change in selection, Notepad is *not* notified)
Control, ChooseString, UTF-8, ComboBox3, A
return
w:: ;Notepad - set ComboBox to UTF-8 (visual change in selection, Notepad *is* notified)
Control, ChooseString, UTF-8, ComboBox3, A
ControlGet, hCtl, Hwnd,, ComboBox3, A
;CBN_SELENDOK := 9
vCtlID := DllCall("user32\GetDlgCtrlID", Ptr,hCtl)
hWndParent := DllCall("user32\GetParent", Ptr,hCtl, Ptr)
SendMessage, 0x111, % vCtlID|(9 << 16), % hCtl,, % "ahk_id " hWndParent ;WM_COMMAND := 0x111
return
Last edited by jeeswg on 03 Apr 2018, 17:36, edited 1 time in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: Combobox Bug
@just me - so how to make this work? "Switch/case" with if/else - and targeting items?
@jeeswg - where in windows notepad you have combobox3 (in main window) with encoding ???
@jeeswg - where in windows notepad you have combobox3 (in main window) with encoding ???
Re: Combobox Bug
@BriHecato: The Save As dialog, I've added 'do 'File, Save'', to my post above.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: Combobox Bug
Hi BriHecato,
this might be used as a workaround until the bug is fixed:
this might be used as a workaround until the bug is fixed:
Code: Select all
#NoEnv
gMat := "1.4301"
matcombo := "ComboBox1"
Gui, Add, ComboBox, , -All-|1.4301|1.4301_4N|1.4301_BA
Gui, Show, , Job
Sleep, 1000
; --------------------------------------------------------------------------------------------------------------------------------
; Control, ChooseString, %gmat%, %matcombo%, Job
SendMessage, 0x014C, -1, &gmat, %matcombo%, Job ; CB_FINDSTRING = 0x014C
If !(ErrorLevel & 0x80000000) ; ErrorLevel is set to CB_ERR (-1) if the string could not be found
Control, Choose, % (ErrorLevel + 1), %matcombo%, Job ; the item index returned by CB_FINDSTRING is 0-basedReturn
; --------------------------------------------------------------------------------------------------------------------------------
Return
GuiClose:
ExitApp
Last edited by just me on 04 Apr 2018, 01:39, edited 1 time in total.
Re: Combobox Bug
@just me: I just tested, and an ErrorLevel of '-1' is different on AHK x64/x32:
0xFFFFFFFF (AHK x32)
0xFFFFFFFFFFFFFFFF (AHK x64)
So an x64/x32 compatible version would be:
if !(ErrorLevel & 0xFFFFFFFF = 0xFFFFFFFF)
0xFFFFFFFF (AHK x32)
0xFFFFFFFFFFFFFFFF (AHK x64)
So an x64/x32 compatible version would be:
if !(ErrorLevel & 0xFFFFFFFF = 0xFFFFFFFF)
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: Combobox Bug
True, thanks. I didn't remember that AHK 64 always receives a signed int64. Fixed!
Re: Combobox Bug
OK, I finally got a few things cleared up. (I hope that the SendMessage description is accurate.)
- From the MSDN pages:
- PostMessage returns a BOOL (Int)
- SendMessage returns an LRESULT (Ptr) [the Int/Int64 (Ptr) is converted to an Int64, (so an Int effectively becomes a UInt), note: if AHK x64 receives a reply from an x32 window, the message will be Int-sized]
- GetMenuItemID returns a UINT (UInt)
- Was there a reason why SendMessage/OnMessage sometimes convert signed to unsigned integers?
- Is that the shortest we can make the bitwise logic? I'm going to check over multiple scripts that check ErrorLevel for -1.
- From the MSDN pages:
- PostMessage returns a BOOL (Int)
- SendMessage returns an LRESULT (Ptr) [the Int/Int64 (Ptr) is converted to an Int64, (so an Int effectively becomes a UInt), note: if AHK x64 receives a reply from an x32 window, the message will be Int-sized]
- GetMenuItemID returns a UINT (UInt)
- Was there a reason why SendMessage/OnMessage sometimes convert signed to unsigned integers?
- Is that the shortest we can make the bitwise logic? I'm going to check over multiple scripts that check ErrorLevel for -1.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: Combobox Bug
Your bitwise logic is simply incorrect.
This would also trigger if a 64 bit program returned 0xFFFFFFFF.
There is no way to know if the return value is -1 without checking the program the message was send to.
It just works in this specific context because it is highly unlikely that anyone ever using this code will have a ComboBox containing 0xFFFFFFFF items.
It's roughly as correct as just mes.
This would also trigger if a 64 bit program returned 0xFFFFFFFF.
There is no way to know if the return value is -1 without checking the program the message was send to.
It just works in this specific context because it is highly unlikely that anyone ever using this code will have a ComboBox containing 0xFFFFFFFF items.
It's roughly as correct as just mes.
Recommends AHK Studio
Re: Combobox Bug
AHK is actually calling SendMessageTimeout. The returned result is of type PDWORD_PTR. AFAIK, that's the only reason why AHK 32 returns an UInt. On AHK 64 a signed value is returned only because AHK doesn't support UInt64.jeeswg wrote:- Was there a reason why SendMessage/OnMessage sometimes convert signed to unsigned integers?
Re: Combobox Bug
Does anyone know a good reason why AHK doesn't support UInt64?
Re: Combobox Bug
There are only 2 kind of number data types in AHK:
Double: 0.12..
Int64: 1234
Adding a UInt64 type would require adding a new number type that is not very distinct from the Int64.
You would have to add a whole typing system if you really wanted to add them seriously.
Double: 0.12..
Int64: 1234
Adding a UInt64 type would require adding a new number type that is not very distinct from the Int64.
You would have to add a whole typing system if you really wanted to add them seriously.
Recommends AHK Studio
Re: Combobox Bug
- @Flipeador: While native UInt64 might be nice, I think that using the Format function where necessary, solves all problems. Do you have any major issues? I had thought though, that some sort of support for infinite precision integers stored as strings, might be useful.
- @nnnik: Yes I knew all of that from your earlier post, but thanks for pointing it out, and thanks for the info re. AHK using Double/Int64. I was too busy at the time to do the testing in order to produce this one-liner which will hopefully work in all circumstances.
if !(ErrorLevel = (A_PtrSize=8 && JEE_ProcessIs64Bit(vPID) ? -1 : 0xFFFFFFFF))
Cf. my quick fix from earlier:
if !(ErrorLevel & 0xFFFFFFFF = 0xFFFFFFFF)
Btw it's unlikely that controls will ever have 4294967295 or more items (0xFFFFFFFF), but I never cut corners!- [EDIT:] Edited script slightly.
- I need to get this ErrorLevel thing right as it affects this, I will update it when I feel sure of the answer.
GUIs via DllCall: get/set internal/external control text - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=40514
- [EDIT: 2019-09-27]
- Rewrote the test script, and added checks for SendMessageTimeout:
- @nnnik: Yes I knew all of that from your earlier post, but thanks for pointing it out, and thanks for the info re. AHK using Double/Int64. I was too busy at the time to do the testing in order to produce this one-liner which will hopefully work in all circumstances.
if !(ErrorLevel = (A_PtrSize=8 && JEE_ProcessIs64Bit(vPID) ? -1 : 0xFFFFFFFF))
Cf. my quick fix from earlier:
if !(ErrorLevel & 0xFFFFFFFF = 0xFFFFFFFF)
Btw it's unlikely that controls will ever have 4294967295 or more items (0xFFFFFFFF), but I never cut corners!
Code: Select all
;test SendMessage and ErrorLevel
;2 separate scripts:
;test SendMessage 1.ahk
Gui, Add, ComboBox,, abc|def|ghi
Gui, Show
;test SendMessage 2.ahk
vText := "abc"
vText := "def"
vText := "ghi"
vText := "---"
WinGet, vPID, PID, ahk_class AutoHotkeyGUI
SendMessage, 0x14C, -1, % &vText, ComboBox1, ahk_class AutoHotkeyGUI ;CB_FINDSTRING := 0x14C
vRet := ErrorLevel
if (vRet = (A_PtrSize=8 && JEE_ProcessIs64Bit(vPID) ? -1 : 0xFFFFFFFF))
vRet2 := -1
else
vRet2 := vRet
ControlGet, hCtl, Hwnd,, ComboBox1, ahk_class AutoHotkeyGUI
vRet3 := DllCall("user32\SendMessage", "Ptr",hCtl, "UInt",0x14C, "UPtr",-1, "Ptr",&vText, "Ptr") ;CB_FINDSTRING := 0x14C
MsgBox, % vRet " (" vRet2 ")`r`n" vRet3
return
;AHK GUI result result (DllCall)
;32 32 4294967295 -1
;32 64 4294967295 4294967295
;64 32 4294967295 -1
;64 64 -1 -1
JEE_ProcessIs64Bit(vPID)
{
if !vPID
return
else if !A_Is64bitOS
return 0
;PROCESS_QUERY_INFORMATION := 0x400
hProc := DllCall("kernel32\OpenProcess", "UInt",0x400, "Int",0, "UInt",vPID, "Ptr")
DllCall("kernel32\IsWow64Process", "Ptr",hProc, "Int*",vIsWow64Process)
DllCall("kernel32\CloseHandle", "Ptr",hProc)
return !vIsWow64Process
}
- I need to get this ErrorLevel thing right as it affects this, I will update it when I feel sure of the answer.
GUIs via DllCall: get/set internal/external control text - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=40514
- [EDIT: 2019-09-27]
- Rewrote the test script, and added checks for SendMessageTimeout:
Code: Select all
/*
;script 1:
Gui, Add, ComboBox,, abc|def|ghi
Gui, Show,, % "Test" (A_PtrSize=8?64:32)
*/
;==================================================
;script 2:
vAHKBit := A_PtrSize=8?64:32
WinGet, hWnd32, ID, Test32 ahk_class AutoHotkeyGUI
WinGet, hWnd64, ID, Test64 ahk_class AutoHotkeyGUI
ControlGet, hCtl32, Hwnd,, ComboBox1, % "ahk_id " hWnd32
ControlGet, hCtl64, Hwnd,, ComboBox1, % "ahk_id " hWnd64
vMsg := 0x14C ;CB_FINDSTRING := 0x14C
vText := "MyNeedle"
wParam := -1
lParam := &vText
Loop 2
{
vNum := A_Index*32
hCtl := hCtl%vNum%
SendMessage, % vMsg, % wParam, % lParam,, % "ahk_id " hCtl
vRet1 := ErrorLevel
vRet2 := DllCall("user32\SendMessage", "Ptr",hCtl, "UInt",vMsg, "UPtr",wParam, "Ptr",lParam, "Ptr")
vRet3 := 0
;SMTO_ABORTIFHUNG := 0x2 ;source: WinUser.h
DllCall("user32\SendMessageTimeout", "Ptr",hCtl, "UInt",vMsg, "UPtr",wParam, "Ptr",lParam, "UInt",0x2, "UInt",2000, "UPtr*",vRet3, "Ptr")
vRet%vNum% := vRet1 " " vRet2 " " vRet3
}
Clipboard .= "`r`n" "AHK" "`t" "GUI" "`t" "SM AHK" "`t" "SM DC" "`t" "SMT DC"
Clipboard .= "`r`n" vAHKBit "`t" "32" "`t" vRet32
Clipboard .= "`r`n" vAHKBit "`t" "64" "`t" vRet64
MsgBox, % "done"
return
;==================================================
;results:
;note: SM AHK and SMT DC match
;headers: AHK bitness, GUI bitness, SendMessage AHK function, SendMessage DllCall, SendMessageTimeout DllCall
;AHK GUI SM AHK SM DC SMT DC
;32 32 4294967295 -1 4294967295
;32 64 4294967295 -1 4294967295
;64 32 4294967295 4294967295 4294967295
;64 64 -1 -1 -1
;==================================================
Last edited by jeeswg on 27 Sep 2019, 13:00, edited 2 times in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: Combobox Bug
Thanks to both for answering, but I was looking for something more detailed.
Yes... there are solutions, but they are not pleasant.I think that using the Format function where necessary, solves all problems
I do not think this is more important than adding UInt64 support. I agree that it would be interesting, but I do not think I'll use it, it is not common and, if implemented, I would probably never use it; unless I'm about to programing a calculator or something, but since it already exists, i would not waste my time.some sort of support for infinite precision integers stored as strings, might be useful
Re: Combobox Bug
@nnnik: Btw, from experience I'd say that AutoHotkey has Double and Int64, but is there anything more concrete that can be cited? Also are there any specs on how strings and binary data are handled (and objects, object keys, ClipboardAll and window groups).
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Re: Combobox Bug
Object keys are stored in a search tree as far as I can tell.
https://en.wikipedia.org/wiki/Search_tree
But I only got that from experimentation.
ClipboardAll and all the binary stuff is handled similar to a string whose size is just larger than the 0 terminator - recently lexikos added some stuff to make it better I will have to look into them again.
I have never really cared for window groups and never looked into them either.
BTW: good work on the 1-liner - I will reccomend it
https://en.wikipedia.org/wiki/Search_tree
But I only got that from experimentation.
ClipboardAll and all the binary stuff is handled similar to a string whose size is just larger than the 0 terminator - recently lexikos added some stuff to make it better I will have to look into them again.
I have never really cared for window groups and never looked into them either.
BTW: good work on the 1-liner - I will reccomend it
Recommends AHK Studio
Re: Combobox issue
That is inaccurate. ChooseString fails with this particular ComboBox for one of the following reasons:jeeswg wrote:There's another *really important* problem with ChooseString. Basically, it's not working on newer OSes.
- The ComboBox has no ID.
- The ComboBox has an ID of 0 (which one may assume is impossible, since "If the [GetDlgCtrlID] function fails, the return value is zero.").
The ComboBox has an ID, but GetDlgCtrlID fails (returns 0) for some reason.[Edit: SetLastError/A_LastError indicates it is not failing.] (If that's the case, Notepad does not use the ID to identify the control.)
ChooseString does virtually the same thing as your script, but has more error-checking.
Who is online
Users browsing this forum: No registered users and 44 guests