GUI Changes Needed

[Valik]

In addition to that lot I was pondering a new notify option that instead of sending a message code causes GetMsg to execute a specifed function - like the functions in VB that can be attached to buttons and things.  Should be easy enough, but that's just a pondering.

Jon, I don't know how feasible this idea is, but something like this could be one way of doing this

$control = GuiCreateControlOfSomeType()
; $control is a handle, basically
GuiSetCallback($control, "MyCallback")

Func MyCallback()
; Do Stuff
EndFunc

Maybe add some @Macros like @Param1 - @Param32 or something for having a clean way to get special parameters passed along which could be helpful in some cases (For example, was a control single clicked or double clicked?). Maybe @Paramn would have some use with Call and HotKeySet, too (@Param1 = key, @Param2 = mod1, @Param3 = mod2, et cetera).

Just some thoughts.

[Jon]

Jon, I don't know how feasible this idea is, but something like this could be one way of doing this

$control = GuiCreateControlOfSomeType()
; $control is a handle, basically
GuiSetCallback($control, "MyCallback")

Func MyCallback()
; Do Stuff
EndFunc

Maybe add some @Macros like @Param1 - @Param32 or something for having a clean way to get special parameters passed along which could be helpful in some cases (For example, was a control single clicked or double clicked?).  Maybe @Paramn would have some use with Call and HotKeySet, too (@Param1 = key, @Param2 = mod1, @Param3 = mod2, et cetera).

Just some thoughts.

That's pretty much what I was thinking. It would be easy to add the variant type into the internal GUI code and a string or number or array message could be returned to GuiMsg() which could then decide if it's a "normal" message for the message pump or if it should "call" another function. It's all doable.

[jpm]

to @Valik and @ Jon

I like the callback approach

Jon do you take care of it?

[Jon]

This is looking pretty cool I must say. I like the way you've handled menu creation that is the pretty much same for app, tray and context menus. Very nifty.

I'm implementing it now, but the changes I am making are:

- In the CreateBlankIcon function you can get rid of all that code with a couple of memset() functions

- Removing the blocking GetMsg modes (all to be merged into a single GetMsg() mode)

- Removing the GuiWaitClose stuff

- Removing the whole "timeout" thing, it's always bugged me, and now there is no blocking mode it can be done with normal TimerInit()

Edited September 22, 2004 by Jon

[SlimShady]

Thank you very mucho, Jon!

[CyberSlug]

Just wondering: Are debug features planned for the next release?

[jpm]

This is looking pretty cool I must say.  I like the way you've handled menu creation that is the pretty much same for app, tray and context menus.  Very nifty.

I'm implementing it now, but the changes I am making are:

- In the CreateBlankIcon function you can get rid of all that code with a couple of memset() functions

- Removing the blocking GetMsg modes (all to be merged into a single GetMsg() mode)

- Removing the GuiWaitClose stuff

- Removing the whole "timeout" thing, it's always bugged me, and now there is no blocking mode it can be done with normal TimerInit()

<{POST_SNAPBACK}>

Thanks Jon, That's why we need you

[Jon]

Just wondering:  Are debug features planned for the next release?

Nutster is looking at it but not seen him in a while so must be busy job hunting.

I'm not - and never have been - that bothered about the debug stuff, it is only going to mess up my neat source code anyway. If it happens, it happens, but it's not a priority for me.

[Jon]

I've uploaded a first stab at the gui changes into the unstable directory. I've also uploaded a guiexamples.zip file with a few of the examples that JP uses to show usage. I'll update the zip file with more as I convert them into new stylee.

[SlimShady]

I'm playing with jpm's test version...

I wanted to try out the GUICtrlCreateTreeView control, but the example doesn't work.

Just wanted to let you know...

[Valik]

I've uploaded a first stab at the gui changes into the unstable directory.  I've also uploaded a guiexamples.zip file with a few of the examples that JP uses to show usage.  I'll update the zip file with more as I convert them into new stylee.

<{POST_SNAPBACK}>

Awesome. I hate to see how much work this is going to be (I have quite a few GUI scripts to update) but I liked how the new layout looked, so this should hopefully be much easier to use.

[CyberSlug]

I guess it's time for me to look at writing some gui conversion scripts

[Jon]

I guess it's time for me to look at writing some gui conversion scripts

I've just been updating examples and I must say I'm prefering it so far. Not having to remember which GUiMsg mode to use is nice. Could be tricky to convert though.

The only thing I'm still not decided on is whether or not to force the default notify mode to "notify" rather than "close", as for any gui with more than one button you are probably want to know when it is clicked and react to that rather than letting the Gui close and then working out afterwards why it closed. Hmmm. Don't know.

[Valik]

I vote do away with the mode altogether. Since you're already forced into using a message loop to handle messages, if you want a button to close it, then it's not like it requires a lot of effort to have:

If $msg = $myExit Then Quit()

[Josbe]

Wow! Thanks, GUI Devs.!

The new improvements are great...more functions, but cool!

Great work!

Now, it's time to conversion...

PS->(Helpfile): I noticed that 'GUIPeekMsg' it's undocumented...

[jpm]

@jon do you intend to upload the installation setup in instable

[Jon]

I vote do away with the mode altogether.  Since you're already forced into using a message loop to handle messages, if you want a button to close it, then it's not like it requires a lot of effort to have:

If $msg = $myExit Then Quit()

I initially thought that this was a bad idea as if you had a simple gui with 10 buttons and you wanted any of them to close the gui it would involve more code in the messageloop part. But then I realized that even if the notify/close mode made it easier to do the message loop you would _still_ have to do a Guiread() afterwards to work out which button was pressed and then you would have to have a big if/select statement anyway.

So yeah, unless anyone can think of a reason to keep the notify mode then I'll remove it.

[Jon]

Wow! Thanks, GUI Devs.!

The new improvements are great...more functions, but cool!

Great work!

Now, it's time to conversion...

PS->(Helpfile): I noticed that 'GUIPeekMsg' it's undocumented... 

It doesn't exist anymore. Just GUIGetMsg().

[Jon]

@jon do you intend to upload the installation setup  in instable

I wasn't home last night, so didn't have broadband. Should be able to upload an installer tonight with any changes we do today.

[jpm]

I wasn't home last night, so didn't have broadband.  Should be able to upload an installer tonight with any changes we do today.

<{POST_SNAPBACK}>

THanks Have a good working day ...