View Issue Details

IDProjectCategoryView StatusLast Update
0005670JEDI VCL00 JVCL Componentspublic2012-09-10 14:15
ReporterAriochAssigned Toobones 
Status resolvedResolutionfixed 
PlatformanyOSanyOS Versionany
Product VersionDaily / GIT 
Target Version3.45Fixed in Version3.46 
Summary0005670: JvFileEdit behaviour in ReadOnly=true mode
DescriptionAS 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);
  if (not FReadOnly) or AlwaysEnableButton then

procedure TJvCustomComboEdit.ButtonClick;
  if Assigned(FOnButtonClick) then

  if (FPopup <> nil) and FPopupVisible then
    PopupCloseUp(FPopup, True)

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 ?
TagsNo tags attached.



2011-10-07 16:09

administrator   ~0019015

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)


2011-10-19 12:54

developer   ~0019045

Last edited: 2012-02-22 22:16

don't know why, but TJvMemo.Lines.LoadFromStream(TFileStream) is very loooong, even for 400-bytes dpr file.


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


2011-10-19 12:58

developer   ~0019046

Personally, in long run, i think that events should be split into two classes

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.


2012-02-24 15:56

administrator   ~0019537

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

Issue History

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