[v2.1+] GUI: Cue banner (placeholder)

Propose new features and changes
User avatar
jNizM
Posts: 3183
Joined: 30 Sep 2013, 01:33
Contact:

[v2.1+] GUI: Cue banner (placeholder)

Post by jNizM » 18 Dec 2019, 04:53

Are there plans to integrate EM_SETCUEBANNER and CB_SETCUEBANNER into the Gui objects as Build-In?

Info:
EM_SETCUEBANNER message -> Sets the textual cue, or tip, that is displayed by the edit control to prompt the user for information.
CB_SETCUEBANNER message -> Sets the cue banner text that is displayed for the edit control of a combo box.


Example (it might look like this) in v2:

Code: Select all

MyEdit := Gui.Add("Edit", "x10 y10 w250")
MyEdit.SetCue("Enter Text here...")
; Gui.Add("Edit", "x10 y10 w250").SetCue("Enter Text here...")     ; alternate

MyCombo := Gui.Add("ComboBox", "x10 y10 w250")
MyCombo.SetCue("Enter Text here...")
; Gui.Add("ComboBox", "x10 y10 w250").SetCue("Enter Text here...")     ; alternate


How I use it atm in v1.1 as functions:

Code: Select all

; ===============================================================================================================================
; Message ..................:  EM_SETCUEBANNER
; Minimum supported client .:  Windows Vista
; Minimum supported server .:  Windows Server 2003
; Links ....................:  https://docs.microsoft.com/en-us/windows/win32/controls/em-setcuebanner
; Description ..............:  Sets the textual cue, or tip, that is displayed by the edit control to prompt the user for information.
; Option ...................:  True  -> if the cue banner should show even when the edit control has focus
;                              False -> if the cue banner disappears when the user clicks in the control
; ===============================================================================================================================

EM_SETCUEBANNER(handle, string, option := true)
{
	static ECM_FIRST       := 0x1500 
	static EM_SETCUEBANNER := ECM_FIRST + 1
	if (DllCall("user32\SendMessage", "ptr", handle, "uint", EM_SETCUEBANNER, "int", option, "str", string, "int"))
		return true
	return false
}

; ===============================================================================================================================

Code: Select all

; ===============================================================================================================================
; Message ..................:  CB_SETCUEBANNER
; Minimum supported client .:  Windows Vista
; Minimum supported server .:  Windows Server 2008
; Links ....................:  https://docs.microsoft.com/en-us/windows/win32/controls/cb-setcuebanner
; Description ..............:  Sets the cue banner text that is displayed for the edit control of a combo box.
; ===============================================================================================================================

CB_SETCUEBANNER(handle, string)
{
	static CBM_FIRST       := 0x1700
	static CB_SETCUEBANNER := CBM_FIRST + 3
	if (DllCall("user32\SendMessage", "ptr", handle, "uint", CB_SETCUEBANNER, "int", 0, "str", string, "int"))
		return true
	return false
}

; ===============================================================================================================================
[AHK] v2.0.5 | [WIN] 11 Pro (Version 22H2) | [GitHub] Profile

DRocks
Posts: 565
Joined: 08 May 2018, 10:20

Re: [GUI] Cue banner for edit controls (placeholder)

Post by DRocks » 14 Jan 2020, 08:19

That's an interesting and useful idea in my opinion.
Would be a nice practical thing to see listed in the autocomplete of a "IDE" and the AHK docs too.

For example, ideally, the IDE would know that myEdit. has setCue(), setFont(), setValue(), setSize(), etc.
And the AHK docs would have a explanation of this listed in the GuiControl's page so when we read the docs, we get a inspiration just by seeing the possibility of that option.

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: [GUI] Cue banner for edit controls (placeholder)

Post by lexikos » 28 Jun 2020, 02:04

I moved this to Wish List, since I see no particular reason to prioritize it prior to the v2.0 release.

I think a property would be more appropriate than a method. I would suggest CueText.

As for the initial question, no, I have no plan to implement it. I would have to spend time developing, testing and documenting it, and then subsequently (most likely) never use it myself. It probably hadn't even crossed my mind before I saw this topic. If someone else wants to do all of the work and submit it via GitHub, I may merge it.

I would like to point out that a script can add methods and properties to all GUI controls of a specific type via the corresponding prototype (base) object. A user-defined library could thus be integrated fairly well with the Gui API. Currently it is necessary to create a control of that type and retrieve .base, but in future the control's class should be accessible directly.

AHK_user
Posts: 515
Joined: 04 Dec 2015, 14:52
Location: Belgium

Re: [v2 GUI] Cue banner for edit controls (placeholder)

Post by AHK_user » 26 Oct 2021, 12:30

@jNizM Interesting code :think: .
I have added it to a proposal for the Custom Gui Extension.

This post explains how to add the method to the edit and combobox.

viewtopic.php?f=83&t=86124&p=426941#p426941

