How can i separate koda and custom gui on my script...

[Aktonius]

I added tons of items in groupctrls and they are all part of arrays, if i import this gui in koda it will simply mess up everything and change those items into non-array items which will then completely mess up my code algorythm.

So what i want to achieve is simply have ability to update everything in my gui trough koda except those specific controls which need special array algo to work.

Usually i solved this problem before with more simple things like statusbargui that i would add outside of koda region, its pretty simple. But this cant work like that because it needs to be part of region because its all in a tab that must be nested in a part of koda gui

Edited June 2, 2011 by Aktonius

[BrewManNH]

Learn to do it without Koda would be the best advice I could give you for this problem. While it's a great tool when you're learning to create GUI's it has limitations as you're finding out. Once you learn the basics of GUI's and item placement, you'll probably find you're using Koda a lot less. I haven't used Koda since about the 3 month mark once I dove in and tried to see what it was making for me.

It's a lot easier to move controls around in the Koda GUI than trying to figure it out for yourself, but the effort will pay off in the long run when you do it for yourself.

[martin]

Learn to do it without Koda would be the best advice I could give you for this problem. While it's a great tool when you're learning to create GUI's it has limitations as you're finding out. Once you learn the basics of GUI's and item placement, you'll probably find you're using Koda a lot less. I haven't used Koda since about the 3 month mark once I dove in and tried to see what it was making for me.

It's a lot easier to move controls around in the Koda GUI than trying to figure it out for yourself, but the effort will pay off in the long run when you do it for yourself.

I don't take the same view. I have been using Koda for some time (years?) although not regularly. My experience is that it is better to find ways round problems in Koda so that you can still use it because it makes gui design and development so much easier. I would expect that given any design for a gui that needs a reasonably complex design I could produce a result in less than half th etime BrewMan can without it, and in a years time when I want to change it I could do it in one tenth the time.

If you have a group of controls that need to be arrays then I know this is a limitation with Koda but there are ways round it but it may be what I think is a reasonable approach someone else might not.

This is one way I deal with arrays of controls. Suppose you have an array of buttons.

In koda set the buttons in position. It's much easier to do this in Koda than otherwise. Give the buttons names like BtnArrayA1, BtnArrayA2 and so on.

Produce the AutoIt code or update your script.

In you code outside of the gui creation but after it, do something like

#endregion ### END Koda GUI section ###

$aBtns = _AssignToArray("BtArrayA"); just one line (ignoring the func)
;now you have your array of buttons, Koda can update and no problems

$aLabels = _AssignToArray("LabSet"); make the array of labels

And an example which I've tested

expandcollapse popup

#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

#region ### START Koda GUI section ### Form=
$Form2 = GUICreate("Form2", 400, 300)
$Button1 = GUICtrlCreateButton("Button1", 38, 47, 75, 25)
$Button2 = GUICtrlCreateButton("Button2", 172, 56, 75, 25)
$Button3 = GUICtrlCreateButton("Button3", 84, 119, 75, 25)
GUISetState(@SW_SHOW)
#endregion ### END Koda GUI section ###

;create button array
Global $bt = _AssignToArray("Button")

GUICtrlSetData($bt[0], "Rearrange")

Global $DoneMove = False

While 1
    $Msg = GUIGetMsg()

    Switch $Msg
        Case -3
            Exit
        Case $bt[0]
            MsgBox(0, "CLICKED", "Button1", 0, $Form2)
            If Not $DoneMove Then
                _MoveAround()
                GUICtrlSetData($bt[0], "Button1")
            EndIf
            $DoneMove = True
        Case $bt[1]
            MsgBox(0, "CLICKED", "Button2", 0, $Form2)
        Case $bt[2]
            MsgBox(0, "CLICKED", "Button3", 0, $Form2)
    EndSwitch



WEnd

