add new GUI events

[Zedna]

I vote for adding these new GUI events:

$GUI_EVENT_SHOW in case of GUISetState(@SW_SHOW)

$GUI_EVENT_HIDE in case of GUISetState(@SW_HIDE)

$GUI_EVENT_OPEN opposite to $GUI_EVENT_CLOSE

$GUI_EVENT_MOVE in case of changing position

$GUI_EVENT_PRIMARYDOUBLE mouse primary doubleclick

$GUI_EVENT_SECONDARYDOUBLE mouse secondary doubleclick

I have script with tray icon/menu and

one "always on top" toolbox window

which can be in state show/hide.

I'm using:

Opt("GUIOnEventMode",1)

GUISetOnEvent ($GUI_EVENT_PRIMARYDOWN, "functionx" )

Opt("TrayOnEventMode",1)

TrayItemSetOnEvent(-1,"functiony")

Main loop is:

while 1 ... wend

(with some more complicated timing and testing).

These new GUI events in this case may help in doing more advanced finesses.

Thanks

Edited June 20, 2005 by Zedna

[therks]

Most of these I could see, except $GUI_EVENT_OPEN. Where would you use that? You said opposite of $GUI_EVENT_CLOSE, but that's triggered by the [x] button in the corner of the GUI (or by the Esc key possibly). What would trigger $GUI_EVENT_OPEN? Could you provide some pseudo example code?

And just to be a pain, I vote we also add $GUI_EVENT_FOCUS and $GUI_EVENT_UNFOCUS. This could more easily help to create local GUI hotkeys.

Think of it:

GuiCreate('')
GuiSetState()

While 1
$gm = GuiGetMsg()
 If $gm = $GUI_EVENT_FOCUS Then
  HotKeySet('^a', 'SelectAll')
 ElseIf $gm = $GUI_EVENT_UNFOCUS Then
  HotKeySet('^a')
 ElseIf $gm = $GUI_EVENT_CLOSE Then
  ExitLoop
 EndIf
WEnd

I really want an easy way to create local HotKeys. I can't stand this looping to check focus workaround we're currently forced to use. It's just so clunky.

[SlimShady]

Great ideas

[Zedna]

Most of these I could see, except $GUI_EVENT_OPEN. Where would you use that? You said opposite of $GUI_EVENT_CLOSE, but that's triggered by the [x] button in the corner of the GUI (or by the Esc key possibly). What would trigger $GUI_EVENT_OPEN? Could you provide some pseudo example code?

And just to be a pain, I vote we also add $GUI_EVENT_FOCUS and $GUI_EVENT_UNFOCUS. This could more easily help to create local GUI hotkeys.

Think of it:

GuiCreate('')
GuiSetState()

While 1
$gm = GuiGetMsg()
 If $gm = $GUI_EVENT_FOCUS Then
  HotKeySet('^a', 'SelectAll')
 ElseIf $gm = $GUI_EVENT_UNFOCUS Then
  HotKeySet('^a')
 ElseIf $gm = $GUI_EVENT_CLOSE Then
  ExitLoop
 EndIf
WEnd

I really want an easy way to create local HotKeys. I can't stand this looping to check focus workaround we're currently forced to use. It's just so clunky.

<{POST_SNAPBACK}>

$GUI_EVENT_OPEN would be something like constructor

as $GUI_EVENT_CLOSE is something like destructor.

But you are right, $GUI_EVENT_OPEN is not neccesary because

code listed in this event can be written immediately after GuiCreate()

with same effect.

Your tip for events about getting/losing focus

$GUI_EVENT_FOCUS and $GUI_EVENT_UNFOCUS

I think names

$GUI_EVENT_GETFOCUS and $GUI_EVENT_LOSEFOCUS or

$GUI_EVENT_ACTIVATE and $GUI_EVENT_DEACTIVATE

would be better

[layer]

This ideas sound very good to me!

[PerryRaptor]

I vote for the addition of $GUI_EVENT_ACTIVATE and $GUI_EVENT_DEACTIVATE. If you don't like these names may be $GUI_EVENT_ENABLE and $GUI_EVENT_DISABLE.

