| [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #3430
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Fl_Help_View::load() always returns 0, even on errors |
Version: | 1.4-current |
Created By: | greg.ercolano |
Assigned To: | matt |
Fix Version: | 1.4.0 |
Fix Commit: | 39a8c72c8631cf61bb468303a245f3247bc57e0a |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | greg.ercolano 13:06 Nov 04, 2017 |
| Fl_Help_View::load() advertises it returns -1 on error, but never does; the code as written returns 0 even if the file or url does not resolve.
In fact, there is a return(-1) in the code that is /commented out/. Not sure why this is.
If an html file is specified but either does not exist or can't be loaded due to permissions or some such, the return value really should be -1, reflecting the detected error, so the app can for instance try alternatives.
Not suggesting a patch, as it's not clear what the intentions are for e.g. the commented out -1 return currently in the code. Needs research. | |
|
#2 | greg.ercolano 13:21 Nov 04, 2017 |
| OK, attaching a patch suggestion simply because I need this. (Still not sure why error returns are being purposefully being squelched.) | |
|
#3 | AlbrechtS 04:09 Nov 05, 2017 |
| Just a thought: generally the return value generated by calling fl_open_uri() may not be available or not useful. For instance if a browser is executed and the file does not exist. The browser will likely keep running and won't return an error to the caller.
Since we can not always guarantee a useful return value, how can we correctly document the return value? Maybe as-is (returns always 0), or "undefined", or ... ?
Just my 2 ct. | |
|
#4 | greg.ercolano 09:46 Nov 08, 2017 |
| Still, I think we should pass back whatever errors fl_open_uri() /can/ detect, so the app can do something else, like present some alternative "hard coded" text document, instead of the "on-line" version.
In the case of fl_open_uri() not being able to find a browser, it could say:
"Couldn't open the url http://somewhere.com/foo. Open your browser and paste that url to view the document."
Regarding docs, we can just say if the return value is -1, the document was surely not opened, and could possibly elaborate that URI schemes like http: failing probably means it couldn't find a browser, and local file URLs probably means the file couldn't be opened, and strerror(errno) can be used to determine what went wrong.
It'd just be good if the application could know if the load() operation failed for any reason.. so as to perhaps provide an alternate "compiled in" document. | |
|
#5 | matt 14:46 Jan 30, 2019 |
| I fixed the return values to -1 on any kind of error. I did not change fl_open_uri(), but instead added a \see tag to the docs. If fl_open_uri indicates an error (by returning 0), ::load() will indicate the error by returning -1, as described in the docs... . | |
[ Return to Bugs & Features ]
|
| |