GUI COMMANDS: COMPLETE RETHINK
Posted: 20 Dec 2016, 10:39
GUI COMMANDS: COMPLETE RETHINK
tl;dr do everything GUI via custom functions
(1) I've already created about 100 functions
(2) issues with MsgBox / InputBox / ToolTip (e.g. font size, background colour, countdown, beep, word wrap, ampersands, text dimension calculations via DrawTextEx)
(3) AutoHotkey v2 phase out of Progress / SplashImage / SplashTextOn/Off
(4) more support needed for external listviews / treeviews / save as prompts / status bars etc
(5) doubling up of commands for internal/external windows
(6) the regular need for functions as hacks to GUI commands (e.g. image lists)
(7) can't create a window with no icon without dodgy workarounds (e.g. in Windows XP)
(8) all GUI windows must have the same class name (which must be pre-edited in the AutoHotkey.exe binary)
(9) AutoHotkey depends on other programs having unique class names (especially before the 'ahk_exe' option was added), so alas there is hypocrisy there
(10) various issues I had even trying to make a Notepad clone (e.g. save as prompt with additional 'Encoding:' drop-down menu, and 'about' window with no icon)
(11) if I want to replace MsgBox, with a custom MsgBox() in all my scripts, will GUI 99 already be in use in some of them? (CRUCIAL ISSUE)
(12) 'Any script that uses the GUI command anywhere is automatically persistent' and single-instance, so potentially fairly-involved alterations to all scripts will be necessary (CRUCIAL ISSUE)
(13) some aspects of GUI commands are quirky like: Gui Submit/AltSubmit, special variables, and special letters (e.g. g-label notifications for listviews)
(14) Forms 0.8 has useful initial code (e.g. Dlg.ahk, RichEdit.ahk, Toolbar.ahk)
(15) GUI via functions will make it easier for programming newbies
(16) GUI via functions will make it easier for programming experts new to AutoHotkey (the functions and message queues are more like how they would program in say C++)
(17) programmers of other languages can learn more easily from AutoHotkey code, leading to cross-fertilisation
(18) uniformity is achieved between how all control types in GUIs are treated
- Although various exe updates and custom functions have resolved most of my AutoHotkey problems, I don't think this problem is going to be solved without a major rethink.
- If we don't do something about this, I'm planning on a breakaway fork called AutoGUI. (jk)
- I was a newbie when I began using AutoHotkey, and things like there being no functions for modifying external listviews/treeviews were a real headache, and almost immediately I was working with things like VirtualAllocEx, because the functions weren't there.
- And a lot of the quirks of the GUI commands, confused me and caused problems, but when I actually started to take a look under the bonnet (hood), it all made a lot more sense and became easier.
- The dilemma for me, whenever I want to do anything GUI, is, which route, GUI commands or custom functions?
- Invariably I need custom GUI functions anyway, but dealing with GUI commands can often get clunky, and I double up the work.
- If I take the custom-functions-only route, that's fine, but for some reason, up till now, it seems nobody else has shared any serious 'GUI from scratch via DllCall' examples. Every time I hit a slight obstacle trying to recreate some of the GUI commands, no-one's there to help, because the GUI commands already perform that function.
- Surely I can't have been the only one having these thoughts.
- Anyway, I feel that I've done 95% of the work, and with a few pointers my GUI command replacement scheme can be completed (e.g. full Basic/32/64-bit support).
- I did find majkinetor's custom MsgBox, the one time I got lucky in this quest, and for anyone who doesn't know how GUI works behind the scenes, it's basically: RegisterClass and CreateWindowEx. Then you handle messages in a message queue and make use of WndProcs.
- AutoHotkey as a community should consider GUI via custom-made functions, rather than the AutoHotkey GUI commands, as a standard way of producing GUI, even the preferred way, in a similar way to Gdip.ahk and Acc.ahk being key parts of AutoHotkey.
- Welcome to the new golden age of AutoHotkey.
tl;dr do everything GUI via custom functions
(1) I've already created about 100 functions
(2) issues with MsgBox / InputBox / ToolTip (e.g. font size, background colour, countdown, beep, word wrap, ampersands, text dimension calculations via DrawTextEx)
(3) AutoHotkey v2 phase out of Progress / SplashImage / SplashTextOn/Off
(4) more support needed for external listviews / treeviews / save as prompts / status bars etc
(5) doubling up of commands for internal/external windows
(6) the regular need for functions as hacks to GUI commands (e.g. image lists)
(7) can't create a window with no icon without dodgy workarounds (e.g. in Windows XP)
(8) all GUI windows must have the same class name (which must be pre-edited in the AutoHotkey.exe binary)
(9) AutoHotkey depends on other programs having unique class names (especially before the 'ahk_exe' option was added), so alas there is hypocrisy there
(10) various issues I had even trying to make a Notepad clone (e.g. save as prompt with additional 'Encoding:' drop-down menu, and 'about' window with no icon)
(11) if I want to replace MsgBox, with a custom MsgBox() in all my scripts, will GUI 99 already be in use in some of them? (CRUCIAL ISSUE)
(12) 'Any script that uses the GUI command anywhere is automatically persistent' and single-instance, so potentially fairly-involved alterations to all scripts will be necessary (CRUCIAL ISSUE)
(13) some aspects of GUI commands are quirky like: Gui Submit/AltSubmit, special variables, and special letters (e.g. g-label notifications for listviews)
(14) Forms 0.8 has useful initial code (e.g. Dlg.ahk, RichEdit.ahk, Toolbar.ahk)
(15) GUI via functions will make it easier for programming newbies
(16) GUI via functions will make it easier for programming experts new to AutoHotkey (the functions and message queues are more like how they would program in say C++)
(17) programmers of other languages can learn more easily from AutoHotkey code, leading to cross-fertilisation
(18) uniformity is achieved between how all control types in GUIs are treated
- Although various exe updates and custom functions have resolved most of my AutoHotkey problems, I don't think this problem is going to be solved without a major rethink.
- If we don't do something about this, I'm planning on a breakaway fork called AutoGUI. (jk)
- I was a newbie when I began using AutoHotkey, and things like there being no functions for modifying external listviews/treeviews were a real headache, and almost immediately I was working with things like VirtualAllocEx, because the functions weren't there.
- And a lot of the quirks of the GUI commands, confused me and caused problems, but when I actually started to take a look under the bonnet (hood), it all made a lot more sense and became easier.
- The dilemma for me, whenever I want to do anything GUI, is, which route, GUI commands or custom functions?
- Invariably I need custom GUI functions anyway, but dealing with GUI commands can often get clunky, and I double up the work.
- If I take the custom-functions-only route, that's fine, but for some reason, up till now, it seems nobody else has shared any serious 'GUI from scratch via DllCall' examples. Every time I hit a slight obstacle trying to recreate some of the GUI commands, no-one's there to help, because the GUI commands already perform that function.
- Surely I can't have been the only one having these thoughts.
- Anyway, I feel that I've done 95% of the work, and with a few pointers my GUI command replacement scheme can be completed (e.g. full Basic/32/64-bit support).
- I did find majkinetor's custom MsgBox, the one time I got lucky in this quest, and for anyone who doesn't know how GUI works behind the scenes, it's basically: RegisterClass and CreateWindowEx. Then you handle messages in a message queue and make use of WndProcs.
- AutoHotkey as a community should consider GUI via custom-made functions, rather than the AutoHotkey GUI commands, as a standard way of producing GUI, even the preferred way, in a similar way to Gdip.ahk and Acc.ahk being key parts of AutoHotkey.
- Welcome to the new golden age of AutoHotkey.