Discussion:
[Foxgui-users] typing in a full filename
Nuri Boardman
2016-07-12 14:47:37 UTC
Permalink
I am using fox 1.6.50 - but i checked both 1.6.51 and 1.7.56 and dont see
any relevant code that might change behavior

I am seeing different behavior between

FXFileDialog::getOpenFilenames(...)
and
FXFileDialog::getOpenFilename(...)

on the single filename version, if i type in a file that exists
(c:\file_that_really_exists)
it accepts the input

on the multiple filename version, if i type in the same thing, i get an
FXBeep

It feels like the issue is coming from FXFileSelector::getFilename()

for getOpenFilenames(...)
the selectmode==SELECTFILE_MULTIPLE
so we go inside that if statement, we loop over all the items currently
being shown in the window - but nothing is selected, so we end up returning
FXString::null

where as for getOpenFilename(...)
we skip the first 2 if statements, the !filename->getText().empty() passes,
and we return a good value


my initial thought was just to comment out the else
and make that logic happen if we dont find anything thats selected above
however for multiple files, i believe it should be possible to set a string
of

"C:\file1_that_exists" "c:\file2_that_exists" and have that work correctly

any assistance the community can provide would be very helpful
thanks

Nuri
Nuri Boardman
2016-08-05 22:40:20 UTC
Permalink
anyone?
Post by Nuri Boardman
I am using fox 1.6.50 - but i checked both 1.6.51 and 1.7.56 and dont see
any relevant code that might change behavior
I am seeing different behavior between
FXFileDialog::getOpenFilenames(...)
and
FXFileDialog::getOpenFilename(...)
on the single filename version, if i type in a file that exists
(c:\file_that_really_exists)
it accepts the input
on the multiple filename version, if i type in the same thing, i get an
FXBeep
It feels like the issue is coming from FXFileSelector::getFilename()
for getOpenFilenames(...)
the selectmode==SELECTFILE_MULTIPLE
so we go inside that if statement, we loop over all the items currently
being shown in the window - but nothing is selected, so we end up returning
FXString::null
where as for getOpenFilename(...)
we skip the first 2 if statements, the !filename->getText().empty()
passes, and we return a good value
my initial thought was just to comment out the else
and make that logic happen if we dont find anything thats selected above
however for multiple files, i believe it should be possible to set a
string of
"C:\file1_that_exists" "c:\file2_that_exists" and have that work correctly
any assistance the community can provide would be very helpful
thanks
Nuri
JVZ
2016-08-09 19:46:33 UTC
Permalink
On Fri, 5 Aug 2016 18:40:20 -0400
Post by Nuri Boardman
anyone?
Post by Nuri Boardman
I am using fox 1.6.50 - but i checked both 1.6.51 and 1.7.56 and dont see
any relevant code that might change behavior
I am seeing different behavior between
FXFileDialog::getOpenFilenames(...)
and
FXFileDialog::getOpenFilename(...)
on the single filename version, if i type in a file that exists
(c:\file_that_really_exists)
it accepts the input
on the multiple filename version, if i type in the same thing, i get an
FXBeep
It feels like the issue is coming from FXFileSelector::getFilename()
for getOpenFilenames(...)
the selectmode==SELECTFILE_MULTIPLE
so we go inside that if statement, we loop over all the items currently
being shown in the window - but nothing is selected, so we end up returning
FXString::null
where as for getOpenFilename(...)
we skip the first 2 if statements, the !filename->getText().empty()
passes, and we return a good value
my initial thought was just to comment out the else
and make that logic happen if we dont find anything thats selected above
however for multiple files, i believe it should be possible to set a
string of
"C:\file1_that_exists" "c:\file2_that_exists" and have that work correctly
any assistance the community can provide would be very helpful
thanks
Noted!

Currently, type-in textfield is populated by FXFileList's selection callback, so
that whatever you select is placed in the text field.

Maybe I can just return contents of the text field; if you've selected multiple
files, then the textfield contains multiple filenames, separated by spaces.

Thus, filenames with spaces would have to be encoded in this case, as filenames
with spaces would need to be distinguishable from quoted filenames.

I believe maybe the logic should be as follows (pls try to punch holes in this
before I implement it!):

1) single filename or directory select should work as now.

2) multiple select mode will place quoted filenames in text box; perhaps
we can quote only when needed, i.e. filenames contain spaces or quotes.

3) Then getFileName() would check mode, and so as follows:

- Return first selected name only, dequote if in multiple select mode.

4) And getFileNames() would:

- Return list of only one single filename if single select mode.

- Return list of filenames, dequoted if in multiple select mode.

Possible problems:

- We would allow user to enter filenames "by hand" into the textbox, even
in multiple select mode.

- User may have used quotes incorrectly. To prevent issues, dequoting
procedure should insist of processing the entire input, and return
either empty filename [getFilename()] or empty list [getFilenames()] if
there's a syntax error.


Other options:

- Always display enquoted filename in text field. This is an easier rule,
but would force people to enquote filenames containing spaces.

- Perhaps its OK to not insist on quoting if we're in single selection mode.