I have`t figured out how to set it by the property, this would be indeed better.

User avatar
jNizM
Posts: 3183
Joined: 30 Sep 2013, 01:33
Contact:

Re: [v2.1] GUI: Cue banner (placeholder)

Post by jNizM » 22 Nov 2022, 04:21

renovation / resumption for v2.1
[AHK] v2.0.5 | [WIN] 11 Pro (Version 22H2) | [GitHub] Profile

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: [v2.1] GUI: Cue banner (placeholder)

Post by lexikos » 22 Nov 2022, 05:41

jNizM wrote:
22 Nov 2022, 04:21
renovation / resumption for v2.1
What does that mean?

Why v2.1? It's hardly interesting or useful enough that you couldn't wait until v2.2.

It's also trivial enough that it could be someone's first foray into contributing to the C++ side of AutoHotkey.

User avatar
jNizM
Posts: 3183
Joined: 30 Sep 2013, 01:33
Contact:

Re: [v2.1] GUI: Cue banner (placeholder)

Post by jNizM » 22 Nov 2022, 05:58

What does that mean?
Was translated with Deepl. Haven't found the right word for it in English. In german I call it "Erneuerung / Wiederaufnahme eines Wunsches"

Why v2.1? It's hardly interesting or useful enough that you couldn't wait until v2.2.
I thought because of this: ... so new features will be developed in a v2.1-alpha branch or later...
But I can change it to v2.1+

It's also trivial enough that it could be someone's first foray into contributing to the C++ side of AutoHotkey.
Outside of AHK and Powershell, I haven't had much exposure to other languages. Maybe one or the other with some basic C++ knowledge can do it.
If I were able to speak the language, I would have contributed one or the other long ago. I can read most of it, but that's it.
[AHK] v2.0.5 | [WIN] 11 Pro (Version 22H2) | [GitHub] Profile

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: [v2.1+] GUI: Cue banner (placeholder)

Post by lexikos » 23 Nov 2022, 02:40

Just assume it will be implemented or not, in whatever version is next at the time. Like every other wish that hasn't been implemented yet. I personally have no plan to work on any Gui features for v2.1, but may accept contributions.

AutoHotkey has too few developers (usually 1, sometimes 0) because every user thinks "maybe someone with more C++ experience will do it" or "I don't know C++". No one has experience at the beginning. You get experience by doing things, which won't happen if you never try. If you don't want to try to learn sufficient C++ to implement this trivial feature (which can be basically translated from your existing code), that is because you don't want the feature enough.

I learned C++ by modifying AutoHotkey. I had no C++ experience prior to that, aside from reading a few tutorials some time before. I didn't even really understand C++ pointers until after learning to deal with structs in AutoHotkey scripts.

[Moderator's note: I've split a discussion initiated from this post into Contributing etc.]

iPhilip
Posts: 796
Joined: 02 Oct 2013, 12:21

Re: [v2.1+] GUI: Cue banner (placeholder)

Post by iPhilip » 26 Nov 2022, 04:34

@jNizM, until your wish is granted you might want to take a look at the two classes I posted here.
Windows 10 Pro (64 bit) - AutoHotkey v2.0+ (Unicode 64-bit)

neogna2
Posts: 586
Joined: 15 Sep 2016, 15:44

Re: [v2.1+] GUI: Cue banner (placeholder)

Post by neogna2 » 26 Nov 2022, 09:39

I looked at v2 code for some existing GUI properties. Here's all of BackColor I think
https://github.com/Lexikos/AutoHotkey_L/blob/alpha/source/script_gui.cpp#L256

Code: Select all

	md_property		(GuiType, BackColor, Variant),
https://github.com/Lexikos/AutoHotkey_L/blob/alpha/source/script_gui.cpp#L428

Code: Select all

FResult GuiType::get_BackColor(ResultToken &aResultToken)
{
	GUI_MUST_HAVE_HWND;
	if (mBackgroundColorWin == CLR_DEFAULT)
		return OK; // "" is the default return value.
	_sntprintf(_f_retval_buf, _f_retval_buf_size, _T("%06X"), bgr_to_rgb(mBackgroundColorWin));
	aResultToken.SetValue(_f_retval_buf);
	return OK;
}


FResult GuiType::set_BackColor(ExprTokenType &aValue)
{
	GUI_MUST_HAVE_HWND;
	
	COLORREF new_color;
	if (!ColorToBGR(aValue, new_color))
		return FValueError(ERR_INVALID_VALUE);
	
	// AssignColor() takes care of deleting old brush, etc.
	AssignColor(new_color, mBackgroundColorWin, mBackgroundBrushWin);
	
	if (IsWindowVisible(mHwnd))
		// Force the window to repaint so that colors take effect immediately.
		// UpdateWindow() isn't enough sometimes/always, so do something more aggressive:
		InvalidateRect(mHwnd, NULL, TRUE);
	
	return OK;
}
and this
https://github.com/Lexikos/AutoHotkey_L/blob/alpha/source/script.h#L2206

User avatar
kczx3
Posts: 1640
Joined: 06 Oct 2015, 21:39

Re: [v2.1+] GUI: Cue banner (placeholder)

Post by kczx3 » 26 Nov 2022, 11:19

I think it needs to be a method that accepts a Boolean to pass as the wParam to the message

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: [v2.1+] GUI: Cue banner (placeholder)

Post by lexikos » 26 Nov 2022, 16:48

Methods use the md_member macro, defining all parameters, whereas the md_property macros are shortcuts to define a getter/setter with appropriate parameter.

BackColor is a bit of an outlier because it has to accept a variant type rather than string to avoid misinterpreting stringified decimal integers as hexadecimal colour values.

Parameter type names used in the md macros are MdType enum members, which are mapped to C++ types in MdType.h. For instance, md_argtype<MdType::String>::t is StrArg for input parameters and md_outtype<MdType::String>::t is StrRet& for output/retval parameters. If the md macro doesn't match the method's actual signature, the macro is designed to cause a compiler error.

I've split neogna2's more general post into Contributing etc.

Post Reply

Return to “Wish List”