AutoHotkey Community

Equal (=), case-sensitive-equal (==), and not-equal (<> or !=). The operators != and <> are identical in function. The == operator behaves identically to = except when either of the inputs is not a number, in which case == is always case sensitive and = is always case insensitive (the method of insensitivity depends on StringCaseSense). By contrast, <> and != obey StringCaseSense.

Parent [v1.1.03+]: Use +Parent immediately followed by the name or number of an existing Gui or the HWND of any window or control to use it as the parent of this window. To convert the Gui back into a top-level window, use -Parent. This option works even after the window is created.

joefiesta wrote:The documentation for +PARENT (found in the GUI topic) says the following:

Parent [v1.1.03+]: Use +Parent immediately followed by the name or number of an existing Gui or the HWND of any window or control to use it as the parent of this window. To convert the Gui back into a top-level window, use -Parent. This option works even after the window is created.

That is all it says. This does not tell me what a PARENT gui is or does.

When the function deems the first parameter to be greater than the second, it should return a positive integer

When the function deems that the first parameter should be placed later in the final/sorted list than the second, it should return a positive integer

nevertheless the command is still available in V2

filecreatedir "a"

The modifiers !+^# affect only the very next key. To send the corresponding modifier key on its own, enclose the key name in braces.

joefiesta wrote:

Code: Select all

Apparently, the sequence in which GUI controls are created is relevant. I can not find this documented anywhere.

Specifically, it appears that when two controls with g-labels are created and they overlap (partially or fully), when clicking a location where they overlap, the G-label of the first created control is triggered.

The only way I have found to make the second created control's G-label to be triggered in this case is by HIDING the first created control (which, of course, is not really what one might want).

Here is a short macro which you can use to test this. This sample is not very practical. In reality, my first control is a PICTURE and the second control is TEXT (which only covers a small portion of the picture and is, therefore, much more logical). I haven't used a picture in the sample for lack of a universal picture file.

Pressing BUTTON 2 has no effect until after Clicking TEXT1 control area (which then HIDES TEXT1).

I also find this interesting in that one has every reason to think that the LAST control created over a certain location has the highest priority.

Code: Select all

#SingleInstance, force
   Gui, 1: Add, text, x001 y000 w300 h400    vText1  gText1,  This is TEXT ONE.
   Gui, 1: Add, button, x101 y105   vMsgTxt gButton2 -background, button two.......
   Gui, 1: Show, x0 y0        , TestGuisOverlapping
   return

Text1:
   msgbox text1 routine
   GuiControl, 1: hide, Text1
   return

Button2:
  msgbox button2 routine
  return

I also find this interesting in that one has every reason to think that the LAST control created over a certain location has the highest priority.

I can not find this documented anywhere.