Re: new waitbar function

[John W. Eaton]

On  3-Nov-2011, Rik wrote:

| I just checked in some useful changes here
| (http://hg.savannah.gnu.org/hgweb/octave/rev/b3cdef33ac0e).
| 
| Summary :
| The docstring has been expanded and now more of the possible calling forms
| are listed

Thanks.

| The created handle, h, is no longer returned if nargout is 0 (just calling
| waitbar(...) on command line)

OK, if that is what Matlab is doing, then I guess we should too or
Octave will likely generate a lot of spurious "ans = ..." output when
Matlab does not.  It's not really important, but I thought it was
somewhat conveneint to have the handle returned anyway.  Because the
figure handle has the visibility property set to "callback" neither
"close" nor "close all" will close the figure. So it can be helpful to
be able to grab the handle value from "ans" if you forget to assign
the handle when you first call waitbar.

| The calling forms 'waitbar (FRAC)' or 'waitbar (FRAC, H)' no longer delete
| the text message.  This allows
| you to set the text message once at the start and then just adjust the fill
| value of the slider.

| Added input validation tests for completeness.

Thanks.

| One calling form they allow is 'waitbar (FRAC)' which updates the length of
| the *current* waitbar.  It would be nice to support that, but I'm not sure
| how they are doing it.  Are they using a persistent variable to remember
| the waitbar handle?  Or do they always just use the current figure and
| check whether there is a waitbar for updating?

The waitbar does not become the current figure.  That way, if you do

  figure (...)
  waitbar (...);
  gcf

then gcf gives you the handle of the actual figure object, the same as
if there is no waitbar.  I think that to do otherwise would be pretty
confusing.  So a persistent variable would probably solve the problem.

Also, I see that with fltk,

  patch ([0, 1, 1, 0], [0, 0, 1, 1], [1, 0, 0]);  ## blue
  patch ([0, 1, 1, 0], [0, 0, 1, 1], [0, 1, 0]);  ## red
  patch ([0, 1, 1, 0], [0, 0, 1, 1], [0, 0, 1]);  ## blue

What's going on with that?  I guess a small indexing error, but I
don't know where to look.

Wow, this apparently simple little function turned up a lot of twisty
little craziness.

jwe