GuiCtrlGet*

[WeaponX]

We can set these options but how do we get them?

GUICtrlSetBkColor -> GUICtrlGetBkColor
GUICtrlSetColor -> GUICtrlGetColor
GUICtrlSetCursor -> GUICtrlGetCursor
GUICtrlSetFont -> GUICtrlGetFont

GUICtrlSetPos -> GUICtrlGetPos (same as ControlGetPos?)

[Valik]

Do we really want to provide these? It seems like something simple for somebody to implement but is it really necessary?

[Jpm]

My point of view is the user has to memorized what he did instead of asking what he has done.
So for me it is not necessary

[Valik]

Good enough answer for me. Closing as rejected.

[TimRude]

I know this suggestion was rejected long ago, but please consider this as possibly a valid reason for needing GUICtrlGet... (and GUIGet...) functions:

Suppose you're writing a UDF that will be used as an #include function. As such you don't know what settings the user may have specified for BkColor, Color, Cursor, or Font while defining their GUI and its controls, and the functionality of your UDF may depend on knowing these settings.

For example, consider a function that converts an .ico or .png into a bitmap for loading into a Pic control. Your function needs to know the BkColor of the GUI in order to know what to do with the transparent parts of the image. And it needs to know it before the GUI is shown (i.e. before querying the DC is useful). Without a GetBkColor function, you're stuck with having to make the user pass the BkColor as a parameter to your UDF.

But maybe the user didn't set a specific BkColor for their GUI or controls. In that case the user would have figure out how to do something like _WinAPI_GetSysColor($COLOR_BTNFACE) to determine what the default BkColor is to then pass it to the UDF. Wouldn't it be better if the UDF could just use a GetBkColor call to find this info on its own?