FLTK logo

STR #3430

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 greg.ercolano
13:21 Nov 04, 2017
Fl_Help_View_return_errors.patch
2k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.