Func _MoveAround()
    ;rearrange the buttons
    $startxy = ControlGetPos($Form2, "", $bt[0])
    For $n = 1 To UBound($bt) - 1
        ControlMove($Form2, "", $bt[$n], $startxy[0], $startxy[1] + $n * 30)
    Next
EndFunc   ;==>_MoveAround


Func _AssignToArray($Group); made up as I write so not tested, just to give the idea
    Local $n, $ss
    Dim $Result[100]
    $n = 1
    ConsoleWrite(Eval("Button1") & @CRLF)
    While 1
        $ss = Eval($Group & $n)
        ConsoleWrite($ss & @CRLF)
        If Not $ss Then ExitLoop
        If UBound($Result) < $n - 1 Then ReDim $Result[$n + 10]

        $Result[$n - 1] = $ss
        $n += 1
    WEnd

    If $n = 0 Then Return SetError(-1, 0, 0)

    ReDim $Result[$n - 1]
    Return $Result

EndFunc   ;==>_AssignToArray

EDIT: Improved with tested example.

Edited June 2, 2011 by martin

[Aktonius]

Martin i solved it somehow simmiliar to you but there is still a small issue, in your example you dont need to nest your array controls while in my example i MUST nest those arrayctrls in a tab that must be part of Koda update region.

I simply placed end of region before i started to create arrays, that means you still need to add gui_show after those arrays and when you update koda gui it creates another gui show on the end of region which on the end creates x2 gui shows for me.

Everytime i update i need to delete Koda's generated gui show but its ok, doesnt really bother me.

[martin]

Martin i solved it somehow simmiliar to you but there is still a small issue, in your example you dont need to nest your array controls while in my example i MUST nest those arrayctrls in a tab that must be part of Koda update region.

I simply placed end of region before i started to create arrays, that means you still need to add gui_show after those arrays and when you update koda gui it creates another gui show on the end of region which on the end creates x2 gui shows for me.

Everytime i update i need to delete Koda's generated gui show but its ok, doesnt really bother me.

I'm glad you found a solution.

I don't understand what you mean by nesting and I don't see why where you have the controls in the Koda design would make any difference to the approach I showed. Can you give a small example?

[SmOke_N]

I don't take the same view. I have been using Koda for some time (years?) although not regularly. My experience is that it is better to find ways round problems in Koda so that you can still use it because it makes gui design and development so much easier. I would expect that given any design for a gui that needs a reasonably complex design I could produce a result in less than half th etime BrewMan can without it, and in a years time when I want to change it I could do it in one tenth the time.

I'll agree that it's a tool that has its place.

But that's where it stops. IMO ( yes, in my opinion ), when working on any type of "real" project, Koda code management is ridiculous.

The time it takes me to work through var name, height, width, styles, etc in Koda. I've already created 2 controls manually, more than that, I've created them in a controlled management scheme.

Edit:

I will say when I am mapping out a GUI, I often throw controls around in Koda just to see how it'd look. But ultimately, I always code it manually.

Edited June 6, 2011 by SmOke_N

[guiguy]

This is a problem I have seen with just about every GUI builder I have used. Even commercial ones costing big $$$.

Here's the cycle:

1) Build a graphic layout using the GUI editor

2) Autogenerate the code for the graphics

3) Add (manually) the custom code required to make the GUI work

4) Recognize the need to update the graphic layout

5) Revise the graphics layout using the GUI editor

6) Autogenerate the code for the revised graphics

7) Get frustrated because the autogeneration messed up the existing code and you have to manually add in the previous custom code in addition to the new custom code.

Isn't there some way to design a GUI builder to make revisions of autogenerated code easier?

Maybe some comment keywords that tell the GUI builder "don't touch this section of code"

And some keyword(s) that mean "don't change this control id / variable name / function name / etc"

For small projects its not a big deal to fix things up manually when revisions are made, but for a large system with 52 different screens and thousands of lines of callback code it's a real killer.

I'm just saying...