Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

GUI ideas


  • Please log in to reply
191 replies to this topic
Rajat
  • Members
  • 1904 posts
  • Last active: Jul 17 2015 07:45 AM
  • Joined: 28 Mar 2004
GUI is under implementation. the way Chris sees it, it'll be easier to implement for simpler forms compared to other options.

In his words:

the window would be sized automatically according to the specified sizes of the controls. And the controls would be laid out vertically or horizontally according to the order in which you add them.


and for complex GUI creation, a script written in ahk that'd make it as easy as point and click, is planned. a very nice tool made by CyberSlug entirely in au3 does the same for au3 scripts. in case someone would like to check it out, its at http://students.cec.... ... _0.4.2.zip .. just extract & run main.exe

as this is a big feature and is still on the drawing board, so i've started this post to collect ideas from you folks ... do post your ideas or wishes like whether ahk should automatically create form specification based on the controls specified by you (ofcourse it'd be customizable)... or should the complete control be left in the hands of user, just like other tools, with one line of code per control...and any other great ideas.

MIA

CleanNews.in : Bite sized latest news headlines from India with zero bloat


Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Since I'm working on it now, I can tell you some details about how the GUI feature might operate. Suggestions and ideas are always welcome.

It's probably best to illustrate by example:
; By default, MyEdit is both the title of the control and the variable
; to which it will be saved when the form is submitted.  Note that the title
; of a control is invisible for most control types:
gui, add, edit,, MyEdit
gui, add, combo,, MyCombo, choice1,choice2
gui, add, list,, MyList, choice1,choice2
gui, add, button,, OK
gui, show
return

