| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #810
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Fl_File_Chooser value(const char*) not wholly functional |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | Natevw |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | Will Not Fix |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | Natevw
08:34 Apr 16, 2005 |
| Fl_File_Chooser does not select files that are passed using value() when the chooser is not loaded. When this occurs, the filename is not even shown in the input box, though the correct path is selected.
For the purpose of saving files, if the string passed to value() doesn't start with a drive letter or slash, it should be appended to the chooser's current directory. The attached program should demonstrate what I mean.
-nvw | |
| |
| #2 | matt
01:06 Jul 26, 2005 |
| I looked through this for a while and I do see your issues. I decided to not fix these because they will have an impact on how the whole File_Chooser works and may disturb too many existing applications. For FLTK2, we must definetly rethink some of the interface.
In detail:
The first issue, '\' vs. '/', was already fixed by an earlier STR.
The second issue, setting Fl_File_Chooser::value("..") is reduced to setting only a directory during '::show()' is true and unfortunate, but changing this would change the way that '::directory()' works. There is an easy workaround though. This sequence works well:
chooser.directory("C:\\Windows\\System\\");
chooser.show();
chooser.value("C:\\Windows\\System\\COMMDLG.DLL");
...
Sorry for the inconvinence.
Issue 3, to be able to first set a directory, then add a relative filepath, is again logical and nice to have, but would change the existing API too much IMHO.
I'll leave this item open for a week or so, and if another developer comes up with a good solution, I'll be happy to implement that.
Matthias | |
| |
| #3 | Natevw
13:20 Jul 26, 2005 |
| I definitely agree...issues two and three can be taken care of easily enough on the application side.
Perhaps we should make a note of issue #2 in the docs, but after that closing this STR is fine by me.
thanks,
-nate | |
| |
| #4 | matt
07:17 Aug 15, 2005 |
| Close because the issues are easily avoidable, plus fixing them would be opening up trouble in existing software. Sorry! [UPDATE: erco 11/25/14: this text from Matt seems unintentional, see comment #7] | |
| |
| #5 | matt
12:41 Apr 22, 2008 |
| Must verify. | |
| |
| #6 | Natevw
16:57 Apr 22, 2008 |
| Hello old friends! Do I need to verify the close of this bug, or am I misinterpreting the last annotation? | |
| |
| #7 | matt
17:40 Apr 22, 2008 |
| Hi there! No, this is only a note to the maintainer. Now that we reached 1.3, we walk through all existing bug reports that weren't succesfully closed and decide if we can find a solution now that we can break the ABI.
Admittedly, after updating a hundred or so STRs, I got quite sloppy about the comments ;-) | |
| |
| #8 | matt
15:38 Feb 02, 2023 |
| Won't fix | |
[ Return to Bugs & Features ]
|
| |
