GUIs via DllCall: MsgBox

Post your working scripts, libraries and tools
User avatar
jeeswg
Posts: 1699
Joined: 19 Dec 2016, 01:58
Location: UK

GUIs via DllCall: MsgBox

18 Apr 2017, 00:30

This is a first example in GUIs via DllCall. I also plan to release a DllCall version of my 'control zoo' and a Notepad replacement. I might recreate some of the examples in the AHK documentation, and then more generally, when I want to create a new GUI, or improve one of my existing GUIs, do it via DllCall.

Creating GUIs from scratch is relatively simple. To create a custom class name, e.g. AutoHotkeyGUI, you use RegisterClassEx. To create windows and controls you use CreateWindowEx. To receive information from windows and controls you use a WndProc function, which is very similar to an OnMessage function.

The script is based on a script by majkinetor, which was the first time I saw a GUI made in AutoHotkey, made without the Gui commands, and made using DllCall only.

[EDIT:] Compared to that script, I have tidied up all the code and functions, and made them AHK v1.1 U64/U32 compatible, I have fixed the cursor to have the correct appearance (to not have the 'busy' cursor) when you hover over the MsgBox when it first appears, and I have made the GUI handle the Enter and Esc keys.

[tutorial] Creating windows without GUI commands - Scripts and Functions - AutoHotkey Community
https://autohotkey.com/board/topic/21124-tutorial-creating-windows-without-gui-commands/

Code: [Select all] [Expand] [Download] (GUIs via DllCall MsgBox.ahk)GeSHi © Codebox Plus



Two issues with this script are that:
- it doesn't properly handle more than one MsgBox being open at the same time
- the window doesn't handle the Enter or Esc keys [EDIT: fixed]

To receive keypress messages directed at the Button control, do I need to subclass the control?
[EDIT:] I have since used subclassing. The problem I had was that SetWindowLongPtr appears to work for x64 but not x32. I thought that logically it should work for both x64 and x32. So I've made it use either SetWindowLongPtr or SetWindowLong based on the script's 'bitness'.

[function] Subclass - helper function to subclass control - Scripts and Functions - AutoHotkey Community
https://autohotkey.com/board/topic/23976-function-subclass-helper-function-to-subclass-control/

The issue with multiple GUIs existing at the same time is one I've asked about here also:

An attempt at a script that creates MsgBoxes/InputBoxes for other scripts - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=29293&p=138253#p138253

Cheers.

[EDIT:] I have noticed that if you activate another window, and then re-activate the GUI, the OK button loses the focus.
Last edited by jeeswg on 21 Apr 2017, 22:16, edited 4 times in total.
just me
Posts: 4436
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: GUIs via DllCall: MsgBox

18 Apr 2017, 02:03

Well, I'm somewhat disappointed. No progress since September 2007. The only advantage over simple AHK GUIs is the missing title bar icon. This example doesn't prove that the concept is capable to be used with complex GUIs without severe issues.
User avatar
jeeswg
Posts: 1699
Joined: 19 Dec 2016, 01:58
Location: UK

Re: GUIs via DllCall: MsgBox

18 Apr 2017, 09:19

@just me
I'm quite sympathetic to your viewpoint. I would have liked that other people had worked on creating GUIs from scratch via DllCall, it's made things harder for me, because fundamental GUI issues have never been discussed on the forum.

What are the 'severe issues' that you imagine? Is there anything that the Gui commands can do that can't be done via DllCall in your view?

In the worst-case scenario, a lot of the functions that I'm working on, can be used alongside the Gui command, or can do things that existing AutoHotkey commands can't do.

I think that there were 'severe issues' with the AHK v1 Gui command, it is amazing not having to use it, especially its event handling. You can also specify custom class names, and windows with no icons, as you mentioned, which people have wanted for years.

[EDIT:] Btw this GUIs via DllCall approach could be useful for people who want to translate GUIs from or to other programming languages.
just me
Posts: 4436
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: GUIs via DllCall: MsgBox

19 Apr 2017, 03:39

Hi jeeswg,

you didn't read much about Message Queues and Window Procedures as yet, did you?

In the worst-case scenario, a lot of the functions that I'm working on, can be used alongside the Gui command, or can do things that existing AutoHotkey commands can't do.
If you would search the forums you would find out that a lot of this functions already exist, of course without the JEE_ prefix.