- Perhaps we can have a flag to force quoting, and it'd be true always in
multiple selection mode, and optionally on when in single selection mode.

- Flag could be handy for entering unusual filenames, e.g. non-printing
characters.


Any feedback?


-- JVZ




+----------------------------------------------------------------------------+
| Copyright (C) 14:10 08/ 9/2016 Jeroen van der Zijp. All Rights Reserved. |
+----------------------------------------------------------------------------+
Jeff Pohlmeyer
2016-08-11 05:24:57 UTC
Permalink
...
Post by JVZ
Post by Nuri Boardman
anyone?
...
Post by JVZ
Any feedback?
In FXiTe text editor I added an extra button [M] in the top
right-hand corner of the file open dialog to toggle between
[M]anual entry and [M]ultiple selection.

Not saying this is the best solution, just another option...

https://github.com/yetanothergeek/fxite/blob/master/src/filedlg.h#L29
https://github.com/yetanothergeek/fxite/blob/master/src/filedlg.cpp#L219


- Jeff
Nuri Boardman
2016-08-11 22:46:14 UTC
Permalink
when i was thinking about how to work around the current issue,
I thought of the following as a better design.
Instead of delaying assembling the list of files until the user calls
getFilenames()

i would have instead made a vector<FX::FXString>variables internal to the
FXFileDialog.
anytime the user changes the selection of selected files, i would update
that vector.
and then from the vector i would create the text for the textfield

and if the user typed text into the textfield, i would put parse that, and
populate the same vector
validation of user input could occur at this point if desired.

this way your never forced to re-parse the text field just to return the
answer.

the logic for a select 1 file vs a select many file names, should then only
be handled in populating the vector
and returning 1 file would just be vector[0]

that doesnt address all the issues you brought up

what if the user enters
"c:\fileThatExists" "C:\fileThatDoesntExist"

or
"\\uncPath\That\Exists" "\\uncPath\That\Does not Exist"

should the values the user enters be accepted even if the file or path
doesn't exist?
what if one does exist and one doesn't?

it gets very complicated in a hurry
Post by JVZ
On Fri, 5 Aug 2016 18:40:20 -0400
Post by Nuri Boardman
anyone?
Post by Nuri Boardman
I am using fox 1.6.50 - but i checked both 1.6.51 and 1.7.56 and dont
see
Post by Nuri Boardman
Post by Nuri Boardman
any relevant code that might change behavior
I am seeing different behavior between
FXFileDialog::getOpenFilenames(...)
and
FXFileDialog::getOpenFilename(...)
on the single filename version, if i type in a file that exists
(c:\file_that_really_exists)
it accepts the input
on the multiple filename version, if i type in the same thing, i get an
FXBeep
It feels like the issue is coming from FXFileSelector::getFilename()
for getOpenFilenames(...)
the selectmode==SELECTFILE_MULTIPLE
so we go inside that if statement, we loop over all the items currently
being shown in the window - but nothing is selected, so we end up
returning
Post by Nuri Boardman
Post by Nuri Boardman
FXString::null
where as for getOpenFilename(...)
we skip the first 2 if statements, the !filename->getText().empty()
passes, and we return a good value
my initial thought was just to comment out the else
and make that logic happen if we dont find anything thats selected above
however for multiple files, i believe it should be possible to set a
string of
"C:\file1_that_exists" "c:\file2_that_exists" and have that work
correctly
Post by Nuri Boardman
Post by Nuri Boardman
any assistance the community can provide would be very helpful
thanks
Noted!
Currently, type-in textfield is populated by FXFileList's selection callback, so
that whatever you select is placed in the text field.
Maybe I can just return contents of the text field; if you've selected multiple
files, then the textfield contains multiple filenames, separated by spaces.
Thus, filenames with spaces would have to be encoded in this case, as filenames
with spaces would need to be distinguishable from quoted filenames.
I believe maybe the logic should be as follows (pls try to punch holes in this
1) single filename or directory select should work as now.
2) multiple select mode will place quoted filenames in text box; perhaps
we can quote only when needed, i.e. filenames contain spaces or quotes.
- Return first selected name only, dequote if in multiple select mode.
- Return list of only one single filename if single select mode.
- Return list of filenames, dequoted if in multiple select mode.
- We would allow user to enter filenames "by hand" into the textbox, even
in multiple select mode.
- User may have used quotes incorrectly. To prevent issues, dequoting
procedure should insist of processing the entire input, and return
either empty filename [getFilename()] or empty list
[getFilenames()] if
there's a syntax error.
- Always display enquoted filename in text field. This is an easier rule,
but would force people to enquote filenames containing spaces.
- Perhaps its OK to not insist on quoting if we're in single selection mode.
- Perhaps we can have a flag to force quoting, and it'd be true always in
multiple selection mode, and optionally on when in single selection mode.
- Flag could be handy for entering unusual filenames, e.g. non-printing
characters.
Any feedback?
-- JVZ
+-----------------------------------------------------------
-----------------+
| Copyright (C) 14:10 08/ 9/2016 Jeroen van der Zijp. All Rights Reserved. |
+-----------------------------------------------------------
-----------------+
Loading...