Project JEDI - Issue Tracker
Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005670 [JEDI VCL] 00 JVCL Components feature always 2011-10-03 10:23 2012-09-10 14:15
Reporter Arioch View Status public  
Assigned To obones
Priority normal Resolution fixed  
Status resolved   Product Version Daily / GIT
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 ?
Additional Information
Tags No tags attached.
Attached Files 7z file icon demo_FileEditbox.7z [^] (65,427 bytes) 2011-10-19 12:52
? file icon demo_fe.exe [^] (1,014,272 bytes) 2011-10-19 12:52

- Relationships

-  Notes
(0019015)
obones (administrator)
2011-10-07 16:09

Please provide the zipped sources of a sample application showing this
(0019045)
Arioch (developer)
2011-10-19 12:54
edited on: 2012-02-22 22:16

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

(0019046)
Arioch (developer)
2011-10-19 12:58

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.
(0019537)
obones (administrator)
2012-02-24 15:56

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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker