|
89 | Koda | Application | Bug Report | Medium | Wrong form height in the generated code | Researching | | 29.05.2011 |
Task Description
If a dialog form is created with the certain style bits (s. below) in Koda the window height in the generated AutoIt code is set to ClientHeight + 1 instead of Height which cuts off a stripe of the height of the window’s title bar (mostly 26 px) at the bottom of the form at the time is displayed from the script.
Example as followed.
SampleDialog.kxf
<object type="TAForm" name="dlgTest">
<properties>
<property name="Left" vt="Int16">1626</property>
<property name="Top" vt="Int16">262</property>
<property name="Width" vt="Int16">321</property>
<property name="Height" vt="Int16">407</property>
<property name="Caption" vt="String">Sample Dialog</property>
<property name="Color" vt="Ident">clBtnFace</property>
<property name="Font.Charset" vt="Ident">DEFAULT_CHARSET</property>
<property name="Font.Color" vt="Ident">clWindowText</property>
<property name="Font.Height" vt="Int8">-11</property>
<property name="Font.Name" vt="String">MS Sans Serif</property>
<property name="Font.Style" vt="Set"/>
<property name="OldCreateOrder" vt="False">False</property>
<property name="Position" vt="Ident">poDesktopCenter</property>
<property name="ParentForm" vt="String">owner</property>
<property name="Style" vt="Int32">273154176</property>
<property name="ExStyle" vt="Int8">0</property>
<property name="Version" vt="String">1.04</property>
<property name="PixelsPerInch" vt="Int8">96</property>
<property name="TextHeight" vt="Int8">13</property>
</properties>
</object>
SampleDialog.au3 (generated)
#Region ### START Koda GUI section ### Form=SampleDialog.kxf
Local $dlgTest = GUICreate("Sample Dialog", 314, 374, -1, -1, BitOR($WS_SYSMENU,$WS_DLGFRAME,$DS_MODALFRAME), 0, $owner)
#EndRegion ### END Koda GUI section ###
As far as I evaluated this concerns only (modal) dialog frames with system menu but without minimize/maximize boxes, normal overlapped windows are not affected though their heights are also set to ClientHeight. It may be the strange way AutoIt’a GUICreate() works but I think Koda should reflect its behavior even if it’s inconsistent.
|
|
188 | Koda | Application | Feature Request | Low | Which form should open when you run Koda? | Unconfirmed | Chris Haslam | 01.03.2011 |
Task Description
In 1.7.3.0, it appears that when I run Koda, the form that automatically opens is the last one changed (I am not sure of this).
I would like to see Koda start by opening the form that was active when Koda was last exited. This makes more sense to me.
|
|
198 | Koda | Application | Bug Report | Low | When CBS_DROPDOWNLIST is set, Koda generate CBS_SIMPLE ... | New | Admin | 15.04.2011 |
Task Description
When CBS_DROPDOWNLIST is set, Koda generate CBS_SIMPLE instead.
|
|
337 | Koda | Import | Bug Report | Medium | Using parenthesis "()" in tab names, breaks import. | Unconfirmed | Vitaliy Maksimov | 24.09.2013 |
Task Description
1. Create a new “Tabbed Pages” Change the name of the first tab to “TabSheet1 Generate form code File, Import, Import Autoit GUI
|
|
136 | Koda | Application | Feature Request | Medium | Use array names | Postponed | OmYcroN | 07.05.2011 |
Task Description
Please add the ability to use array names in the Object Inspector for the control names: ControlName[Index]
|
|
140 | Koda | Application | Feature Request | Very Low | Unicode support | Unconfirmed | Thong | 30.10.2010 |
Task Description
I am vietnamese,i use the unicode,but koda don’t support it,we need it,thanks
|
|
312 | Koda | Application | Feature Request | Low | Undoing strings | Unconfirmed | Chris Haslam | 06.07.2011 |
Task Description
It would make sense to me to have one Ctrl_Z undo all changes to a string, rather than character-by-character.
|
|
131 | Koda | Application | Bug Report | High | Unable to insert embedded IE control | Assigned | ND | 04.05.2010 |
Task Description
In version 1.7.2.8 when I try to add an embedded IE control (Shell.Explorer.2) to a form Koda shows ‘Call to DllRegisterServer failed in
As consequence no AU3 code is generated for the control - although it shows on the form - and all attempts to open the definition file afterward fail with the same error message, so the only remaining option is to open KXF file as XML and remove the control manually.
Especially confusing is the fact that Koda wants to call DllRegisterServer at all. Why is it necessary? The DLL is already registered on the system, otherwise the control wouldn’t appear in the Koda’s object browser.
|
|
284 | Koda | Application | Bug Report | Low | Treeview styles: some suggestions | Unconfirmed | Chris Haslam | 20.05.2011 |
Task Description
TVS_LINESATROOT is only intended by MS to work if TVS_HASLINES is also set, so Koda should check TVS_HASLINES when user checks TVS_LINESATROOT.
TVS_FULLROWSELECT is only intended by MS to work if TVS_HASLINES is not set, so Koda should uncheck TVS_HASLINES when user checks TVS_FULLROWSELECT.
TVS_NOTOOLTIPS and TVS_INFOTIP show in OI but Treeview Editor does not provide a way of entering tool tips. AutoIt only seems to provide ways of setting tool tips via GUICtrlSendMsg or by calling a UDF. So I suggest removing these two styles from OI for now.
|
|
219 | Koda | Application | Feature Request | Low | Treeview Editor: Observations | Assigned | Chris Haslam | 27.04.2011 |
Task Description
I suggest that:
Selecting a node created earlier without a name is challenging: you have to click exactly in the right place. I suggest that when a node is created, Koda assign it a temporary name, e.g. Node1 (like Menu Editor). This name would be highlighted in the Text input box, ready for the user to enter his own name.
A related question: should Koda even allow a node to exist neither an image nor a name?
It would be user-friendly if images could be selected from a list: see how I have written the doc for To add a node.
It would be nice if icons showed in the treeview control as they do at run time.
Is image the correct word? Aren’t they always icons?
|
|
218 | Koda | Application | Bug Report | Low | TreeView bug? | Assigned | Chris Haslam | 26.04.2011 |
Task Description
I am trying to understand Image index and Selected index. BTW in the doc proped_treeview_editor.png lacks these controls.
When I tried to generate from the attached form, I got an AutoIt error. See attached screenshot.
|
|
236 | Koda | Application | Bug Report | Low | TreeView :Properties | Unconfirmed | Chris Haslam | 04.05.2011 |
Task Description
I suggest that Images be called ImageList. This will be clearer.
I suggest that Items be called Nodes.
|
|
214 | Koda | Application | Bug Report | Low | TrayMenu | Undo | Assigned | Chris Haslam | 21.04.2011 |
Task Description
I clicked on New Form icon
I created a Tray Menu control
I added File as a menu item and gave it Exit as a sub-menu item
I did Ctrl_Z several times
I was then unable to select the form.
|
|
215 | Koda | Application | Bug Report | Low | TrayMenu | MouseClick | Default | Assigned | Chris Haslam | 26.04.2011 |
Task Description
I have problems with Koda generating TraySetClick(”0”) as the default:
It is not clear to me what ShowStdMenu does when a Tray Menu control is on a form.
Any thoughts?
|
|
197 | Koda | Documentation | Regular Task | Low | Tools | Update Script with multiple Koda regions in the... | Unconfirmed | Chris Haslam | 15.04.2011 |
Task Description
If there are two Koda regions in a .au3 file, say foo.kxf and bar.kxf, will Update Script work both when foo.kxf is the active form and when bar.kxf is the active form?
It seems to me that this is possible, but the current documentation does not say so.
|
|
182 | Koda | Application | Bug Report | Low | Tools | Generating Options | Template doesn't show Even... | Assigned | Chris Haslam | 24.02.2011 |
Task Description
But Events Example is in Code Templates dialog
|
|
289 | Koda | Application | Bug Report | Low | Toolbar: suggested changes | Unconfirmed | Chris Haslam | 22.05.2011 |
Task Description
TBSTYLE_TOOLTIPS: not needed in OI because Koda knows whether Hints have been specified. So suggest remove TBSTYLE_TOOLTIPS for now.
TBSTYLE_ALTDRAG: Doc would say “Allows changing a button’s position by Alt-dragging it, rather than Shift-dragging it. Requires CCS_ADJUSTABLE”. Also doc would describe CCA_ADJUSTABLE as “enables user to add, delete, and rearrange buttons”. CCA_ADJUSTABLE is defined in Constants.au3. Suggesting adding styles is beyond my current scope, so I suggest removing TBSTYLE_ALTDRAG for now.
TBSTYLE_LIST does not seem to work, so I suggest removing it from OI.
TBSTYLE_CUSTOMERASE: Doc would say “Generates NM_CUSTOMDRAW notification codes when toolbar processes WM_ERASEBKGND messages”. This is not generated by Koda, so I suggest removing it from OI.
TBSTYLE_REGISTERDROP: Doc would say “Generates TBN_GETOBJECT notification codes to request drop target objects when the cursor passes over toolbar buttons”. This is not generated by Koda, so I suggest removing it from OI.
Extended Styles: Bug: won’t stay checked, so can’t test them.
TBSTYLE_EX_MIXEDBUTTONS: Requires TBSTYLE_LIST, which doesn’t seem to work. So I suggest removing TBSTYLE_EX_MIXEDBUTTONS from OI.
TBSTYLE_EX_HIDECLIPPEDBUTTONS: AutoIt help says “Hides partially clipped buttons”. To me buttons could only be partly clipped if buttons were added. CCS_ADJUSTABLE is not in OI, so I suggest removing TBSTYLE_EX_HIDECLIPPEDBUTTONS for now.
|
|
245 | Koda | Application | Bug Report | Low | Toolbar: Properties: discrepancy between Koda and the d... | Unconfirmed | Chris Haslam | 05.05.2011 |
Task Description
The following properties are in Object Inspector but not in the doc:
TAToolbar - Enabled, Height, Hint, Tab Order, Top, Visible, Width
TAToolButton - Caption, Enabled, Height, Hint, ImageIndex, Top, Visible, Width
Please tell me which should be added to the doc. (Some I know, e.g. ImageIndex)
|
|
251 | Koda | Application | Bug Report | Low | Toolbar | Style | tbsDropDown | Unconfirmed | Chris Haslam | 06.05.2011 |
Task Description
A button with tbsDropDown does not show correctly when the form is run. Koda generates
_GUICtrlToolbar_AddButton($ToolBar1, 0, 20, 0, $BTNS_DROPDOWN)
The AutoIt help says:
_GUICtrlToolbar_AddButton($hWnd, $iID, $iImage[, $iString = 0[, $iStyle = 0[, $iState = 4[, $iParam = 0]]]])
Is this a code generator problem? Or is _GUICtrlToolbar flaky?
|
|
243 | Koda | Application | Bug Report | Low | Toolbar | Button | Height | Unconfirmed | Chris Haslam | 05.05.2011 |
Task Description
Selected Height value
Pressed Del
Pressed Enter
Exception Exception handled 2011-05-04 at 22:35:49 by is not a valid integer Address: about Source of Method: Line:
Same thing happened when Backspace key (rather than Del) was pressed.
|
|
250 | Koda | Application | Bug Report | Low | Toolbar : controls_toolbutton_add.png | Unconfirmed | Chris Haslam | 06.05.2011 |
Task Description
Please update this image with your selection color.
|
|
184 | Koda | Application | Feature Request | Low | Template Gallery | Assigned | Chris Haslam | 05.05.2011 |
Task Description
I note that the documentation calls this “Templates Gallery” but 1.7.3 .0 and the screen shot call it “Form Templates”. I suggest that “Form Templates” is the better name: it fits with “Code Generation Templates”. I will change the documentation to “Form Templates”.
I note that 1.7.3.0 shows two tabs: “Standard” and “My own templates”, but that the 1.7.3.0 help and the documentation shows only “Standard”. Further, one of the templates in the “My own templates” tab has no icon. I suggest that “My own templates” be dropped. THe documentation will tell the user how to add templates and tabs.
How can the user add a description and icon to a template he creates?
How can the user delete a template he creates?
How can the user delete a tab that he creates?
|
|
154 | Koda | Application | Bug Report | Low | TAUpdown: Problems in AutoIt affect Koda | Unconfirmed | Chris Haslam | 03.01.2011 |
Task Description
GUICtrlSetLimit() sets max and min but not increment. Perhaps a _GuiCtrlSetLimit(max, min, incr) could be written. Then Koda could set a (new) Increment property. It is needed if UDS_ARROWKEYS is to work. You may have some influence over Jon to add to GUICtrlSetLimit().
If no style is specified, Updown is placed to the right of the Input, but $ GUI_SS_DEFAULT_UPDOWN alone puts the UpDown to the left of the Input. This is because UpDownConstants.au3 has Global Const $GUI_SS_DEFAULT_UPDOWN = $UDS_ALIGNLEFT
To me, $GUI_SS_DEFAULT_* are equivalent to -1. AutoIt Help says that -1 means $UDS_ALIGNRIGHT. Right is where you expect to see an UpDown. So Koda should use $UDS_ALIGNRIGHT until AutoIt fixes $GUI_SS_DEFAULT_UPDOWN.
|
|
152 | Koda | Application | Bug Report | Low | TAUpdown: Appearance in Preview is inconsistent with ap... | Assigned | Chris Haslam | 30.06.2011 |
Task Description
In Koda, it is possible to widen an updown control. This change shows in Preview and can make some very wide updown controls.
Running the generated code produces the same overall width (Input plus Updown) but the width of the Updown is fixed. The extra width is added to the Input.
See attached screenshots.
AutoIt help shows
GUICtrlCreateUpdown ( inputcontrolID [,style]
so there is no opportunity to enter the left, top, width and height.
So left, top, width and height should not appear in Properties for Updown. The left and top are always “to the right of the Input”. The height is taken from the Input, and should be set there. The width is always 17 in AutoIt.
Autoit only recognizes UpDown as a buddy window.
MSDN says that “The width of the buddy window is decreased to accommodate the width of the up-down control”. This is not the way AutoIt behaves.
|
|
281 | Koda | Application | Bug Report | Low | TAPic styles: some suggestions | Unconfirmed | Chris Haslam | 20.05.2011 |
Task Description
I suggest not showing SS_BITMAP in OI because it is redundant and, for AutoIt, incorrect: AutoIt supports BMP, JPG, and GIF.
For transparency, Form needs WS_EX_LAYERED, so perhaps this should be added to Form.
I do not see how SS_NOPREFIX applies to Pic.
|
|
318 | Koda | Application | Bug Report | Low | TAMonthCal: Centering problem | Assigned | Chris Haslam | 08.07.2011 |
Task Description
The auto-height seems to be correct at 168, but the vertical centering is off a bit, so when Autosize is True, the bottom of the Today line is hidden.
It is likely that there are other cases where centering is a bit off, e.g. Align | Center Vertically in Window.
|
|
321 | Koda | Application | Bug Report | Low | TAListView: code generation funny | Unconfirmed | Chris Haslam | 15.07.2011 |
Task Description
$ListView1 = GUICtrlCreateListView("|", 128, 56, 257, 289, BitOR($GUI_SS_DEFAULT_LISTVIEW,$LVS_NOCOLUMNHEADER))
was generated by Koda, and does not work with 2 columns: the second column shows as blank.
$ListView1 = GUICtrlCreateListView(" | ", 128, 56, 257, 289, BitOR($GUI_SS_DEFAULT_LISTVIEW,$LVS_NOCOLUMNHEADER))
does work.
Koda then generated:
GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 0, 50)
GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 1, 200)
Apparently AutoIt needs a space before and after the |.
I consider this to be an AutoIt bug, but Koda is the servant of AutoIt, so ...
If AutoIt ever fixes this bug, Koda code generation will still be OK with “<space>|<space> “.
|
|
296 | Koda | Application | Bug Report | Low | TAList: Code Generator error | Assigned | Chris Haslam | 01.06.2011 |
Task Description
I set the Color of a Listbox to clBtnFace. It showed OK in the Design Area but when Run. the box was white.
|
|
309 | Koda | Application | Bug Report | Low | TAList: Caption missing from Properties | Unconfirmed | Chris Haslam | 08.07.2011 |
Task Description
Probably not used much, but should be there.
|
|
158 | Koda | Application | Bug Report | Low | TALabel: Autosize | Assigned | Chris Haslam | 03.06.2011 |
Task Description
I would like to see the default for TALabel | Autosize be False. It is frustrating to create a label which will be populated/set from the AutoIt script and have its default to the size of the text Label1 – because part of my mental process is to make the size be enough for the longest value GUICtrlSetData() will provide.
For example, when I am upgrading a script, I usually put the word “Development” as a label in the first dialog the script creates. When the script is no longer a development version, the script leaves this label blank. So in Koda I make lblDevel long enough for the word “Development”. Here is the
If StringInStr(@ScriptName,"(Devel)")<>0 Then
GUICtrlSetData($lblDevel,"Development version")
EndIf</code>
As Koda is now, I have to create the label, change AutoSize to False, then increase the length of the label. A bit of a pain!
This is not a major issue with me, but I would prefer AutoSize to default to False (as VB has it).
...chris
|
|
153 | Koda | Application | Bug Report | Low | TAInput with TAUpdown always sets initial value to UpDo... | Postponed | Chris Haslam | 17.01.2011 |
Task Description
I set the Min to 1 and the Max to 9 in Updown. I could not then change the Text in Input to 3. I should be able to do this.
|
|
147 | Koda | Application | Feature Request | Low | TAGroup: A suggestion | Waiting feedback | Chris Haslam | 17.01.2011 |
Task Description
Koda works well at grouping if the user creates a group and then adds radio buttons to it: he decides in advance what area of the form will be needed for the radios, and then adds the radios. For example, he creates Group1 and then creates Radio1 and Radio2 within it.
But two scenarios:
But what if he later realizes that he needs a third radio in this group? When he enlarges the Group area and adds Radio 3, Radio3 is not placed in Group1. It should be.
The user creates Checkbox1 and CheckBox2. He then surrounds them with Group2. The checkboxes are not made part of Group2. They should be.
I suggest that code be added to Koda: when a group is created, include in it all controls which are within the area of the group.
|
|
278 | Koda | Application | Bug Report | Low | TAGroup styles - some suggestions | Unconfirmed | Chris Haslam | 19.05.2011 |
Task Description
BS_RIGHTBUTTON: does not seem to do anything. So perhaps remove it from OI.
BS_GROUPBOX: redundant in TAGroup. So perhaps remove it from OI.
WS_GROUP: irrelevant to code generation. AutoIt normally uses GuiCtrlCreateGroup. So perhaps remove it from OI.
|
|
311 | Koda | Application | Bug Report | Low | TAEDIT: bad line wrapping with custom font | Unconfirmed | Chris Haslam | 07.07.2011 |
Task Description
The attached .kxf file shows that for the dd code, zero fits easily on the line when the form is run. If I remove the \n\r in Strings Editor, they return when I close SE. SE does not seem to know that the font is Courier New 8pt.
|
|
276 | Koda | Application | Bug Report | Low | TAComboBox: Height behaviour abnormal | Assigned | Chris Haslam | 19.05.2011 |
Task Description
With CBS_SIMPLE set, at design time, when I mouse to change the height of the control, the Height property does not change.
|
|
241 | Koda | Application | Bug Report | Low | Tab: Hint | Unconfirmed | Chris Haslam | 05.05.2011 |
Task Description
The doc says;
If one of pages has “Hint” property set, Koda will always generate GUICtrlSetTip for first page - this is the only way to correct setting tip to previous pages.
I am not sure what this means.
Here is what I think it may mean:
If you set a Hint for a page other than the first page, Koda will also generate a Hint for the first page.
Does this mean that a Hint will be set for all pages?
Is this an AutoIt limitation?
Is the Hint on the first page the same as on the subsequent page?
|
|
287 | Koda | Application | Bug Report | Low | Tab styles: some suggestions | Unconfirmed | Chris Haslam | 21.05.2011 |
Task Description
TCS_SCROLLOPPOSITE: I am not sure what this is supposed to do, but it does not seem to do anything. Googling didn’t help. Perhasp it should be removed from OI.
TCS_TOOLTIPS: There is no Hint property for a Page. Remove it from OI until there is?
See the doc for the many requirements. It would be good to have OI help the user not to choose combinations of styles that MS does not intend to work.
|
|
290 | Koda | Application | Bug Report | Low | Tab Sequence (Order) Editor: a proposal | Unconfirmed | Chris Haslam | 23.05.2011 |
Task Description
I am attaching a screen shot of what I have in mind. This dialog would be accessible from Edit | Tab Order and from each real (not substitute) control. From the menu, it would appear as in the screen shot. From a control, if the control is a group, the group would be highlighted. If the control is not in a group, Form1 would be highlighted.
Note that Koda would not show sequence numbers of tabstops. This would be internal to fd.exe. Users won’t need sequence numbers if they have the information visually. The user would no longer have to think the numbers. With the proposed dialog, he would get all the tabstop info in one place. This makes sense to me because tabstops are really inter-control rather than intra-control.
Optimally, Add would only be enabled when the Not tabstops .. list has focus and an item is selected. Up, Down and Remove would only be enabled when the Tabstops list has focus and an item is selected (and of course, Up would be disabled if the top item is selected, and Down would disabled if the last item is selected).
If this proposal is implemented, I would suggest:
In Properties, Tab Order would be replaced with Tabstop, which would be read-only boolean , with a ... button to the right to access the Editor
In Styles, WS_TABSTOP would be removed. fd.exe would continue to track WS_TABSTOP.
It is possible that, early in designing a form, a user may wish to make some controls tabstops, and others not; he may wish to refine the order later. So the Tabstop property could be read-write. If it is, I suggest:
If the user changes Tabstop for a control from False to True, the control would be placed at the end of the Tabstops list
If the user changes Tabstop for a control from True to False, the control would be moved from the Tabstops list to the Not tabstops, but can be list.
For Label (and other controls that cannot be tabbed to), the Tabstop property would be set to False and would be read-only.
I acknowledge that AutoIt tabs in the order in which calls to GuiCtrl functions that specify WS_TABSTOP appear in the script. The code generator could generate in the order shown: first the Tabstop list (with WS_TABSTOP set), then the others (without TABSTOP set), although this is not requisite.
I think that this proposal mostly improves the UI. It does clear up what I called an inconsistency in my previous post – although I may be wrong. I think that the code under the hood will change very little.
I have done some playing with (and thinking about) the names of the lists. Alternative names are: Un-tabable, Potential tabstops and Tabstops. I don’t like Un-tabable because it is bad English.
|
|
170 | Koda | Application | Feature Request | Low | Tab Order - 2 cases | Assigned | Chris Haslam | 23.05.2011 |
Task Description
As well as Edit→Tab Order, I now see Tab Order in Object Inspector (e.g. for Button). (perhaps Tab Stop Number would be more precise). So I think that there are two cases:
Setting the tab order for all controls, and
Setting the tab stop number for the currently selected control.
Tab Order Editor handles the first case.
Now for the second case.
In Object Inspector, Koda permits the user to enter the tab stop number. But what if he enters 2, and there is already a control that has tab stop 2. What happens?
I think it would be preferable to have clicking to the right of tab order bring up a dialog something like my screenshot:
This would allow the user to position the selected control relative to other controls. Note that he would no longer be concerned with the tab stop number, so conflicts in number could not occur.
IMHO
...chris
|
|
249 | Koda | Application | Bug Report | Low | Tab control: Hint being set for ccontrol on a page | Unconfirmed | Chris Haslam | 06.05.2011 |
Task Description
The attached .kxf file, when run, shows a Hint for the Label on the third Page. The Hint should be for the Page.
|
|
240 | Koda | Application | Bug Report | Low | Tab Control: Focus and reorganizing pages | Unconfirmed | Chris Haslam | 06.05.2011 |
Task Description
While Alt-Left and Alt-Right have worked for me, I have just spent several minutes trying to get Alt-Left to work for me.
Screen shot and .kxf file are attached.
I wish I could be clearer as to what is happening. Alt-Left seems not to be working because the focus is not on TabSheet1. I also notice that the Form is active but Koda is not: odd.
When I first tried Alt-Left and Alt-Right they didn’t work. Then somehow they did.
|
|
298 | Koda | Application | Bug Report | Low | Styles dialogs suggestions | Unconfirmed | Chris Haslam | 08.09.2011 |
Task Description
I have made some more progress: I have improved the Form dialog, and present the Label dialog for the first time.
I am beginning to think about Pic, Icon and Graphic. Here are my thoughts:
The following SS constants only apply to an image: SS_BITMAP, SS_ICON, SS_REALSIZECONTROL, SS_REALSIZEIMAGE and SS_RIGHTJUST. Which of these does Picture Editor handle? Which does the proposed Styles Editor need to handle?
I have learnt that ControlSetText() can be used to show text in an apparently image-only Static control. So the Styles Editor for Pic, Icon and Graphic could look much the same as that for Label. Would it be identical?
It occurs to me that if Koda will have a Styles Dialog for images that has styles for text, it would make sense to have Code Generator generate the call to ControlSetText().
More thoughts are in the attached readmes.
|
|
217 | Koda | Application | Feature Request | Low | Strings Editot | Show Hard Return? | Unconfirmed | Chris Haslam | 26.04.2011 |
Task Description
It would be nice if Hard Return showed. My experience elsewhere is that, because the width of the Edit control and the width of the Strings Editor are usually different, showing HRt can relieve some confusion.
|
|
286 | Koda | Application | Bug Report | Low | Statusbar styles: some suggestions | Assigned | Chris Haslam | 11.06.2011 |
Task Description
SBARS_SIZEGRIP and SBARS_TOOLTIPS: need some extra code to be generated to work. For now, doc says “Requires ... message”.
SBARS_TOOLTIPS: no way to specify hint(s).
Remove them from OI for now?
|
|
235 | Koda | Application | Bug Report | Low | Slider | Position | Waiting feedback | Chris Haslam | 11.05.2011 |
Task Description
I take Position to be the initial position (value) of the slider.
I set Position to 40. It appeared not to generate any code. I did run. The slider showed at the left end of its range.
|
|
283 | Koda | Application | Bug Report | Low | Slider styles: some suggestions | Unconfirmed | Chris Haslam | 10.06.2011 |
Task Description
TBS_ENABLESELRANGE, TBS_FIXEDLENGTH: I do not see a way of setting the selection range. It appears that GuiCtrlSlider... does not have selection range but _GuiCtrlSlider... does. TBS_ENABLESELRANGE is in SliderConstants.au3
TBS_NOTHUMB appears twice in OI.
|
|
315 | Koda | Application | Bug Report | Low | Send to Back, Bring to Front: bug? | Unconfirmed | Chris Haslam | 04.07.2011 |
Task Description
The attached .kxf does not display as I would expect.
|
|
4 | Koda | Application | Feature Request | Low | Save chosen template as one of form options | Assigned | Admin | 13.11.2008 |
Task Description
Save chosen template as one of form options.
|
|
79 | Koda | Application | Feature Request | Low | RichEdit custom control | Assigned | Admin | 15.10.2009 |
Task Description
RichEdit custom control since it’s UDF was added in the standard distributive.
|
|
21 | Koda | Application | Bug Report | Low | Resizing property - missing some constants | Postponed | Zedna | 16.03.2009 |
Task Description
In object inspector is property Resizing generated code GUICtrlSetResizing()
But there are missing constants (defined in AutoIt’s helpfile): $GUI_DOCKSIZE, $GUI_DOCKMENUBAR, $GUI_DOCKSTATEBAR, $GUI_DOCKALL, $GUI_DOCKBORDERS
All these contants are defined by sum of base constants already defined in I think it may be intentional to not add these contants.
But it would be pretty handy to have them all in Koda.
|