GUI Changes Needed

[Jon]

There's quite a lot of new GUI code itching to get into the source but I'm reluctant to add new stuff to the GUI until we can agree how the basic _functions_ should look.

There was talk that the current functions are too complicated, or have to many parameters, and some need -1 for this default and "" for that, etc.

See these threads:

http://www.autoitscript.com/forum/index.ph...wtopic=3665&hl=

http://www.autoitscript.com/forum/index.ph...wtopic=3739&hl=

So, in this thread I want us to agree the basic functions that the GUI should have. Then i/we will change the sources to match the agreement and _then_ we can add the new stuff like bmp buttons and extra controls.

Obviously even any small change will break existing GUI script, but the gui stuff is in beta and change is expected (as long as the change is an improvement )

[jpm]

I agree theat GUIControlEx can be clean I support the Holger proposal GUISetControlProperty which suppress GUIsetControlData/GUIsetControlFont even GuiSetControlNotify

the topic

Another area if the GUIWrite vs GuiSetControlEx/GuiSetControlData/GuiSetControlEx

With GuiSetControlProperty proposal we certainly can remove it

To ease coord handling we can add GUIGetCursorPos

so the GUI functions can be :

• GUICreate ( "title", width, height, [left, top [,style [,exStyle]]] )
• GUICreateEx ( helpfile [,background [,iconfile]] )
• GUIDefaultFont ( size [,weight [,fontname [,attribute]]])
• GUIDelete ( )
• GUIGetControlState ( [controlref] )
• GUIGetCursorPos ( )
• GUIHide ( )
• GUIMsg ( [timeout] )
• GUIRead ( [controlref] )
• GUIRecvMsg ( controlref ,msg [,wParam [,lParamType])
• GUISendMsg ( controlref, msg ,wParam, lParam )
• GUISetControl ( type, "text", left, top [,width [,height [,style [,exStyle]]] )
• GUISetControlProperty ( type, controlref, par1, ... )
• GUISetCoord ( left, top [,width [,height]] )
• GUISetCursor ( [cursorId] )
• GUISetGroup ( )
• GUIShow ( [timeout] )
• GUIWaitClose ( [timeout] )

This proposal can accept the typs "menu" and "menuitem" of Holger

for the type around tray and tree I need to think about but as the GUISetControlProperty can have specific par by type it should notbe a problem.

Edited August 27, 2004 by jpm

[Valik]

I feel the opposite. I feel that more functions are needed just to eliminate confusion on which function works with which control with which parameters. Its both an internal nightmare and a script-writers nightmare having one function do most of the GUI-related work. I say break them down into functions related to an individual control, and if the C++ grunt-work for the two is identical, then write a utility function to do the work and call it from the C++ one.

Examples:

GuiCheckboxRead("ref")
GuiCheckboxWrite("ref", state)
GuiInputRead("ref")
GuiInputWrite("ref", "text", [overwrite])
GuiEditRead("ref")
GuiEditWrite("ref", "text", [overwrite])
; Obviously, these two controls could use the same code, so just add 
; a private function which does the work, then wrap them in public
; functions so they can be exposed.

And I am not a fan at all of going "Function("itemtype", parameters, ...)". That doesn't make sense to me when you could use "FunctionItemType(parameters, ...)". In other words, the object functions act on should be described in the function name, and not taken as a parameter, which means each function "should only do one thing and do it well."

[jpm]

I feel the opposite.

I was thinking in the previous thread you accept the Jon Idea due to size.

If not too much size why not

Up to Jon to decide.

[Holger]

@Valik: but how do you change then i.e. the notify, color, the font, maybe an icon/bitmap, etc. for one control?

That would be soooooo much commands :-O

So I can say for me - I would not like it.

Maybe I didn't understand it right what did you mean.

Could you maybe post an idea-sample with 'before' and 'after' so we could discuss that?

Thanks and regards

Holger

P.S: I have to think of a little bit, maybe this idea is not so bad as I thought......*thinking* GUIEditImage...GUIButtonIcon...GUICheckboxColor...

[Valik]

Calling 4023 functions is a hell of a lot easier than calling 1 function 4023 times with 9832 different combinations of parameters. Thats the point I'm trying to make and what I hope to see. There may be some use for a generic GuiSetControlProperty, but it MUST be generic enough that it works on every control it claims to support in the exact same way, otherwise, we fall back into the trap of what we have currently where some parameters work some ways on some controls but not like that on others.

[Holger]

Ok, that could be right.

So, how could all these functions renamed or how are these must be declared?

Could it be that the performance will be much slower with the changes?

You mean something like:

GUI type option (parameters)

don't you?

i.e.

GUIButtonFont
GUIButtonImage
GUIButtonNotify
GUIButtonRead
GUIButtonResizing
GUIButtonState
GUIButtonText
GUIButtonTip

Don't know if GUI Button Write would needed...

Edited August 27, 2004 by Holger

[Valik]

Something like GuiButtonTip could just be a generic GuiControlTip since it should work the same on all controls.

The key thing to keep in mind is, each function should only do one thing. If it can do that one thing on multiple controls, that's okay, but at the end of the day, if somebody asks you "What does this function do", your answer should be "It does <insert the one and only thing the function is capable of doing>".

[Holger]

Ahhh...yeah...now I checks this ok... I write some down...

[Lazycat]

I some time follow GUISetControlProperty development and I think that a very good way to incapsulate different properties: acts like Opt() function this logical and clean (at least for user). From my side, I even would like to set style and exStyle in this function

So I vote for including Holger mod and basically agree with Jpm function layout.

Just two my coins...

[jeffmikels]

IMHO:

I would like to see the GUI functions "feel" more object oriented with the following basic features:

Functions to construct objects returning handles to those objects.

$guiWindow = GuiWindow( [ parameters ]  )

Object constructors require a handle to a GuiWindow Object

$lblEnterText = GuiLabel($guiWindow, 'Enter some text' , [other parameters ] )
$edEditBox = GuiEdit($guiWindow, 'default text', [ other parameters ] )
$btnOK = GuiButton ($guiWindow, [ button parameters ] )
$edResultBox = GuiEdit($guiWindow,'', [ other parameters] )
; the object parameters could be written in a string similar to html stylesheet
$edEditBox2 = GuiEdit($guiWindow,'Basic Edit','font:Verdana;vscroll:off;hscroll:off')

Generic Function to change object parameters taking an object handle as arguments.

GuiChange($btnOK, [button parameters same as for object creator] )
GuiChange($edEditBox, [edit box parameters same as for object creator] )

Generic function to read the status of an object taking a handle as an argument.

$variable = GuiRead($edEditBox)
; $variable is an array containing the parameters in the same order as the object constructor.
;$variable[0] = parent window handle
;$variable[1] = edit box contents
;$variable[2] = string containing ALL parameters of the same format as the constructor

Return of an event message for every type of event on every object unless object is disabled

$guiMessage = GuiMsg() should return an array like the following:
$guiMessage[0] = event type like one of the following
guiObjectMouseOver
guiObjectMouseOut
guiObjectChange
guiObjectClick
guiWindowClose
guiWindowChange
guiNoEvent

; These should be constants defined in the language as macros or something!

$guiMessage[1] = handle of object or -1 if no event took place

EXAMPLE:

$guiWindow = GuiWindow( [ parameters ]  )
$lblEnterText = GuiLabel('Enter some text' , [other parameters ] )
$edEditBox = GuiEdit('default text', [ other parameters ] )
$edResultBox = GuiEdit($guiWindow,'', [ other parameters] )
$btnOK = GuiButton ( [ button parameters ] )

$guiMessage = GuiMsg()
While $guiMessage[0]  <> @guiWindowClose
If $guiMessage[1] = $btnOK Then doOKEvents($guiMessage[0])
If $guiMessage[1] = $edEditBox Then doEditBoxEvents($guiMessage[0])
$guiMessage = GuiMsg()
Wend

exit

Func doOKEvents($event)
If $event = $guiObjectClick Then
$results = GuiRead($edResultsBox)
MsgBox(4096,'OK button was clicked...',$results[1])

EndIf
EndFunc

Func doEditBoxEvents($event)
if $event = $guiObjectChange Then
$editBoxStats = GuiRead($edEditBox)
GuiChange($edResultsBox,$editBoxStats[1],'fontSize:24')
EndIf
EndFunc

--------------------------------------------

Does this make sense?

Edited August 30, 2004 by jeffmikels

[Josbe]

I some time follow GUISetControlProperty development and I think that a very good way to incapsulate different properties: acts like Opt() function this logical and clean (at least for user). From my side, I even would like to set style and exStyle in this function

So I vote for including Holger mod and basically agree with Jpm function layout.

Just two my coins...

<{POST_SNAPBACK}>

Me too.

[jpm]

I just submit to Jon a small lexer/parser extension which make the same

GuiSetControl ("label", ...)

and

GuiSetControl.label (...)

So I hope Valik will be glad to have a kind of object oriented form.

I propose too to rationalize the functions apply to the GUI (not the controls) as GUICreateEx, GUIDefaultFont, GUIShow, GUIHide ,GUISetCoord, GUISetCursor and future extension as for managing Trayicon under GUISetProperty

So my complete proposal is

• GUICreate ( "title", width, height, [left, top [,style [,exStyle]]] )
• GUIDelete ( )

• GUISetProperty.Help ( file )
• GUISetProperty.Background ( color )
• GUISetProperty.Icon ( file)
• GUISetProperty.Font ( size [,weight [,fontname [,attribute]]] )
• GUISetProperty.Coord ( left, top [,width [,height]] )
• GUISetProperty.Cursor ( [cursorId] )
• GUISetProperty.State ( flag [,timeout]) ; replace GuiShow, GuiHide can handle trayicon extension

• GUIGetCursorPos ( )

• GUISetGroup ( )

• GUISetControl.TYPE ( "text", left, top [,width [,height [,style [,exStyle]]] )
• GUISetControl ( controlref, "text", left, top [,width [,height [,style [,exStyle]]] )

• GUISetControlProperty.TYPE ( controlref, state [,resizing [,tip [,ext1 [,background]]])
• GUISetControlProperty.font ( controlref, size [,weight [,fontname [,attribute]]])
• GUISetControlProperty.data ( controlref, data [,default] )
• GUISetControlProperty.notify ( controlref [,action] )

• GUIWaitClose ( [timeout] )
• GUIGetMsg ( [timeout] ) ; replace GUIMsg() and GUIMsg (timeout)
• GUIPeekMsg ( ) ; replace GUIMsg(0)

• GUIRead ( [controlref] )
• GUIRecvMsg ( controlref ,msg [,wParam [,lParamType])
• GUISendMsg ( controlref, msg ,wParam, lParam )

Writing this proposal I imagine that we can go a little bit further generalizing the "object oriented" form to have for instance GUISetControlProperty.TYPE.tip( tip value) this extension need to recode the execution part of the function too not just the lexer/parser.

[Jon]

I don't like that at all - I'd rather have them as seperate functions than adding new rules to the lexer and function calls.

I don't actually mind either way: having the function like Holger suggested or lots of seperate functions. Depends what is most popular and supportable.

[jpm]

I don't like that at all - I'd rather have them as seperate functions than adding new rules to the lexer and function calls.

Can you explain why you don't like the "object oriented" form? I was so proud of it.

I don't actually mind either way: having the function like Holger suggested or lots of seperate functions.  Depends what is most popular and supportable.

<{POST_SNAPBACK}>

Do you confirm is not a size problem to have so many functions?

[Jon]

Can you explain why you don't like the "object oriented" form? I was so proud of it.

Do you confirm is not a size problem to have so many functions?

Adding more functions is not really a problem - the new function lookup seems to be working well. And having more functions may actually reduce the amount of code in situation where you have a long list of string comparisons (like ControlCommand which is massive).

[jpm]

Adding more functions is not really a problem - the new function lookup seems to be working well.  And having more functions may actually reduce the amount of code in situation where you have a long list of string comparisons (like ControlCommand which is massive).

<{POST_SNAPBACK}>

Thanks

[jeffmikels]

Just wondering, did anyone have any feedback on my suggestions? Was I just off the wall with them? I've been using a language called plua on my Palm Pilot and have been really impressed with the ease of use its gui functions have.

For AutoIt GUI, I was especially hopeful for a string-based parameter system like that used in HTML CSS.

Thanks again one and all for a great programming language!

Edited August 31, 2004 by jeffmikels

[dooshorama]

since everyone seems to be indifferent about the actual implementation effort, perhaps we should clarify what exactly we are argueing about. ease of use? code ethics? cosmetics? ease of debugging?

on grounds of cosmetics, i agree with Valik. the code will be easier to read.

ease of use, i like the Holger idea, like the current ControlCommand() function. sure, some of the parameters may end up unused, but as far as referencing goes, it's all in 1 place. if i need to know what commands are available, there's 1 command and i can look on 1 page what it can do. with the Valik idea, i would need to remember/reference more commands. as an analogy, if you were in an office, and each person did only 1 thing, you would need to memorize every person's name for each individual task. the phonebook would be huge. where as the Holger idea, there's 1 person you can go to for everything you need (in a particular area). so actualy i prefer calling 1 function 4023 times rather than referencing 4023 functions.

here's my take on the comparison:

[Holger]

+ it's 1 function

+ help reference is located in 1 place

- it looks odd

- empty parameters may be confusing

[Valik]

+ looks/reads better

+ maybe less confusing

- many functions

- each function will have different # of parameters (increases referencing the help file)

- help references are located in different places for different functions

i don't know about code ethics, ease of debugging, or else.

>EDIT< is it possible to implement Holger's idea, but create function aliases to support Valik's idea?

so there would be a CommandDoAll("this") and CommandDoAll("that") and also aliases .. CommandDoThis(), CommandDoThat()? or maybe the other way around?

Edited September 2, 2004 by dooshorama

[Holger]

@dooshorama: we will see if this is possible :-)

At the moment I agree with you cause I have absolutely no plan what the best thing is...

But the thing with "GUISetControlProperty" would a little bit like the thing with more functions, so here is one old example-part of me:

$button = GUISetControl("button","...",15,10,25,25,$BS_ICON)
GUISetControlProperty("notify")
GUISetControlProperty("tip",-1,"this is the default button")
;load image from file with ID 5 to button as small image (0=small,other=large)
GUISetControlProperty("image",-1,"Shell32.dll",5,0)

$bigbutton = GUISetControl("button","...",5,40,32,32,$BS_ICON)
GUISetControlProperty("notify")
GUISetControlProperty("image",-1,"Shell32.dll",28)

$listbox = GUISetControl("list","",50,10,70,100)
GUISetControlProperty("data",-1,"item1|item2|item3|item4","item2")

$url = GUISetControl("label","www.autoitscript.com",130,10,150,20)
;set color to red and backgroundcolor to blue
GUISetControlProperty("color",-1,0xE70000,0xA5C9EF)
;set control font to size 11 and style "underline"
GUISetControlProperty("font",-1,11,-1,"",4)
GUISetControlProperty("notify")
$listbox = GUISetControl("combo","",130,40,70,80)
GUISetControlProperty("data",-1,"item1|item2|item3|item4","item3")

$input = GUISetControl("input","write...",130,70,100,20)
GUISetControlProperty("limit",-1,8)

$inputupdown = GUISetControl("input","5",250,70,40,20)
$updown = GUISetControl("updown",$inputupdown,0,0)
GUISetControlProperty("limit",-1,5,10)

$check = GUISetControl("checkbox","Turbo-Mode",20,100,100,20)
GUISetControlProperty("state",-1,$GUI_CHECKED)
GUISetControlProperty("color",-1,0xB00000)
;set notify mode to submit, also possible (.."notify",-1 / $ctrlid,0 / 1 / 2)
GUISetControlProperty("notify")

You can see it's a lot of lines

Edited September 2, 2004 by Holger