|
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.
|
|
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.
|
|
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 |
|
229 | Koda | Application | Bug Report | Low | Data separator char | Assigned | Chris Haslam | 05.05.2011 |
Task Description
I find it a little surprising that Data separator char is in Options but not in Generating Options. My understanding is that it is not saved with the form, so if the form was created when Options | Data separator char was (say) $ and the user later adds a ListBox where one of the items is $10, he has to recreate his form from scratch.
Thoughts?
|
|
230 | Koda | Application | Bug Report | Low | Combo: ItemIndex and Text | Unconfirmed | Chris Haslam | 05.05.2011 |
Task Description
I take ItemIndex to be the ordinal number of the Item that is shown initially ref 1).
With a List, I have played with Text. It seems always to show the Item with the ordinal that is assigned to ItemIndex. So why does Koda have both ItemIndex and Text? Or should Text be read-only?
|
|
231 | Koda | Application | Bug Report | Low | Combo: Remarks | Unconfirmed | Chris Haslam | 04.05.2011 |
Task Description
The doc from WinXP the “visual” height of combo cannot be set. Height parameter is showing height of opened combo. Koda allow you to change it manually.
I don’t understand. Is the doc saying that the collapsed height is fixed by XP and up, but that the user can set (with the Height property) the expanded height? If so.I have not been able to see this.
|
|
232 | Koda | Application | Bug Report | Low | Control | Pic | Unconfirmed | Chris Haslam | 04.05.2011 |
Task Description
I have written:
sRealSize - Width and height are determined by original size of image
Is this correct?
|
|
233 | Koda | Application | Bug Report | Low | Cannot set OnClick to be none | Unconfirmed | Martin Gibson | 04.05.2011 |
Task Description
The OnClick property does not work for me if I choose none. With none I expect that there will be no line GuiCtrlSetOnEvent for that control and for lots of things, like labels, I might not have an event.
|
|
234 | Koda | Application | Bug Report | Low | Dummy: notify | Assigned | Chris Haslam | 04.05.2011 |
Task Description
I read in the doc:
The control will “notify” as normal
but do not see an OnClick property.
So how does the user tell a Dummy control to notify?
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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?
|
|
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
|
|
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.
|
|
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)
|
|
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.
|
|
247 | Koda | Application | Bug Report | Low | Koda menu | Help | Content | Unconfirmed | Chris Haslam | 05.05.2011 |
Task Description
The correct English usage is Contents.
|
|
248 | Koda | Documentation | Bug Report | Low | Creating a Tab control | new screenshot | Unconfirmed | Chris Haslam | 06.05.2011 |
Task Description
Please update controls_tab_add.png, i.e. with Add a Page rather than New Page. I could do it, but my colors are different from yours.
|
|
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.
|
|
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.
|
|
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?
|
|
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.
|
|
253 | Koda | Documentation | Regular Task | Low | Combobox | Remarks | Height parameter | Unconfirmed | Chris Haslam | 19.05.2011 |
Task Description
The doc as I received it says:
Starting from WinXP the “visual” height of combo cannot be set. Height parameter is showing height of opened combo. Koda allow you to change it manually.
I don’t quite understand.
Does this say the same thing:
Windows XP and up set the opened height of a Combobox. The Height property is the height of the closed Combobox.
My playing around shows that the height of the closed control is fixed in Design Area and at run-time (perhaps font-size dependent), and that when opened, the height is sufficient to show at least 15 items.
|
|
255 | Koda | Application | Bug Report | Low | Dummy: How to show Context Menu | Unconfirmed | Chris Haslam | 11.05.2011 |
Task Description
How can I get a context menu to show when I press the accelerator key?
See attached for AutoIt error.
|
|
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.
|
|
258 | Koda | Application | Bug Report | Low | dialog_generating_options.png is out of date | Unconfirmed | Chris Haslam | 08.05.2011 |
Task Description
Please update with your color scheme
|
|
259 | Koda | Application | Bug Report | Low | proped_treeview_editor.png: update from Item to Node | Unconfirmed | Chris Haslam | 08.05.2011 |
Task Description
Please
|
|
261 | Koda | Application | Feature Request | Low | Disable a tabstop | Unconfirmed | Chris Haslam | 24.05.2011 |
Task Description
An example from External Link:
GUICtrlCreateButton("Two", 10, 140, 80, 30)
_WinAPI_SetWindowLong(GUICtrlGetHandle(-1), $GWL_STYLE, BitAND(_WinAPI_GetWindowLong(GUICtrlGetHandle(-1), $GWL_STYLE), BitNOT($WS_TABSTOP)))
But first the inconsistency between Tab Order and WS_TABSTOP needs to be resolved.
|
|
263 | Koda | Documentation | Bug Report | Low | Add styles and exstyles to documentation? | Unconfirmed | Chris Haslam | 17.05.2011 |
Task Description
I am inclined to think that Styles and ExStyles should be added to the documentation – for each control in the Controls section. That way, Koda goes even further to being the “one stop” place for GUIs.
Any thoughts?
Include would make the process less painful. There are some WS_ constants that are available to almost all controls, so it would be nice to be able to include multiple rows of a table in one VAR. Can Include do this?
I would copy the stuff from AutoIt, perhaps doing some re-wording where I can make things clearer (but mostly the AutoIt doc is fairly clear on Styles).
The Styles for Form are a problem: Microsoft defined them in odd ways. I can’t do much about that!
Should I create a commstyle page like commctrl?
|
|
264 | Koda | Application | Bug Report | Low | Choose Script: move from startup to Tools | Update Scri... | Unconfirmed | Chris Haslam | 23.05.2011 |
Task Description
I think that it would be more user-friendly to move Choose Script from start-up to when the info is needed, i.e. when the user first does Tools | Update Script in a session (and, of course, when more than one .au3 file uses the active form).
Choose Script would then be changed to ask: “Update which script?”. Otherwise the dialog would be the same as it is now.
Moving Choose Script would significantly help with the documentation effort. It is not documented because I haven’t thought of where to weave it in.
|
|
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) |
|
266 | Koda | Application | Feature Request | Low | Checkbox: initialize with $GUI_INDETERMINATE | Postponed | Chris Haslam | 17.05.2011 |
Task Description
When BS_3STATE is checked, Check would offer True, Indeterminate and False. If Indeterminate is too long, Gray would fit.
If the user chose Gray and subsequently unchecked BS_3STATE, Check would automatically become False.
|
|
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.
|
|
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
|
|
270 | Koda | Application | Bug Report | Low | Button: SS_RIGHTJUST available but no way of specifying... | Unconfirmed | Chris Haslam | 18.05.2011 |
Task Description
Also: should I remove mention if image from SS_CENTERIMAGE?
|
|
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.
|
|
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.
|
|
273 | Koda | Application | Bug Report | Low | Edit styles: some suggested changes | Unconfirmed | Chris Haslam | 09.06.2011 |
Task Description
I think that ES_MULTILINE should not appear in Object Inspector because an EditBox is by definition multi-line.
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 TAEdit 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 | TAEdit.
|
|
274 | Koda | Application | Bug Report | Low | Button styles: some suggested changes | Unconfirmed | Chris Haslam | 11.06.2011 |
Task Description
Microsoft and AutoIt say that BS_PUSHLIKE applies to Checkbox and Radio, but not to Button. I suggest removing it from Button.
BS_ICON and BS_BITMAP: I think these are redundant because the user tells Koda which icon or bitmap to use in Picture.
WS_GROUP, WS_VISIBLE and WS_CHILD: see discussion in FS$273
|
|
275 | Koda | Application | Bug Report | Low | Checkbox styles: some suggested changes | Unconfirmed | Chris Haslam | 06.06.2011 |
Task Description
WS_GROUP, WS_VISIBLE and WS_CHILD: see discussion in FS#273
|
|
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.
|
|
277 | Koda | Application | Bug Report | Low | Menutitem: Object Inspector shows styles and exstyles f... | Unconfirmed | Chris Haslam | 10.06.2011 |
Task Description
...chris
|
|
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.
|
|
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.
|
|
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.
|
|
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
|
|
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.
|