GUI COMMANDS: COMPLETE RETHINK
(12) 'Any script that uses the GUI command anywhere is automatically persistent'
Didn't you notice that your example in this thread wouldn't work if the script wouldn't be #Persistent?
(13) some aspects of GUI commands are quirky like: Gui Submit/AltSubmit, special variables, and special letters (e.g. g-label notifications for listviews)
You should try to implement the event handlers using your non-AHK-GUI concept. Good luck!
User avatar
jeeswg
Posts: 1699
Joined: 19 Dec 2016, 01:58
Location: UK

Re: GUIs via DllCall: MsgBox

19 Apr 2017, 11:41

Message queues and window procedures are fundamental to GUIs, however they have not proved too much of an obstacle so far. I don't mind knowing more about them, but there hasn't been that much that I've needed to know so far.

I feel that I have 95% of the problems fixed, many problems are general and not specific to 'GUIs via DllCall'. Of course, one major problem, and you don't have a working script!

There are quite a lot of GUI functions available now, however, back in 2011 for example, there were far fewer. Unfortunately a lot of people writing functions combine the object and the functions together. This obscures the code, making it harder to understand, also, often I want the raw function combined with *my own* object implementation, or more specifically, I want all windows/controls to use one object implementation, not to each have their own implementation. My approach will be to create raw functions, and let other's create their own object around the functions, or use my object.

