>> I can't say that I am very happy with a non-closing close() and a lying
isOpen(). Even if documented, it goes against any expectations.
I disagree, then You would have
QTemporaryFile attached to file which is not anymore
under control.
This would be even more confusing and made documented features wrong:
"the file will subsequently be removed upon destruction of the
QTemporaryFile object."
"Detaching" could be made in close(), but in this case you leave useless
now QTemporaryFile alive.
I think current implementation is less alone prone.
What can be done - I would override close just to make it private, so
people do not call it.
Regards,
Alex
On Fri, Aug 23, 2013 at 11:50 AM, Guido Seifert <warg...@gmx.de> wrote:
>
> > open() means it succeeded in opening.
> >
> > QTemporaryFile::close() truncates and repositions, but doesn't *close*
> the
> > file. If you really want to close, destroy the object or force it to
> open a new
> > file (with a new name).
>
> Bah, stupid me. Wrong function. I meant of course 'isOpen()', sorry. Am I
> so wrong that I expect a 'true' when the file is still open?
>
> But, erm... yes... now that you say it, I can even find this behaviour in
> the docs:
>
> Reopening a QTemporaryFile after calling close() is safe. For as long as
> the QTemporaryFile object itself is not destroyed, the unique temporary
> file will exist and be kept open internally by QTemporaryFile.
>
> I can't say that I am very happy with a non-closing close() and a lying
> isOpen(). Even if documented, it goes against any expectations.
>
> Guido
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
