Sign in to follow this  
Followers 0
Zedna

add new GUI events

20 posts in this topic

#1 ·  Posted (edited)

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 by Zedna

Share this post


Link to post
Share on other sites



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.

Share this post


Link to post
Share on other sites

Great ideas :)

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

This ideas sound very good to me! :)


FootbaG

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

I prefer

$GUI_EVENT_SETFOCUS

$GUI_EVENT_REMOVEFOCUS

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

i like Saunders idea!! :)


FootbaG

Share this post


Link to post
Share on other sites

very nice indeed, Saunders :)

Share this post


Link to post
Share on other sites

#11 ·  Posted (edited)

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 by Zedna

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

#13 ·  Posted (edited)

@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 by Zedna

Share this post


Link to post
Share on other sites

@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%.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0