; Because there is an OK button in this GUI, a subroutine named
; ButtonOK (if present) is automatically launched when the button
; is pressed:
ButtonOK:
gui, submit  ; Save all selections and text to their associated variables.
MsgBox You entered the following:`n%MyEdit%`n%MyCombo%`n%MyList%.
return
I'm not 100% sure the above syntax is viable, but an early prototype suggests it's okay.

Finally, I'm planning to release the core features early rather than waiting until a more elaborate set of controls and sub-commands is complete. For example, the tabbed-control (where multiple view are available by clicking on one or more rows of tabs at the top) might be deferred until the next version rather than have it hold up the release of this version.

Candle
  • Members
  • 326 posts
  • Last active: May 17 2010 03:04 PM
  • Joined: 19 Aug 2004
So far it looks good to me Chris . and simple and to the point :)

Rajat
  • Members
  • 1904 posts
  • Last active: Jul 17 2015 07:45 AM
  • Joined: 28 Mar 2004
I think there should be a GuiWaitClose like cmd so that in case somebody uses the close button or Alt+F4 to close the form then the script continues. and that will take care of the 'return' in this case too as otherwise if the scriptor wants to wait till the form is closed then he'll have to end the particular thread.

And also the errorlevel or some other variable should contain the close method after the form ends so that in case one would like to, instead of going to specific section, do this:

IfEqual, GuiCloseMethod, ButtonOK
{
}
IfEqual, GuiCloseMethod, ButtonCancel
{
}
Else
{
}

MIA

CleanNews.in : Bite sized latest news headlines from India with zero bloat


Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

a GuiWaitClose like cmd so that in case somebody uses the close button or Alt+F4 to close the form then the script continues.

The "return" in my example above was for the auto-execute section. If it weren't there, the script would continue executing "behind" the GUI window. In other words, the presence of the window does not affect the regular flow of the script in any way. Only when you click on something in the GUI that has a registered action will a new thread be launched to take care of it (similar to selecting a custom menu item from the tray menu).

if the scriptor wants to wait till the form is closed then he'll have to end the particular thread

Closing the form can also be an event that can have an associated subroutine in the script. For example, if a form has a cancel button, that might be made to call the same subroutine as closing the form by any other means.

I think I'd like to avoid the need to wait for anything. It seems much better to have everything triggered by events, such as closing the form, pressing a button, or selecting an item from a menu. If you still see this as a drawback, perhaps you could describe a short example in which it would be simpler to wait than to have the form actions automatically trigger associated subroutines. Note that it is still possible to have a thread wait for a form to close by using WinWaitClose.

And also the errorlevel or some other variable should contain the close method

I was hoping to avoid that by having each button -- and the closing of the form itself -- associated with a subroutine. For example, if a form has OK and Cancel buttons:
ButtonOK:
gui, submit
... do something with all the variables that have been set
return

GuiClose:  ; This subroutine is launched automatically if the user closes the form.
ButtonCancel:  ; This one is triggered by the Cancel button
gui, close ; But both labels execute the same subroutine.
MsgBox, 4, , You canceled the form.  Would you like to try again?
IfMsgBox, Yes
     gui, show
return
This method also performs better because the script is completely idle while GUI window(s) are on the screen. It is not waiting for anything, instead it awakens and responds whenever the user triggers a registered action in it.

I'd welcome any kind of real-world example for which this concept would be inadequate. It's far better to learn of a shortcoming now that it would be later.

In any case, I'm glad you mentioned it because it got me thinking about whether triggered subroutines will be a complete solution. I'm far from certain they are.

beardboy
  • Members
  • 443 posts
  • Last active: May 27 2017 08:41 AM
  • Joined: 02 Mar 2004
I always like options, and I know that makes it more work for Chris ;). I would like to be able to have x/y and width/height options for each type of control and gui itself. But then would like the flexibility that if those parameters are missing that it would size automaticlly like it was stated. Of course all of the x/y and width/height settings can be done with existing commands like WinMove, Control, etc.

With a static text control it would be nice to be able to use the font options available with Progress command.

I would want the script to continue running after the gui had been created, unlike Msgbox.

thanks,
beardboy

Rajat
  • Members
  • 1904 posts
  • Last active: Jul 17 2015 07:45 AM
  • Joined: 28 Mar 2004
@Chris
your examples have made me think that this'd solve the purpose. right now i don't know any case where the options won't suffice... and yes WinWaitClose will do the job for GUIwaitclose, so that's not reqd.

GuiClose: ; This subroutine is launched automatically if the user closes the form.

user closes the form 'HOW?'... if in every case its launched then it'd make no sense (IMHO), but if u mean it's launched only when form is closed unconventionally (alt+f4 or close button etc.) then it'd do the job.

MIA

CleanNews.in : Bite sized latest news headlines from India with zero bloat


Candle
  • Members
  • 326 posts
  • Last active: May 17 2010 03:04 PM
  • Joined: 19 Aug 2004
Maybe like this ?
Posted Image
#cs - ### Generated by AutoBuilder 0.4 -- do not modify ###
394	271
0100000000000000	
button	$button_1	Button 1	60	50	150	50	0	0	
#ce - ### End of Dump ###

;Script generated by AutoBuilder 0.4


Opt("GUICoordMode", 1)
Opt("GUINotifyMode", 1)
GuiCreate("MyGUI", 392,266,(@DesktopWidth-392)/2, (@DesktopHeight-266)/2 , 0x04CF0000)

$button_1 = GUISetControl("button", "Quit", 60, 50, 150, 50)

GuiShow()

While 1
    sleep(100)
    $msg = GuiMsg(0)
    Select
    Case $msg = -3
        Exit
    Case $msg = 1
        ;;;
    Case $msg = $button_1
    Exit
        ;;;
    EndSelect
WEnd
Exit
Exit when button is clicked and with X is clicked .
This is with autoit and autobuilder

deguix
  • Members
  • 87 posts
  • Last active: Jun 17 2014 05:18 AM
  • Joined: 26 Aug 2004

I would like to be able to have x/y and width/height options for each type of control and gui itself.

I think this really should be required.

Exit when button is clicked and with X is clicked.

I would like that controls had an option to make you know what the user did to them to notify the script of this change. Like for example, when I click with right mouse button on an item of a ListBox, it would generally say that that control was activated and an item was selected, but I wanted to now how the user selected that item. An additional variable should be there for this...

With that you could attach a menu with the listbox with some options for the particular item selected there.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

I would like to be able to have x/y and width/height options for each type of control and gui itself.

Yes, that's what the blank parameter was for in my original example: "gui, add, edit,, MyEdit". That parameter is planned to support x, y, w, and h option letters, and probably quite a few others as well. In addition, if you use something like y+5, the next control would be placed 5 pixels beneath the bottom of the previous control.

With a static text control it would be nice to be able to use the font options available with Progress command.

Yes, I think the AutoIt approach to this is best, whereby a font is set as the new default and all controls from that point forward will use it (if applicable). Example: gui, font, verdana, 12, 400, red (where 400 is the weight). I'll try to get font support into this version unless it is thought better to defer it to the next version (to accelerate this release).

user closes the form 'HOW?'... if in every case its launched then it'd make no sense (IMHO), but if u mean it's launched only when form is closed unconventionally (alt+f4 or close button etc.) then it'd do the job.

I guess there are quite a few ways to close a window:
SC_CLOSE is done by the user, which is either Alt-F4, selecting "close" from the icon menu, or clicking the X button in the title bar.
WinClose (or something similar) is used on the GUI: I was thinking of handling this the same as the above.
Script closes by any means (its OnExit subroutine could do special handling for any GUI windows that still exist).
A button is pressed that does "gui, close". In that case, the button's subroutine can do whatever it needs to.

In light of the above, does anyone see any need to have separate "reason codes" for the closing of the GUI, or are the following enough: 1) Normal Close; 2) Script Close (maybe should bypass the GuiClose subroutine and defer to OnExit)?; 3) Button press or menu item (already fully handled by its subroutine).

when I click with right mouse button on an item of a ListBox, it would generally say that that control was activated and an item was selected, but I wanted to now how the user selected that item. An additional variable should be there for this...

That's a nice idea. I'll see if this can at least be planned as a future feature if it doesn't get into this version.

Thanks for all the feedback.

Edit: fixed typos

Candle
  • Members
  • 326 posts
  • Last active: May 17 2010 03:04 PM
  • Joined: 19 Aug 2004

when I click with right mouse button on an item of a ListBox, it would generally say that that control was activated

That would be nice to have so if you make a editbox or combobox you can have the items as links or run commands so you can do a menu type thing .

Rajat
  • Members
  • 1904 posts
  • Last active: Jul 17 2015 07:45 AM
  • Joined: 28 Mar 2004

In addition, if you use something like y+5, the next control would be placed 5 pixels beneath the bottom of the previous control.


this sounds nice. the y+5 here means the last control's ending y co-ord + 5 ...right?

MIA

CleanNews.in : Bite sized latest news headlines from India with zero bloat


Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
I think by default, some types of controls might have more vertical space between them than others. For example, if a static text control is followed by an edit beneath it, the text is probably a label so should be right above the control. But if you have two edits consecutively, maybe there should be more margin.

I didn't want to spend too much time initially on layout features. For example, the concept of docking a group of controls to the bottom or right sides of a window might be deferred until a later release. So might some kind of dynamic re-positioning that occurs when the user resizes the window.

There is also the question of whether to size the window according to what's in it, or vice versa. By default, the former might be better. Of course, you can specify the size explicitly too.

Also, for control sizing, I was thinking that automatic height would be an option for static text labels. In this example, since a width is specified as w100, the height will be automatically calculated based on how much text there is and how many times it starts a new line (based on wrapping and linefeeds (`n) in the text):

gui, add, text, w100, A sentence long enough to be wrapped.`nWith an explicit new line.

Maybe the above should also be done for buttons and checkboxes.

Rajat
  • Members
  • 1904 posts
  • Last active: Jul 17 2015 07:45 AM
  • Joined: 28 Mar 2004

I didn't want to spend too much time initially on layout features. For example, the concept of docking a group of controls to the bottom or right sides of a window might be deferred until a later release. So might some kind of dynamic re-positioning that occurs when the user resizes the window.


ditto!... automatic sizing etc. IMHO can take a backseat till the totally user controlled gui becomes stable... then u can make the creation easier for newbies.

There is also the question of whether to size the window according to what's in it, or vice versa. By default, the former might be better.

yes. i think so too.

by the way there's just one more thing that might trouble the automatic sizing etc.... XP themes.

MIA

CleanNews.in : Bite sized latest news headlines from India with zero bloat


Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
I think the sizing should automatically handle XP themes because it uses built-in Windows features to measure the text and fonts. But since I'm still using the classic/basic theme, I'll rely on you and anyone else who feels like it to tell me if there are theme/style issues.