[Michel Claveau]

I prefer

$GUI_EVENT_SETFOCUS

$GUI_EVENT_REMOVEFOCUS

only for to have the same word than I use in Paradox.

[therks]

How about we take after HTML and use Focus and Blur?

$GUI_EVENT_onfocus

$GUI_EVENT_onblur

In HTML, you can do something like this:

Click in this input box, then click somewhere else on the page.<br>
<input name="status" onfocus="this.value='onfocus Triggered'" onblur="this.value='onblur Triggered'">

Go ahead, save that as file.html and give it a try.

[layer]

i like Saunders idea!!

[SlimShady]

very nice indeed, Saunders

[Zedna]

About focus events: For me sounds best

$GUI_EVENT_GETFOCUS

$GUI_EVENT_LOSEFOCUS

It exactly says what is going on:

losing or getting focus.

These names also have window events in PowerBuilder

EDIT:

We also should keep name convence from previous existing events:

$GUI_EVENT_CLOSE

$GUI_EVENT_MINIMIZE

$GUI_EVENT_RESTORE

$GUI_EVENT_MAXIMIZE

$GUI_EVENT_PRIMARYDOWN

$GUI_EVENT_PRIMARYUP

$GUI_EVENT_SECONDARYDOWN

$GUI_EVENT_SECONDARYUP

$GUI_EVENT_MOUSEMOVE

$GUI_EVENT_RESIZED

See there is no

$GUI_EVENT_ONCLOSE

but

$GUI_EVENT_CLOSE

Because that is not perfect

$GUI_EVENT_onfocus

$GUI_EVENT_onblur

so rather

$GUI_EVENT_FOCUS

$GUI_EVENT_BLUR

Edited June 25, 2005 by Zedna

[Valik]

I think that adding a facility to subscribe to any Windows message would be a better use of time than adding support for more hard-coded events.

[Zedna]

@Valik

Yes but I think it's sure more complicated to implement

such universal solution

than only adding a few hardcoded events which will cover

99% of needs all users...

Edited June 25, 2005 by Zedna

[Valik]

@Valik

Yes but I think it's sure more complicated to implement

such universal solution

than only adding a few hardcoded events which will cover

99% of needs all users...

<{POST_SNAPBACK}>

But subscribing to events at the users discretion will cover 100%.

[Zedna]

Yes

I said Yes

But if authors couldn't implement this universal (more complicated) solution soon

then I vote for simple hardcoded events (maded more quickly)

[therks]

I think that adding a facility to subscribe to any Windows message would be a better use of time than adding support for more hard-coded events.

<{POST_SNAPBACK}>

This intrigues me. Could you demonstrate how this might work with AutoIt code?

[Valik]

This intrigues me. Could you demonstrate how this might work with AutoIt code?

<{POST_SNAPBACK}>

No, because the GUI designers are currently in a KISS mode with the GUI. This would require some additonal method for communicating parameters as part of the message. For example, subscribing to a WM_MOUSEMOVE would require some way to pass the parameters of that message (The x,y coordinates). I want to see a true callback method where the callback function for the event automagically gets passed some parameters, but I'm not sure if thats do-able at this point with AutoIt's internal workings. Also, this might be a bit more complex for new users because of the seemingly magical way things work in a callback system.

[Zedna]

About possibility of subscribe to any Windows message

I found another topic:

GUIGetMsg(1), additional parameter in advanced mode

[Zedna]

I have another topic (in Idea Lab forum) related to this one:

Possibility to handle any windows message

[Zedna]

Please can be added these two GUI events?

$GUI_EVENT_PRIMARYDOUBLE - mouse primary doubleclick

$GUI_EVENT_SECONDARYDOUBLE - mouse secondary doubleclick

It has corresponding windows messages

(WM_LBUTTONDBLCLK, WM_RBUTTONDBLCLK),

so implement this can't be so hard.

I found several workarounds in AutoIt forum,

but there are problems in some circumstances with it

and code is little dirty (less readable) with it.

Thank you

***

I also vote for these two events:

$GUI_EVENT_GETFOCUS

$GUI_EVENT_LOSEFOCUS