[I've added a section 'GUI - WINDOWS / CONTROLS (LIBRARIES)' to:]
best utilities + best AutoHotkey scripts (+ useful tips) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=7&t=28149

==================================================

I made the script #Persistent, but I would like to be able to make a script temporarily #Persistent like AutoHotkey's MsgBox/InputBox commands.

This little hack for temporary persistence didn't work unfortunately, it just made the script permanently persistent:

Code: [Select all] [Download] GeSHi © Codebox Plus

Hotkey, q, MyLabel
ToolTip, HELLO
Sleep 3000
Hotkey, q, Off ;script does not close at this point, but remains open
MyLabel:

#Persistent
https://autohotkey.com/docs/commands/_Persistent.htm
hotkeys, hotstrings, or any use of OnMessage() or Gui

The idea for the 'temporary persistence' hack, which didn't work, was that the presence of a hotkey in the script, makes a script Persistent, so perhaps 1 hotkey (or more) = persistent, turn hotkeys off and 0 hotkeys = not persistent.

My 0-hotkey script started off non-persistent, I defined 1 hotkey, which made the script persistent, even after I turned off the hotkey.

==================================================

I don't personally want a direct equivalent to AutoHotkey's Submit/AltSubmit and special variable-associated-with-a-control approach, or 'A_' variables, I would just specify the hWnds and grab the text. I plan to handle events on a case-by-case basis using WndProcs for the controls.

Now that I've fixed the subclassing issue, I'm feeling fairly optimistic about 'GUIs via DllCall'. It appears that it's all doable, although some of it may be fiddly, but then, it's fiddly even if you do it via the Gui commands. Overall though, I feel it's much easier to use one approach: DllCall, rather than two approaches at the same time: the Gui command and extras via DllCall.

Thanks for your response.
Last edited by jeeswg on 19 Apr 2017, 12:40, edited 3 times in total.
Helgef
Posts: 1894
Joined: 17 Jul 2016, 01:02
Contact:

Re: GUIs via DllCall: MsgBox

19 Apr 2017, 11:53

Interesting code, it also gives a hint about the amount of time ahk saves us with its gui features. Regarding temporary persistence, although its a funny expression, I get what you mean, I think :wave: . How about a winwaitclose wait for the msgbox?
Cheers.
User avatar
jeeswg
Posts: 1699
Joined: 19 Dec 2016, 01:58
Location: UK

Re: GUIs via DllCall: MsgBox

19 Apr 2017, 12:32

I'm close to finishing a DllCall version of my 'control zoo'. Creating an equivalent has made it clear to me how the Gui command is good at making the right assumptions about how you want a control to appear (style, extended style, size, position), thus reducing say 10 lines of code to 1.

My JEE_RegisterClassExCFI command works on a similar basis to this, making certain assumptions for you. I had thought that I could make an alternative to JEE_DCCreateWindowEx, based on 'Gui, Add', that makes more assumptions, but that allows customisation in the same way that 'Gui, Add' does.

Anyhow, hopefully it appears fairly easy to create windows/controls in my script, and I much prefer handling events etc via WndProcs than the Gui command way.

That said, AutoHotkey v1 and its Gui commands, might be one of the best attempts ever at a program that makes it easy to create GUIs. I would be interested to hear of any other examples.

Ideally I would like something like 'Persistent, On', 'Persistent, Off'. Thanks for reminding me, I had used WinWaitClose in the past. I would be interested generally in any ideas for achieving 'temporary persistence'.

[Btw @Helgef, 1357 posts, nice number.]
just me
Posts: 4436
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: GUIs via DllCall: MsgBox

20 Apr 2017, 02:53

jeeswg, it's easy to create and show windows via DllCall(). But you might find out that it isn't that easy to provide the flexibility of the Gui command options and - more important - to implement event handling (message processing) which comes near to the implementation for built-in AHK Guis.
User avatar
Drugwash
Posts: 212
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUIs via DllCall: MsgBox

20 Apr 2017, 05:12

@ jeeswg: The concept is interesting, at some point I had thought of using it in SmartGUIXP Creator Mod - or rather a complete rewrite of it - thus eliminating the limit on GUI number creation (max 99) but never got around to working on that and seeing the interest in that old script is next to zero it probably won't see any (major) updates anymore.

I've had an attempt at creating dialog windows from binary templates in myCompiler which was intended to be a crossbreed between a resource editor and the AHK compiler. Only managed to display resources so far, it's still buggy and most of all it only works (almost) correctly with ANSI binaries/resources because I haven't gotten to converting it to use ANSI/Unicode AHK. Pure AHK 1.0 code, because main target is Win98SE, as always. You may check it out at my repository if you think it may be of any help.
User avatar
jeeswg
Posts: 1699
Joined: 19 Dec 2016, 01:58
Location: UK

Re: GUIs via DllCall: MsgBox

04 Aug 2017, 13:52

While checking the help file for all references to #Persistent/persistent/persistence, I found what may be a way to achieve 'temporary persistence':

Code: [Select all] [Download] GeSHi © Codebox Plus

BlockInput, MouseMove ;this line begins 'temporary persistence'
BlockInput, MouseMoveOff
ToolTip hello
Sleep 3000
Suspend ;this line ends 'temporary persistence'
Suspend, Off


And one method that in theory would work, but appeared not to:
(although it does seem to introduce 'permanent persistence', where a script was previously not persistent)

Code: [Select all] [Download] GeSHi © Codebox Plus

;doesn't work:
Input, vDummy, T0.001 ;this line begins 'temporary persistence'
ToolTip hello
Sleep 3000
Suspend ;this line ends 'temporary persistence'
Suspend, Off
gwarble
Posts: 194
Joined: 30 Sep 2013, 15:01

Re: GUIs via DllCall: MsgBox

04 Aug 2017, 15:41

Thanks for sharing...

I have a need to create windows of different class names for EitherMouse... basically I want to add the system window shadow attribute to my normal gui windows (done successfully with ShadowEnabled := DllCall("SetClassLong", "uint", WinExist(), "int", -26, "int", DllCall("GetClassLong", "uint", WinExist(), "int", -26) | 0x20000 | 0x0800)) but then I want to create other windows (temporary cursors) without that shadow, so I think they need to be created with a different class than AutoHotkeyGUI which can't be done with gui commands. Is this the proper solution for this?
EitherMouse - Multiple mice, individual settings . . . . www.EitherMouse.com . . . . forum . . . .
User avatar
jeeswg
Posts: 1699
Joined: 19 Dec 2016, 01:58
Location: UK

Re: GUIs via DllCall: MsgBox

05 Aug 2017, 02:29

It seems that you're trying to change the default window style (GCL_STYLE := -26) for a class.

Did you try changing the default window style for the AutoHotkeyGUI class, as appropriate, each time (just before) you created a window (with the Gui command)? Does WinSetStyle work to change the style after the window has been created?

If you can use more than one script, then you can edit the class name 'AutoHotkeyGUI' in the exe file, and have two classes that way. That would change the GUI class name.

If you only want a finite number of windows, it may be possible to create some windows using the 'AutoHotkeyGUI' class, and then change the class name in the address space, and create more windows using a different class name. (In my tests I was able to change the class once but only once, it may be simpler or more complicated than this.)

But in general, to create a GUI with any class name, this is the basis of the approach, to create the GUI via DllCall using CreateWindowEx and RegisterClassEx. There are some other examples in the forums e.g. for ToolTips using DllCall, just search for CreateWindow or CreateWindowEx.

If this information doesn't solve your problem, then you should consider starting a new thread in Ask For Help. Best of luck.

Return to “Scripts and Functions”

Who is online

Users browsing this forum: No registered users and 25 guests