|
11 | Koda | Application | Feature Request | Low | Remove ClientWidth/ClientHeight | Assigned | Admin | 13.11.2008 |
Task Description
Remove ClientWidth/ClientHeight for the Form (Make Width=ClientWidth etc)
|
|
259 | Koda | Application | Bug Report | Low | proped_treeview_editor.png: update from Item to Node | Unconfirmed | Chris Haslam | 08.05.2011 |
Task Description
Please
|
|
133 | Koda | Application | Bug Report | Low | Problems with Toolbar Configuration | Assigned | Spence | 29.06.2010 |
Task Description
Version 1.7.2.8
Customize Add “NewPage” or “NewButton” to a Toolbar (e.g. Standard Toolbar or User Toolbar n” will not show the Icons
with showing User Toolbar3**
User Toolbar 1 is configure well
User Toolbar 2 is not configure
User Toolbar 3 is configure
“Apply” Button
Result: User Toolbar 1 is shown, User Toolbar 3 is not shown!
a1.
User Toolbar 1 is configure well
User Toolbar 2 is not configure
User Toolbar 3 is configure
After “Apply” Button
User Toolbar 2 is setting up
“Apply” Button
Result: All Toolbars will shown
b.
User Toolbar 1 is configure well
User Toolbar 2 is configure well
User Toolbar 3 is configure
“Apply” Button
Result: User Toolbar 3 will not be shown!
|
|
257 | Koda | Documentation | Regular Task | Low | Problem updating menu_align.png | Unconfirmed | Chris Haslam | 11.05.2011 |
Task Description
menu_align.png had Horizontal rather than Horizontally. etc.
I uploaded an updated version, but the old version still shows.
New version is attached.
|
|
216 | Koda | Application | Bug Report | Low | Picture Editor: some observations | Unconfirmed | Chris Haslam | 04.05.2011 |
Task Description
See the doc for the way I understand it.
The Load | File Open dialog filter only offers .jpg, .jpeg, .bmp and .gif.
Via Load, I moused to, and selected, D:\WINDOWS\system32\setup.bmp. This appeared in Custom path to image, and the .bmp appeared in Selected image.
I then changed the path to @SystemDir\setup.bmp. Select image cleared. A bug?
In the course of this, I discovered that there is only one level of Undo here.
Thoughts
@ScriptDir should be permitted in Custom path to image. This would be helpful to a user who puts his .bmps, etc. in the same tree as his script. As Run (F9) is now, running the form would show a blank picture. Perhaps Koda could instead temporarily create a picture containing the file spec. Or one saying “File not available to Koda”. Being able to use @ScriptDir is hugely important to me!
Perhaps a filename and ext should be generated by Koda as @ScriptDir\fnam.ext
Some of these thoughts come from consideration of updating a form in a .au3. I would rather not have to change the file spec whenever I update the script.
Having only one input field for the file spec is not user-unfriendly for people like me who make mistakes! I suggest Custom path to image be replaced the fields in the screen shot attached.
|
|
297 | Koda | Application | Bug Report | Low | Pic Properties | Picture | Assigned | Chris Haslam | 16.06.2011 |
Task Description
Properties | Picture always seems to show None even when a .bmp is loaded and appears in the Design Area.
|
|
202 | Koda | Application | Feature Request | Low | Overcoming MS's confusion in styles for forms | Assigned | Chris Haslam | 05.05.2011 |
Task Description
MS‘s mess (discussed previously) is driving me nuts!
So for Styles of TAForm I suggest that you add some pseudo-styles. Some I think of: Title bar, Close box, Minimize box, Normal frame, Dialog frame, perhaps Modal.
There are two ways you could add them:
Put them in the Styles tab, at the top of the list, or
Put a Clearer styles for Form checkbox in Options | Designer. When it is checked, have Koda replace all the WS styles which are equivalent to pseudo-styles.
You have more experience than I do with these bloody styles. Perhaps there is no way to get around MS‘s confusion!
There is another way: document the translation from pseudo-styles to WS_ constants in Controls | Form. For that I would need your help.
|
|
201 | Koda | Documentation | Bug Report | Low | Options | Options | Windows: which windows? | Unconfirmed | Chris Haslam | 05.05.2011 |
Task Description
Are the Windows here all the windows in Koda, i.e. Object Treeview, Object Inspector, Form List, and forms?
I have not figured out what the following checkboxes really do:
I have looked at the doc as I received it. It doesn’t help.
BTW the screen shot here is obsolete: we need a new one. Please supply.
BTW “Always full expand” should be “Always fully expand”
|
|
246 | Koda | Application | Regular Task | Low | Options | Options | General | Recent Files 2 | Unconfirmed | Chris Haslam | 06.05.2011 |
Task Description
I notice that the caption in 1.7.3.1 is Number of recent file list. This does not make sense to me. It makes it look like recent file list has an ID number (or something).
I wrote:
I suggest that the caption be changed to Recent files in File menu. This is consistent with Undo levels. I also think that it is clearer.
Other wordings are possible.
Number of is redundant: the input box shows numbers.
|
|
194 | Koda | Application | Bug Report | Low | Options | Options | General | Recent files | Unconfirmed | Chris Haslam | 12.05.2011 |
Task Description
I suggest that the caption be changed to Recent files in File menu. This is consistent with Undo levels. I also think that it is clearer.
|
|
187 | Koda | Application | Feature Request | Low | OnClick => Notify ? | Assigned | Chris Haslam | 05.05.2011 |
Task Description
I don’t see why OnClick brings up a dialog.
It only has two values: Notify and don’t notify.
It seems to me that it would be more obvious if it were called Notify and its values were True and False. It would then work like, for example, Enabled.
Just a thought.
|
|
6 | Koda | Application | Feature Request | Low | Not rename form when loading (Form1->Form1_1) | Assigned | Admin | 13.11.2008 |
Task Description
Not rename form when loading (Form1?Form1_1)
|
|
252 | Koda | Application | Bug Report | Low | My first pass through the documentation is now complete | Unconfirmed | Chris Haslam | 06.05.2011 |
Task Description
My first pass through the documentation is now complete, except for issues I have raised in open Bugtracker tasks. I will be proceeding to Pass 2. This will include replacing many #term_definitions with #remarks_headers.
|
|
300 | Koda | Application | Bug Report | Low | Multiple selection of controls within a Group | Unconfirmed | Chris Haslam | 25.06.2011 |
Task Description
I have written in the proposed Help:
To select all controls in an area of the active form, hold the left mouse button down and drag to select an area of the form. All controls wholely within, and partly within, this area are selected.
This often does not work when I try to select several controls in a Group, and is driving me nuts with the Style dialogs.
I suggest that Koda be changed such that:
clicking within a Group in the Design area does not select the Group
a Group can only be selected in the Design Area by clicking on (or near) its border, not on a drag handle.
|
|
191 | Koda | Application | Regular Task | Low | Multiple selection of controls | Unconfirmed | Chris Haslam | 13.03.2011 |
Task Description
Where is this mentioned in the Help? I have not found it.
I find it a little surprising that the user shift-clicks to add a control to the selection.
In Explorer (and elsewhere), control-click adds a file to the selection; shift-click adds a range of files to the selection.
Just a thought.
|
|
277 | Koda | Application | Bug Report | Low | Menutitem: Object Inspector shows styles and exstyles f... | Unconfirmed | Chris Haslam | 10.06.2011 |
Task Description
...chris
|
|
226 | Koda | Application | Bug Report | Low | MenuItem | RadioItem | Unconfirmed | Chris Haslam | 05.05.2011 |
Task Description
Either MenuItem | RadioItem is not working or I don’t understand it. .kxf file, attached, generated:
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#Region ### START Koda GUI section ### Form=F:\Koda forms for PerfectScript\Menu radio test.kxf
$Form1 = GUICreate("Form1", 623, 449, 192, 114)
$mnuFile = GUICtrlCreateMenu("&File")
$mnuOpen = GUICtrlCreateMenuItem("Open", $mnuFile, -1 , 1)
$mnuSave = GUICtrlCreateMenuItem("Save", $mnuFile, -1 , 1)
$MenuItem1 = GUICtrlCreateMenuItem("", $mnuFile)
$mnuExit = GUICtrlCreateMenuItem("Exit", $mnuFile)
$mnuEdit = GUICtrlCreateMenu("&Edit")
$mnuOpts = GUICtrlCreateMenu("&Options")
$mnuHelp = GUICtrlCreateMenu("&Help")
$Label1 = GUICtrlCreateLabel("Label1", 224, 184, 36, 17)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###
While 1
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit
EndSwitch
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#Region ### START Koda GUI section ### Form=F:\Koda forms for PerfectScript\Menu radio test.kxf
$Form1 = GUICreate("Form1", 623, 449, 192, 114)
$mnuFile = GUICtrlCreateMenu("&File")
$mnuOpen = GUICtrlCreateMenuItem("Open", $mnuFile, -1 , 1)
$mnuSave = GUICtrlCreateMenuItem("Save", $mnuFile, -1 , 1)
$MenuItem1 = GUICtrlCreateMenuItem("", $mnuFile)
$mnuExit = GUICtrlCreateMenuItem("Exit", $mnuFile)
$mnuEdit = GUICtrlCreateMenu("&Edit")
$mnuOpts = GUICtrlCreateMenu("&Options")
$mnuHelp = GUICtrlCreateMenu("&Help")
$Label1 = GUICtrlCreateLabel("Label1", 224, 184, 36, 17)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###
While 1
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit
EndSwitch
WEnd |
|
225 | Koda | Application | Feature Request | Low | Menu Designer: OK and Cancel buttons | Researching | Chris Haslam | 05.05.2011 |
Task Description
I am finding that it is very easy to loose the last menu item created. I was testing Creating a menu control.
I suggest that Menu Designer have OK and Cancel buttons. This would be user friendly – allowing a user to back out of a change – and could ensure that the last menu item added does indeed get added to the menu control.
|
|
77 | Koda | Application | Feature Request | Low | Making Code Templates more flexible | Waiting feedback | David | 30.05.2011 |
Task Description
I would like to see additional variables available for the Code
%FORMNAME% - the name of the form as assigned in the form's properties.
The ability to inject code into general event
Func MyGUIClose()
$MyVar="Some Value"
EndFunc
The reason for this request is that most of the time, when I create a GUI, I create it within a function in an include file, with additional control structures. I typically spend 5-10 minutes each time I generate new code using KODA to fit it into my format. I would like to be able to use custom Code Templates to create them already in my format, so I can jump right into the application coding.
|
|
338 | Koda | Application | Bug Report | Medium | Lock controls in designer | Unconfirmed | Henrik | 24.08.2014 |
Task Description
The function “Edit→Control→Lock” works only in the actually reloading the “KXF”-file, the “LOCK” no longer works.
|
|
285 | Koda | Application | Bug Report | Low | Listview styles: some suggestions | Unconfirmed | Chris Haslam | 15.07.2011 |
Task Description
Icon and SmallIcon views are available in AutoIt so LVS_ICON and LVS_SMALLICON should not be disabled. The points below assume the present situation: only List and Report view available. I have added to the doc “At this time, only Report and List views are available in Koda”.
Koda can know that if if there are Columns, the view is Report else it is List. So until Icon and SmallIcon views are added, LVS_LIST and LVS_REPORT could be removed.
With LVS_LIST checked, Koda generated BitOr($ GUI_SS_DEF_LV,LVS_SMALLICON). It so happens that this has the same value as LVS_LIST – but untidy
LVS_COLUMNHEADERS only applies to Report style, so it should be disabled when LVS_LIST is checked
Collection editor: if you enter only one row, no column header is created
LVS_NOSORTHEADER should be removed from OI because it doesn’t work and AutoIt help says that double-click to sort rhas not been implemented.
Multiple selection only works in Report view so LVS_SINGLESEL should be disabled in List view.
Check LVS_SORTASCENDING and then check LVS_SORTDESCENDING: LVS_SORTASCENDING is still checked. Because mask is missing from styles.xml.
LVS_AUTOARRANGE, LVS_ALIGNTOP and LVS_ALIGNLEFT are only intended for Icon and SmallIcon views, so should be removed.
LVS_ALIGNTOP will not uncheck.
|
|
237 | Koda | Application | Bug Report | Low | ListView Properties | Unconfirmed | Chris Haslam | 04.05.2011 |
Task Description
I suggest that Images be called ImageList. Clearer
Alignment
I read the info on Alignment:
According to MSDN, the alignment of the leftmost column is always left-justified; it cannot be changed.
MSDN says in full:
If a column is added to a list-view control with index 0 (the leftmost column), it is always LVCFMT_LEFT. Setting other flags on column 0 does not override that alignment. Therefore if you keep inserting columns with index 0, the text in all columns are left-aligned. If you want the first column to be right-aligned or centered you can make a dummy column, then insert one or more columns with index 1 or higher and specify the alignment you require. Finally delete the dummy column.
The form ran OK. The part of the generated code that does the ListView is here:
$ListView2 = GUICtrlCreateListView("Animal|Coat|Feet", 96, 384, 169, 113)
GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 0, 50)
GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 1, 50)
GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 2, 50)
_GUICtrlListView_JustifyColumn(GUICtrlGetHandle($ListView2), 0, 1)
$ListView2_0 = GUICtrlCreateListViewItem("Lucas|furry|paws", $List
I am wondering whether Koda would be able to do the work-around automatically, rather than the user having to do it manually. Perhaps Koda would need to create a zero-width column 0 so Object Inspector would allow the first column that shows in Collection editor to be right or center justified.
Just a thought.
|
|
308 | Koda | Application | Bug Report | Low | Listbox test form includes GUIListBox.au3 | Assigned | Chris Haslam | 27.06.2011 |
Task Description
Should be ListBox.au3
See attached file
|
|
333 | Koda | Application | Bug Report | Low | label width value is being forgotten | Unconfirmed | Vitas | 22.10.2012 |
Task Description
I have some labels in my program but when I set longer text in them it overflows and line breaks. So I prolonged them in Koda, saved, updated script with CTRL+U and it worked. Unfortunatelly next time after opening the KXF file I found all labels to have width and height reset back to the values set after their creation! Pretty dumb...I think this is a bug I found out it happens not only after reopening the form, but randomly during development when the project is open. The only workaround seems to be to add a lot of spaces to a label’s caption
|
|
272 | Koda | Application | Bug Report | Low | Label styles: some suggested changes | Unconfirmed | Chris Haslam | 15.06.2011 |
Task Description
SS_NOTIFY is shown as checked and forced, even when OnCick has not been specified. But notification can be set/reset in OnClick. So I suggest removing SS_NOTIFY. I wonder whether SS_NOTIFY will work for a Label.
n C/C++, WS_GROUP is the way of marking a control as the first in a group, and another control as the last in the group. But AutoIt uses, and Koda generates, a pair of calls to GUICtrlCreateGroup. So I suggest removing WS_GROUP from TALabel in Object Inspector. The fewer styles there are, the easier it is for a user: some scrolling down is inevitable, but the less he needs to do so the less likely he is to miss a style that he needs to check or uncheck.
Koda shows WS_VISIBLE as forced, but AutoIt doesn’t. Further, WS_VISIBLE remains checked even when Visible is False. I suggest removing WS_VISIBLE.
I think that WS_CHILD only applies to Forms. So I suggest removing it from Object Inspector | TALabel.
|
|
247 | Koda | Application | Bug Report | Low | Koda menu | Help | Content | Unconfirmed | Chris Haslam | 05.05.2011 |
Task Description
The correct English usage is Contents.
|
|
242 | Koda | Application | Feature Request | Low | IP address: Enabled | Assigned | Chris Haslam | 11.05.2011 |
Task Description
I am surprised that there is no Enabled property in Object Inspector
|
|
265 | Koda | Application | Bug Report | Low | InputBox+UpDown | disabled : Code Generator error | Assigned | Chris Haslam | 17.05.2011 |
Task Description
I set InputBox | Enabled to False. Koda generated:
$Input1 = GUICtrlCreateInput("1", 112, 56, 96, 21, 0)
$Updown1 = GUICtrlCreateUpdown($Input1)
GUICtrlSetLimit(-1, 1, 100)
GUICtrlSetState(-1, $GUI_DISABLE)
It should be:
$Input1 = GUICtrlCreateInput("1", 112, 56, 96, 21, 0)
GUICtrlSetState(-1, $GUI_DISABLE)
$Updown1 = GUICtrlCreateUpdown($Input1)
GUICtrlSetLimit(-1, 1, 100) |
|
271 | Koda | Application | Bug Report | Low | Input styles: some suggested changes | Unconfirmed | Chris Haslam | 18.05.2011 |
Task Description
I think that ES_MULTILINE should not appear in Object Inspector because an InputBox is by definition single-line.
ES_WANTRETURN is irrelevant to Input box because InputBox is single-line, so I think that it should not appear in Object Inspector. Same for ES_AUTOVSCROLL and WS_VSCROLL.
In C/C++, WS_GROUP is the way of marking a control as the first in a group, and another control as the last in the group. But AutoIt uses, and Koda generates, a pair of calls to GUICtrlCreateGroup. So I suggest removing WS_GROUP from TAInput in Object Inspector. The fewer styles there are, the easier it is for a user: some scrolling down is inevitable, but the less he needs to do so the less likely he is to miss a style that he needs to check or uncheck.
Koda shows WS_VISIBLE as forced, but AutoIt doesn’t. Further, WS_VISIBLE remains checked even when Visible is False. I suggest removing WS_VISIBLE.
I think that WS_CHILD only applies to Forms. So I suggest removing it from Object Inspector | TAInput.
With WS_HSCROLL checked, when a Form is run, the scroll bar is drawn over the Text. Koda insists that the Height be 21. It needs to allow a larger height when WS_HSCROLL is checked.
|
|
102 | Koda | Application | Bug Report | Low | In String list editor all words are not translatable. | Unconfirmed | Thierry | 05.02.2010 |
Task Description
In the string list editor, we can’t translate all the terms attached image.
|
|
37 | Koda | Import | Feature Request | Low | Import - Listview column widths - not imported | Assigned | Zedna | 03.02.2010 |
Task Description
$Form1 = GUICreate(”Title”, 300, 200, -1, = GUICtrlCreateListView(”A|B|C”, 15, 15, 270, $LVM_SETCOLUMNWIDTH, 0, $LVM_SETCOLUMNWIDTH, 1, $LVM_SETCOLUMNWIDTH, 2,
Column widths are not imported from AU3 to KXF.
|
|
282 | Koda | Application | Bug Report | Low | Icon styles: some suggestions | Unconfirmed | Chris Haslam | 11.06.2011 |
Task Description
SS_ICON: could be dropped from OI because it doesn’t add any info: TAIcon only handles, and requires, an icon.
SS_PREFIX applies to text, but TAIcon has no text.
FS#281 relates
|
|
339 | Koda | Application | Bug Report | High | I can't rename tab control | Unconfirmed | Vo Anh Kiet | 15.01.2015 |
Task Description
I’m using Windows 7 and Koda FormDesign Version 1.7.3.0 build 252 I add more a tab control into Form after that I rename this tab have received a Exception handled: MainExceptionHandler confirm attachment file
|
|
319 | Koda | Application | Bug Report | Low | Hint or Tooltip? | Unconfirmed | Chris Haslam | 08.07.2011 |
Task Description
Koda calls them hints but AutoIt and Windows call them tooltips.
I think that Koda should use the same term as AutoIt.
Right now, the Treeview Styles dialog has a checkbox called Hints (tooltips) show.
|
|
159 | Koda | Documentation | Regular Task | Low | Help | Property Editors | Waiting feedback | Chris Haslam | 18.01.2011 |
Task Description
It would be helpful if the Help mentioned how to access the property editors. A few are obvious, but one that is not is the TreeView Editor. There may be more that have this problem.
|
|
336 | Koda | Application | Bug Report | Low | Height property value of certain fields (input, combobo... | Unconfirmed | vvoois | 18.09.2013 |
Task Description
I have been working with Koda for quite a few years of the most annoying parts of the GUI editor is where i alter the height of inputboxes, comboboxes etc and adjust them to a value where these objects become smaller than the original value (input boxes have a value of 21, i rather cram the contents in 16 pixels which works just as nice).
Koda does accept it and adjusts on the form, but the minute i do something with the form in general or drag the object that is carrying it (frame) somewhere else, the height-value is being set back to the original can also save the form with its values, but when i reload, all values are reset to the original values that seem to be the “minimum” for those objects.
I rather don’t have Koda to touch these properties in any situation, they are manually adjusted for a reason.
|
|
279 | Koda | Application | Bug Report | Low | Graphics: graphic may not show in control | Assigned | Chris Haslam | 14.06.2011 |
Task Description
If the graphic created in Graphics Editor is too far down in the GE design area, and/or is to far the right, it may not be seen in the design area.
There are 3 possible solutions that I can think of:
Have Koda reposition the graphic, and perhaps decrease it in size, so that all of it shows in the Graphics control
Make the size of the design area in the Graphics Editor the same size as the Graphics control
Add to the Graphics Editor the right and bottom bounds of the control, showing them as thick dashed lines. It would then be the responsibility of the user either to keep within the bounded design area or, when he leaves GE, to change the size of the control to fit the graphics.
|
|
280 | Koda | Application | Bug Report | Low | Graphics styles: some suggestions | Unconfirmed | Chris Haslam | 11.06.2011 |
Task Description
SS_LEFTNOWORDWRAP appears in OI but is not, I think, applicable to a control that has no text
SS_SIMPLE seems to do nothing
SS_ETCHEDHORZ reduces the Height to 2, and when the Height is restored in OI, the graphic is not drawn. Indeed, Graphics Editor no longer shows the graphic although Item still shows 1 item.
SS_ETCHEDVERT behaves similarly except that the Width increased to about 630.
These tests were with a graphic that was larger than the control.
|
|
24 | Koda | Application | Bug Report | Low | Generation options dialog is loose indent char selectio... | Assigned | Admin | 06.02.2009 |
Task Description
Generation options dialog is loose indent char selection, when opening options dialog by clicking “Manage” button, and then clicking “Ok” in options dialog.
|
|
306 | Koda | Application | Bug Report | Low | Generate Code button | Save to file | Unconfirmed | Chris Haslam | 25.06.2011 |
Task Description
I created a form in the Design Area but did not save it.
I clicked the Generate icon.
At the Code window, “Save to file” showed. I clicked on it.
Koda said “Your current form is not saved. In order to use the Update function, you must save the form before saving the script”.
But I wasn’t using the Update function, so I suggest that “In order to use the Update function” be dropped from this messagebox.
BTW Yesterday I met a message that contained “it’s”. There is a growing tendency in English usage to use “it’s” rather than “its”. Correct usage is:
“it’s” is the abbreviated form of “it is”, just as “wasn’t” is an abbreviated form of “was not”. The “‘” shows that one or more characters are missing.
“its” is an exception to the general rule that “‘s” indicates possession, as in “Koda’s design”, which is exactly equivalent to “the design of Koda”
“its design” is good English.
There are cases in computer-eze where I do use “‘s” to indicate a plural because it seems to be the only way to be clear. An example: “there are five #include’s in my script”.
|
|
175 | Koda | Application | Regular Task | Low | Forms main menu item: Why? | Assigned | Chris Haslam | 11.02.2011 |
Task Description
I do not see the reason for the existence of this menu item.
I can almost as easily key Ctrl-3 and choose which form to activate with the mouse.
Also, consider a form that occupies the whole of the screen. In this case, there is no way IMHO to activate the main menu in order for Alt-m to work. (See the Help as it now is.)
If you wish to keep the Forms menu item, perhaps there should be a function key that focuses Koda so the main menu is active, so Alt-m works.
Or am I missing something?
...chris
|
|
268 | Koda | Application | Feature Request | Low | Form | WS_EX_ACCEPTFILES requires GUI_DROPACCEPTED in o... | Unconfirmed | Chris Haslam | 17.05.2011 |
Task Description
I don’t see how to check GUI_DROPACCEPTED in Edit control.
|
|
223 | Koda | Application | Bug Report | Low | Form | OnClose, OnMaximize, OnMinimize in MessageLoop ... | Assigned | Chris Haslam | 04.05.2011 |
Task Description
With OnClose, OnMaximize, OnMinimize set to Notify, Koda generated the following code with Generating Options set to MessageLoop mode:
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
#Region ### START Koda GUI section ### Form=F:\Koda forms for PerfectScript\Pic ed test.kxf
$Form1 = GUICreate("Form1", 623, 449, 192, 114)
$Icon1 = GUICtrlCreateIcon("D:\WINDOWS\system32\freecell.exe", -1, 136, 136, 121, 121)
$Pic1 = GUICtrlCreatePic("D:\WINDOWS\system32\setup.bmp", 392, 120, 177, 169)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###
While 1
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit
Case $Form1
Case $Form1
Case $Form1
EndSwitch
WEnd
The last 3 cases look odd to me.
I would expect in MessageLoop mode:
As well as $ GUI_EVENT_CLOSE, two cases: $ GUI_EVENT_MAXIMIZE and $ GUI_EVENT_MINIMIZE
I then switched to OnEvent mode and got:
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
Opt("GUIOnEventMode", 1)
#Region ### START Koda GUI section ### Form=F:\Koda forms for PerfectScript\Pic ed test.kxf
$Form1 = GUICreate("Form1", 623, 449, 192, 114)
GUISetOnEvent($GUI_EVENT_CLOSE, "Form1Close")
GUISetOnEvent($GUI_EVENT_MINIMIZE, "Form1Minimize")
GUISetOnEvent($GUI_EVENT_MAXIMIZE, "Form1Maximize")
$Icon1 = GUICtrlCreateIcon("D:\WINDOWS\system32\freecell.exe", -1, 136, 136, 121, 121)
$Pic1 = GUICtrlCreatePic("D:\WINDOWS\system32\setup.bmp", 392, 120, 177, 169)
GUISetState(@SW_SHOW)
#EndRegion ### END Koda GUI section ###
While 1
Sleep(100)
WEnd
Func Form1Close()
EndFunc
Func Form1Maximize()
EndFunc
Func Form1Minimize()
EndFunc
I don’t see Exit, so it appears that this is not the code that is run by Koda. This is only an observation.
|
|
292 | Koda | Application | Bug Report | Low | Form styles: Code generation error | Unconfirmed | Chris Haslam | 10.06.2011 |
Task Description
Style 94C8 0000 generates $WS_SYSMENU,$WS_POPUP. It should generate $WS_POPUPWINDOW, $WS_CAPTION.
|
|
291 | Koda | Application | Bug Report | Low | Form styles: a few definitely don't belong to Form | Unconfirmed | Chris Haslam | 09.06.2011 |
Task Description
WS_GROUP and WS_MINIMIZEBOX have the same value, so WS_GROUP is not a constant for a Form. So remove WS_GROUP. See FS#267 .
The value of WS_OVERLAPPED is zero. It has no mask. So I suggest that it be removed from OI.
WS_SIZEBOX and WS_THICKFRAME have the same value, so I suggest removing WS_THICKFRAME.
WS_TABSTOP and WS_MAXIMIZE have the same value, so WS_TABSTOP is not a constant for a Form. So I suggest removing WS_TABSTOP.
|
|
293 | Koda | Application | Bug Report | Low | Form style DS_FOREGROUND: Autoit only supports partiall... | Unconfirmed | Chris Haslam | 26.05.2011 |
Task Description
Microsoft says of DS_FOREGROUND:
Causes the system to use the SetForegroundWindow function to bring the dialog box to the foreground
AutoIt does not seem to provide SetForegroundWindow functionality.
So I suggest the DS_FOREGROUND be removed.
WS_EX_TOPMOST provides “stay on top”.
|
|
269 | Koda | Application | Bug Report | Low | Form lacks WS_EX_CLIENTEDGE and WS_EX_STATICEDGE | Unconfirmed | Chris Haslam | 17.05.2011 |
Task Description
AutoIt has constants for them
|
|
222 | Koda | Documentation | Bug Report | Low | Form control | Unconfirmed | Chris Haslam | 04.05.2011 |
Task Description
Description is in the doc but not in Object Inspector. Do I remove Description from doc?
|
|
316 | Koda | Application | Bug Report | Low | Font size inconsistent for Courier New | Unconfirmed | Chris Haslam | 04.07.2011 |
Task Description
The attached .kxf shows one font size in Design Area and a smaller size when run.
This problem may be related to another. This dialog shows as designed if I change the font size to 8.5 points in AutoIt. Koda won’t let me set the font size to 8.5.
|
|
299 | Koda | Application | Bug Report | Low | File | Recent Files: non-existent file | Unconfirmed | Chris Haslam | 21.06.2011 |
Task Description
When I tried to open a file that I had moved, Koda said “F:\ ... is not exists”. Correct English usage is “does not exist”.
|