View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005670 | JEDI VCL | 00 JVCL Components | public | 2011-10-03 10:23 | 2012-09-10 14:15 |
| Reporter | Arioch | Assigned To | obones | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | any | OS | any | OS Version | any |
| Product Version | Daily / GIT | ||||
| Target Version | 3.45 | Fixed in Version | 3.46 | ||
| Summary | 0005670: JvFileEdit behaviour in ReadOnly=true mode | ||||
| Description | AS i created the same topic in jvcl newsgroup for faster and broader discussion. I also create the ticket, so the proposal not get lost. ---- Those two properties in TJvCustomComboEdit are not published in TJvFileDirEdit and successors. They were published in TJvComboEdit btw. property AlwaysEnableButton: Boolean read FAlwaysEnableButton write FAlwaysEnableButton default False; property AlwaysShowPopup: Boolean read FAlwaysShowPopup write FAlwaysShowPopup default False; I want to use JvFileEdit - i like its conciseness and its ability to accept files drag-n-dropped. Since i do not want extra buttons like "broswe" or "open" then i wish dialog was opened for file. But since i want file existed, i do not want free input in the edit, so i set the editbox with ReadOnly:=true; Tis results in completelypassive, label-like dialog, with a button that reacts to nothing at all. Those components may have button in "Open Dialog" or "Open drop-down list" modes. I use default "open dialog" mode. It might be understandable, while we want to supress drop-down list in read-only mode (though still questionable - we regular combobox do have "list only, not free edit" mode so why not?), but why supress the dialog ? What the sense to have dialog with button, that ignore presses ? ---- The control flow after user click is: procedure TJvCustomComboEdit.EditButtonClick(Sender: TObject); begin if (not FReadOnly) or AlwaysEnableButton then ButtonClick; end; procedure TJvCustomComboEdit.ButtonClick; begin if Assigned(FOnButtonClick) then FOnButtonClick(Self); if (FPopup <> nil) and FPopupVisible then PopupCloseUp(FPopup, True) else PopupDropDown(True); end; The PopupDropDown method in turn fires Beforedialog/AfterDialog events and does execute the dialog itself. BTW, this is the only place AlwaysEnableButton is used. The AlwaysShowPopup is very similarly used single time in procedure TJvCustomComboEdit.PopupDropDown ---- what can we do about it ? 1) publish aforementioned properties for JvFileDirEdit or derived widgets. 2) make them True by default for JvFileDirEdit or derived widgets. 3) both 1 and 2 together 4) more intelligent approaches maybe? 4.1) such as allowing edits using auto-complete, but not allowing free typing. 4.2) Or by firing the OnButtonClick events for developer use of those, yet not executing the dialog/opening the list. Personally i am for 3, though 4.1 seems fancy and challenging, and 4.2 seems the minimum required. I already said that i can't see reason behind disallowing those dialogs. And at very-very least, i can't see any logic behind suppressing OnButtonClick event then. To stir thing more, even in ReadOnly mode the editbox still accepts files drag-n-drop. So if Readonly is aimed to make the widget 100% inert (as in inert gas), then it failed. If the (strange0 goal is to make editbox a fancy lable, with non-functioning button, then IMO it can accept any drag-ndrop (and fire corresponding events) yet not change the displayed value. ---- Since the aforementioned properties used only once and for the only reason i also think their name is too vague and indescriptive. I want them be renamed SupressEnableButtonWhenReadOnly and SupressShowPopupWhenReadOnly and have true/false values inversed and have default action to allow button clicks on readonly (until the widgets can visually reder the button in "gray" disabled state - having button not reacting to presses is just confusing the user. The aforementioned properties may remain (with getter/setter linking them to new properties) for code compatibility reasons, but either: a) turned to public (not published). then TComponent.Reader should be modified for reading older DFMs, rxLib showed examples, when thy used hidden properties like "rxlib version" to choose the format of data in DFM. b) Or those properties, while remaining published, may be concealed from Object Inspector by proper registering and turned "stored false" Any interested opinions ? | ||||
| Tags | No tags attached. | ||||
|
|
Please provide the zipped sources of a sample application showing this |
|
2011-10-19 12:52
|
demo_FileEditbox.7z (65,427 bytes) |
|
2011-10-19 12:52
|
demo_fe.exe (1,014,272 bytes) |
|
|
don't know why, but TJvMemo.Lines.LoadFromStream(TFileStream) is very loooong, even for 400-bytes dpr file. Strange. But probably it is more about VCL than about JVCL, dunno. ============= this was most probably related to conflict between Delphi XE2 and TeamViewer v.6 |
|
|
Personally, in long run, i think that events should be split into two classes OnQuery-bla-bla-bla Like current AfterDialog - where developer can check upon file name and context and approve/cancel the EditBox.Text change to new value. OnFilesSelection - after it been approved, to take the very action required. This maye would also provide for other types of user "OK" action, be it Enter key strike or context menu or whatever. Currently, when one is in AfterDialog event, the JvFileEdit.FileName has older value, but when in OnDropFiles then JvFileEdit.FileName has newer value. Inconsistent and confusing. |
|
|
Published AlwaysEnableButton and AlwaysShowPopup with a default value of True so that a readonly edit can still allow selecting a file which feels more natural |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-10-03 10:23 | Arioch | New Issue | |
| 2011-10-07 16:09 | obones | Note Added: 0019015 | |
| 2011-10-07 16:09 | obones | Status | new => feedback |
| 2011-10-19 12:52 | Arioch | File Added: demo_FileEditbox.7z | |
| 2011-10-19 12:53 | Arioch | File Added: demo_fe.exe | |
| 2011-10-19 12:54 | Arioch | Note Added: 0019045 | |
| 2011-10-19 12:58 | Arioch | Note Added: 0019046 | |
| 2012-02-22 14:43 | obones | Status | feedback => acknowledged |
| 2012-02-22 22:16 | Arioch | Note Edited: 0019045 | |
| 2012-02-24 15:56 | obones | Note Added: 0019537 | |
| 2012-02-24 15:56 | obones | Status | acknowledged => resolved |
| 2012-02-24 15:56 | obones | Fixed in Version | => Daily / SVN |
| 2012-02-24 15:56 | obones | Resolution | open => fixed |
| 2012-02-24 15:56 | obones | Assigned To | => obones |
| 2012-09-10 14:15 | obones | Fixed in Version | Daily / SVN => 3.46 |
