Does the destructor of Fl_Window ever get called?

[Steve Maas]

Hi,

Sorry to keep bugging you with Fl_Window issues, but I think I found another one. It seems that the destructor of a class derived from Fl_Window never gets called. Consider this test program.

#include <FL/Fl_Window.H>
#include <FL/Fl.H>
#include <FL/fl_message.H>

class MyWindow : public Fl_Window
{
public:
 MyWindow(int X, int Y, int W, int H) : Fl_Window(X, Y, W, H){}
 MyWindow(int W, int H) : Fl_Window(W, H, "Hello"){}
 ~MyWindow()
 {
  fl_message("Inside Destructor");
 }
};

int main(int nargs, char** argv)
{
 MyWindow* pw = new MyWindow(300, 300);
 {
  MyWindow* pw2 = new MyWindow(0, 0, 300, 300);
  pw2->end();
  pw2->box(FL_FLAT_BOX);
  pw2->color(FL_RED);
 }
 pw->end();
 pw->show();

 return Fl::run();
}

The destructor never gets called. Not for the main window, not for the child window. I think this may be another bug in fltk.

Best,

Steve

[Greg Ercolano]

On 11/25/14 11:56, Steve Maas wrote:
> The destructor never gets called. Not for the main window, not for the child window. I think this may be another bug in fltk.

Not sure if it's a bug or a feature; make this one change to the main window
and then it works for both:

- MyWindow* pw = new MyWindow(300, 300);
+ MyWindow pw(300, 300);
- pw->end();
- pw->show();
+ pw.end();
+ pw.show();

This forces pw to go out of scope, and that tears down the inner (red) window too.

Not sure if FLTK should go out of its way to delete the 'new MyWindow' instance
created at the top of main when it returns out of main() or not.. might be an omission,
or it might not know if the instance was created with 'new' or not..

[Ian MacArthur]

How sure are you that the destructor is not called, though?

I haven’t run this, but just staring at the code, I think you'd expect to see the fl_message box pop up when the destructors runs, is that right?

But... the window will not be destroyed until it goes out of scope, and it will not go out of scope until after Fl::run() has returned.

But if Fl::run() has returned, the fltk event loop is no longer running, so the call to fl_message might not do anything... Or does fl_message pump its own event loop? Hmm, dunno.


Anyway, for widgets that only take memory as in this case, that will be reaped on process exit (and rather more efficiently than walking the destructor lists would) so it is not like it’s a leak or anything.
There are quite a few places in fltk where we deliberately defer to process cleanup to reap memory and related resources on program exit, it's one of those “fast light” things, so it is often “by design” rather than “by accident” that this happens.

Of course, if the derived widget was taking some resource that can not be easily reaped automatically, then we’d really want the destructor to be called, though I guess in that case the programmer would want to call it explicitly anyway to be on the safe side!

[Greg Ercolano]

On 11/25/14 14:53, Ian MacArthur wrote:
> How sure are you that the destructor is not called, though?

I tested with fprintf(stderr) and it isn't called either.

I think because it's a top level window created with 'new', no destructor is called
because nothing is triggering a 'delete' for the window. You might think FLTK would
do that, but it seems not to. And can't help but wonder if it doesn't because FLTK
can't know whether the window was created with new or as an automatic. (Heap vs. stack)

> But if Fl::run() has returned, the fltk event loop is no longer running, so the call to fl_message might not do anything...

fl_message() and fl_ask() I believe pumps its own event loop.
But you can replace his code with fprintf() and you'll get the same result.

What works is if the Fl_Window goes out of scope; then it tears down itself
and the child window.

But other than doing an explicit delete, I don't think you can expect FLTK
to destroy the window if created with new, for the reason cited above;
that we support automatic as well as 'new' constructions.

> so it is not like it’s a leak or anything.

Right, though he may be more concerned about using the dtor to deallocate
non-memory stuff (like files or some such, who knows.. arguably should rely
on calling delete or some other mechanism for cleanup, e.g. atexit(3).

> Of course, if the derived widget was taking some resource that can not be easily reaped automatically, then we’d really want the destructor to be called, though I guess in that case the programmer would want to call it explicitly anyway to be on the safe side!

Right.. I guess though FLTK offers a perhaps confusing behavior to the user;
it handles teardown of widgets and 'new' allocations in other contexts. But not when it's a parent window..

[Greg Ercolano]

On 11/25/14 15:04, Greg Ercolano wrote:
>> Of course, if the derived widget was taking some resource that can
>> not be easily reaped automatically, then we’d really want the destructor
>> to be called, though I guess in that case the programmer would want to
>> call it explicitly anyway to be on the safe side!
>
> Right.. I guess though FLTK offers a perhaps confusing behavior to the user;
> it handles teardown of widgets and 'new' allocations in other contexts.
> But not when it's a parent window..

Or I should say it 'seems' clear.

I don't think FLTK does teardown unless triggered by a destructor,
which makes C++ sense.

If a window is destroyed, all the child widgets created with new
are destroyed.

But top level windows are not destroyed automatically by FLTK,
a destructor has to be invoked.. and the only way that'll happen
if the window is created with 'new' is if it's delete'ed.

[Albrecht Schlosser]

On 26.11.2014 00:18, Greg Ercolano wrote:

>> Right.. I guess though FLTK offers a perhaps confusing behavior to the user;
>> it handles teardown of widgets and 'new' allocations in other contexts.

Only if the widget is a child of another widget/window and that window
gets deleted. No magic here.

>> But not when it's a parent window..

Only if it gets destroyed with delete. No magic either.

> Or I should say it 'seems' clear.
>
> I don't think FLTK does teardown unless triggered by a destructor,
> which makes C++ sense.

Yup.

> If a window is destroyed, all the child widgets created with new
> are destroyed.

Remove "created with new" from this sentence. FLTK does not know how a
child widget was created. There is a note in the docs in ~Fl_Group():

<http://www.fltk.org/doc-1.3/classFl__Group.html#a9a71aac1ca586825ff0c790f8f99f9cf>

(1) "It is allowed that the Fl_Group and all of its children are
automatic (local) variables, but you must declare the Fl_Group
first, so that it is destroyed last."

(2) "If you add static or automatic (local) variables to an Fl_Group,
then it is your responsibility to remove (or delete) all such static
or automatic child widgets before destroying the group - otherwise
the child widgets' destructors would be called twice!"

Regarding (1): This works because child widgets remove themselves from
their parents when they are destroyed with delete or when they are going
out of scope.

Regarding (2): If you add a static or local (automatic) variable (widget
object) to the group and destroy the group (with delete or by going out
of scope), then the group will (try to) delete that child widget. See
the attached file dbl_del.cxx for an example how this can crash the demo
program. The test scenario and output under Linux is documented in this
file. It took a while, but it was fun to write the program and to see
how it behaves under Linux (Fedora 19).

BTW: the same program runs "w/o error" under Windows (compiled with
MinGW g++). I only show the failure mode here (see dbl_del.cxx for how
the program behaves under Fedora 19):

$ ./dbl_del.exe
Fl::run() returned 0
delete window...
MyButton 'close me' deleted.
MyButton 'remove me' deleted. <-- Button deleted once
window deleted, returning now...
MyButton 'remove me' deleted. <-- Button deleted twice

> But top level windows are not destroyed automatically by FLTK,
> a destructor has to be invoked.. and the only way that'll happen
> if the window is created with 'new' is if it's delete'ed.

Absolutely correct. This does not happen in the OP's demo program.

[Albrecht Schlosser]

On 26.11.2014 00:04, Greg Ercolano wrote:
> On 11/25/14 14:53, Ian MacArthur wrote:
>> How sure are you that the destructor is not called, though?
>
> I tested with fprintf(stderr) and it isn't called either.

True.

> I think because it's a top level window created with 'new', no destructor is called
> because nothing is triggering a 'delete' for the window. You might think FLTK would
> do that, but it seems not to. And can't help but wonder if it doesn't because FLTK
> can't know whether the window was created with new or as an automatic. (Heap vs. stack)

FLTK only "knows" about windows that are shown(), because it has an
internal list. It needs this list for event handling and drawing.
Whenever you hide() a window FLTK removes the window from the list. FLTK
has no memory of that window anymore (no pointer, no list, nothing).

>> But if Fl::run() has returned, the fltk event loop is no longer running, so the call to fl_message might not do anything...
>
> fl_message() and fl_ask() I believe pumps its own event loop.

Yes, they do.

> But you can replace his code with fprintf() and you'll get the same result.

Yup.

> What works is if the Fl_Window goes out of scope; then it tears down itself
> and the child window.

True, but it must be a local or static variable to "go out of scope".

> But other than doing an explicit delete, I don't think you can expect FLTK
> to destroy the window if created with new, for the reason cited above;

Absolutely.

> that we support automatic as well as 'new' constructions.
>> so it is not like it’s a leak or anything.

Well, formally it is a leak. But a leak in the responsibility of the
programmer who allocates an object with new but doesn't delete it. FLTK
has nothing to do with this.

> Right, though he may be more concerned about using the dtor to deallocate
> non-memory stuff (like files or some such, who knows.. arguably should rely
> on calling delete or some other mechanism for cleanup, e.g. atexit(3).

It's the programmer's responsibility.

>> Of course, if the derived widget was taking some resource that can not be easily reaped automatically, then we’d really want the destructor to be called, though I guess in that case the programmer would want to call it explicitly anyway to be on the safe side!

There's no other way.

> Right.. I guess though FLTK offers a perhaps confusing behavior to the user;

No, that should not be confusing. See below.

> it handles teardown of widgets and 'new' allocations in other contexts.

This context is if you add a widget to a group or window, and this is
documented behavior. Imagine that the programmer transfers ownership of
the object to the group. Whenever the object is removed from the group,
ownership is transferred back to "the program". The widget is only
deleted if the group (or window) is deleted. But this doesn't happen
automatically for objects created with new.

> But not when it's a parent window..

Sure. But that's not surprising, because FLTK doesn't manage a list of
window objects (except those that are shown()).

[Albrecht Schlosser]

On 25.11.2014 20:56, Steve Maas wrote:

> It seems that the destructor of a class derived
> from Fl_Window never gets called. Consider this test program.
>
> #include <FL/Fl_Window.H>
> #include <FL/Fl.H>
> #include <FL/fl_message.H>
> class MyWindow : public Fl_Window
> {
> public:
> MyWindow(int X, int Y, int W, int H) : Fl_Window(X, Y, W, H){}
> MyWindow(int W, int H) : Fl_Window(W, H, "Hello"){}
> ~MyWindow()
> {
> fl_message("Inside Destructor");
> }
> };
> int main(int nargs, char** argv)
> {
> MyWindow* pw = new MyWindow(300, 300);
> {
> MyWindow* pw2 = new MyWindow(0, 0, 300, 300);
> pw2->end();
> pw2->box(FL_FLAT_BOX);
> pw2->color(FL_RED);
> }
> pw->end();
> pw->show();
> return Fl::run();
> }
>
> The destructor never gets called. Not for the main window, not for the
> child window. I think this may be another bug in fltk.

This is correct behavior. You allocate the windows with new, so they are
only destroyed if you 'delete' them explicitly. See also Greg's reply in
this thread and my reply to Greg's posting with another fun demo program
to a related topic (double deletes).

[Greg Ercolano]

On 11/25/14 17:17, Albrecht Schlosser wrote:
>> But top level windows are not destroyed automatically by FLTK,
>> a destructor has to be invoked.. and the only way that'll happen
>> if the window is created with 'new' is if it's delete'ed.
>
> Absolutely correct. This does not happen in the OP's demo program.

Ya, so nothing wrong here, I don't think.

This seems consistent with C++'s normal behavior of
what happens when one return()'s out of main();
an FLTK window behaves like a normal C++ class
if the class is..

* Created as an automatic, the dtor gets called
when it goes out of scope.

* Created with 'new', the dtor is *not* called
unless the class is explicitly delete'ed.

Neither a return() from main() or an exit() call will trigger
dtors of an object created with 'new'; there needs to be an
explicit 'delete'.

OP, let me know if we're missing something, or if there
needs to be doc clarification. (and if so, where and what)

[Steve Maas]

Hi everyone,

Thanks for the very interesting responses. So, the solution seems to be either to use a local variable for the main window or making sure the delete operator is called before the program ends. Okay, that solves the problem for the main window, but you can create other windows while the program is running. How do you guarantee that the destructors of these other windows are called? Even more, I want the destructor to be called when the window is closed.

I tried to delete the window from its callback routine. That seems to work, but only if the user closes the window. When I try to close the windows by calling hide() on all open windows, it looks like the callback isn't done and thus deleting the window during its callback won't work. Any suggestions for making sure the destructors of all windows gets called, either when the user closes the window or when the program terminates?

Thanks,

Steve

[Albrecht Schlosser]

On 26.11.2014 06:03 Steve Maas wrote:

> Thanks for the very interesting responses. So, the solution seems to be
> either to use a local variable for the main window or making sure the
> delete operator is called before the program ends. Okay, that solves the
> problem for the main window, but you can create other windows while the
> program is running. How do you guarantee that the destructors of these
> other windows are called? Even more, I want the destructor to be called
> when the window is closed.

As with all other objects you create during the runtime of a program,
you (the programmer) are responsible for deleting the objects or you can
let the system clean up for you. The latter means that there will be no
memory leaks unless you create objects frequently and don't delete them,
but if you require d'tors to be called for cleanup tasks, then you must
do this yourself. There's nothing FLTK can do for you.

> I tried to delete the window from its callback routine. That seems to
> work, but only if the user closes the window. When I try to close the
> windows by calling hide() on all open windows, it looks like the
> callback isn't done and thus deleting the window during its callback
> won't work.

If _you_ call hide() and want the window to be deleted, I can recommend
one of these options:

(1) window->hide(); delete window;

(2) delete window; // will do hide() before deleting the object

(3+4) replace 'delete window;' with 'Fl::delete_widget(window);'

> Any suggestions for making sure the destructors of all
> windows gets called, either when the user closes the window or when the
> program terminates?

No, not really. It's your program's choice to delete its objects (or
not). However, some suggestions:

Maybe you can try to derive your own window class and catch the FL_HIDE
event in its handle() method, then combine everything given so far.

If I wanted to make sure that all window objects are deleted eventually
I would manage my own window list, combine all techniques known so far,
and remove deleted winodws from the list. At program exit you can use
atexit() to scan the list and delete all remaining windows.

Instead of using atexit() you can also use a static (or automatic)
object (class instance) of a "window list class" in main() whose d'tor
will be called after the main() program returns. One often used way is
to use an "application" class as an automatic instance in main() that
manages all its resources in internal variables and lists.

There are many, many options...

However this is all "normal" OO programming, and FLTK is not different
in this regard, except where documented - just as in other class libraries.

[Steve Maas]

Okay, fair enough, users are responsible for deleting the objects they create. That makes sense, but two small comments:

 

1) The documentation does not reflect this (unless I missed it). In fact, the very first example in the online manual does not delete the window object. Neither does any of the test examples (unless I missed it) that dynamically allocates the main window. Consequently, users could easily get the impression that FLTK cleans up after itself (as so many other GUI toolkits do) which, as is now clear, is not the case.

2) When you say "let the system clean up for you", you should clarify that the system in fact does not clean up for you. It does not call delete, or the destructors, or closes resources properly. As far as I understand, it just reclaims the resources in a rather brute force manner, which is definitely not something a developer should rely on as a mechanism to properly de-allocate resources. Now, I'm sure you knew this, but what I'm saying is that I don't think this is a programming practice that should be promoted as it could very easily lead to problems. In my opinion, if FLTK is not going to provide an automatic clean up mechanism it should stick to good C++ programming practices through its documentation and examples. Sorry, I'm somewhat of a C++ purist in that regard. But, of course, that's just my humble opinion.

Thanks to all for taking the time to respond!

Best,

Steve

[Ian MacArthur]

On Wed Nov 26 2014 05:03:11, Steve Maas wrote:

> How do you guarantee that the destructors of these other windows are called? Even more, I want the destructor to be called when the window is closed.

Can I ask why?

If the widget is only memory (i.e. it’s not locking any persistent resources or anything) and has a lifetime that mirrors that of the application, then it will be reaped by process cleanup when the app exits anyway, so explicitly triggering the destructor may not bring any advantage...

[Steve Maas]

I'm working on an application where users can bring up windows to generate plots. I do not know in advance how many and once the user is done with the window, there is no point to bring that same window back, so I want to make sure all resources allocated by that window are cleaned up (including the window itself). (It actually works similar to how Matlab generates and manages figures, as far as I understand). In other words, in this particular application, the window's lifetime is much shorter than the application's lifetime. I hope that answers your question.

Best,

Steve 

[Albrecht Schlosser]

On 26.11.2014 21:41 Steve Maas wrote:
> Okay, fair enough, users are responsible for deleting the objects
> they create. That makes sense, but two small comments:
>
> 1) The documentation does not reflect this (unless I missed it).

This is basic OOP knowledge, no need to say.

> In fact, the very first example in the online manual does not delete the
> window object. Neither does any of the test examples (unless I missed
> it) that dynamically allocates the main window.

You may like it or not, but this is "The FLTK Way". This has been
discussed many times before. Since FLTK has no knowledge how an object
has been created (new, local/automatic, static) FLTK _can not_ delete
objects (particularly Windows) when the program ends. There are usual
OOP mechanisms that work as everywhere (going out of scope calls the
d'tor), but for windows created with new there is no way for FLTK to
know when to delete them. And, to emphasize the 'L' in FLTK: FLTK is the
"Fast Light Tool Kit". Its philosophy is not to create bloat for
managing stuff that can be managed in user code. FLTK does not maintain
a list of window objects because it is not needed by FLTK. Only windows
that are shown are managed internally by FLTK.

> Consequently, users
> could easily get the impression that FLTK cleans up after itself (as so
> many other GUI toolkits do) which, as is now clear, is not the case.

Okay, that impression would be wrong as far as destructors are
concerned. However, it is often better NOT to call destructors at the
end of the program because this would take unnecessary long for no
effect. If you need d'tors you are free to do what you want to
guaranteee that they are called (and you should do that). Again: you are
responsible for the objects you created.

> 2) When you say "let the system clean up for you", you should clarify
> that the system in fact does not clean up for you. It does not call
> delete, or the destructors, or closes resources properly.

Be fair! I did exactly that: "As with all other objects you create

during the runtime of a program, you (the programmer) are responsible
for deleting the objects or you can let the system clean up for you. The
latter means that there will be no memory leaks unless you create
objects frequently and don't delete them, but if you require d'tors to
be called for cleanup tasks, then you must do this yourself. There's
nothing FLTK can do for you."

Please read the 2nd sentence of the cited paragrah again.

> As far as I
> understand, it just reclaims the resources in a rather brute force
> manner, which is definitely not something a developer should rely on as
> a mechanism to properly de-allocate resources.

Sorry, it is exactly that what has been said often before. We do not
recommend "reclaiming" all objects by calling all destructors at the end
of the program. That does not mean that YOU should not do it for objects
that are worth it, for instance if you have open files and such. But
that's a different story. Here is an example: we have to allocate font
structures so that text can be rendered during runtime. We do NOT free
font structures when the program terminates. All memory will be released
by the OS, unless documented otherwise. Sometimes we allocate memory for
something that will be used frequently during runtime. We do not release
this memory, because it will be reused later. free()ing and malloc()ing
(or delete and new) are just a waste of CPU cycles in this case. Hence
memory check programs will report a memory leak. We consider this a
false positive.

> Now, I'm sure you knew
> this, but what I'm saying is that I don't think this is a programming
> practice that should be promoted as it could very easily lead to
> problems. In my opinion, if FLTK is not going to provide an automatic
> clean up mechanism it should stick to good C++ programming practices
> through its documentation and examples. Sorry, I'm somewhat of a C++
> purist in that regard. But, of course, that's just my humble opinion.

You can be sure that we take care of deleting structures that are worth
it during runtime of the program. But we do deliberately not delete
objects before terminating the program, unless this is necessary or done
by automatic destructors. We consider memory leaks only if they increase
during runtime, but not if a memory resource is not free()d before
program exit. Whenever we get reports of memory leaks (usually created
by using valgrind or similar) we do check it and fix it, if it is a
memory leak. Really.

One last point to this "end of program" and cleanup discussion. FLTK
does not have the information when a program will be terminated. When
Fl::run() terminates this does not mean that the end of the program is
near. You can create new windows, call Fl::wait(), Fl::check(), another
instance of Fl::run(), call fl_ask() etc. and maybe run another instance
of a loop. You can even reuse a window that has been hidden and not
deleted before. There is no guaranteed "end of program" point that FLTK
could use to cleanup, not even atexit() will always work. So instead of
trying the impossible, FLTK is lightweight and leaves this up to the
programmer.

> Thanks to all for taking the time to respond!

You're welcome.

[MacArthur, Ian (Selex ES, UK)]

> When you say "let the system clean up for you", you
> should clarify that the system in fact does not clean up
> for you.

Yes it does; it does exactly the things you'd expect at process termination, and Nothing More.

So it frees the memory, closes open file handles, terminates the process environment, etc.

If you, as the programmer, have acquired any resources which are persistent across processes, then it is your responsibility, as the programmer, to make sure that those resources freed properly.

If that means that you have to explicitly call the destructors for your widgets, then I'm afraid that's the way it is. FLTK, with its "fast light" ethos, is not going to do that for you.

In this regard, Fl:delete_widget() is probably your friend, as that should allow you to hide a widget then mark it for subsequent clean up.

> It does not call delete, or the destructors, or

> closes resources properly. As far as I understand, it just

> reclaims the resources in a rather brute force manner,
> which is definitely not something a developer should rely
> on as a mechanism to properly de-allocate resources.

Sorry: Disagree strongly.
You absolutely *can* depend on process termination to do these things for you, and you should.

Consider the "usual" case, where all the widgets have just taken some RAM, but no persistent resources.

If you walk through your widgets at process termination, you can delete them all and return that RAM to the heap. You can do this, and it will take time.

Your process will then terminate, and process termination will discard that entire heap, since it is virtual.

So... what exactly was the point of returning all that RAM to the heap? A heap that no longer exists?

If you are creating and deleting widgets as you go along, you must manage explicit deletion, and that's correct, but at process termination?
Just chuck it...

I trot this anecdote out every time this comes up (here we go again...) but years ago we had a new guy start, very bright, dead keen, and as a "getting started" task he was set to refactoring a horrible mess of code. Did a lovely job, much better...
But we started to get complaints from users that it was "taking too long to close."

Bottom line, fresh from school he did what he was taught and studiously deleted every widget he created when he came to app termination.

Was taking a couple of minutes (really!) No wonder the users were peeved.

Better option: Just terminate. App closes "instantly". Everything else is just the same.


Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[MacArthur, Ian (Selex ES, UK)]

> I'm working on an application where users can
> bring up windows to generate plots.
> I do not know in advance how many and once the
> user is done with the window, there is no point
> to bring that same window back, so I want to make
> sure all resources allocated by that window are
> cleaned up (including the window itself).

OK, makes sense, I think you'd want to derive a window type and have it call Fl::delete_widget() on itself when you are finished with it.

That said, when I have done something similar, I usually just create a pool of windows and re-use them for each display, so that when the window is hidden it is not deleted, but kept around and re-used when I need to show another window.

> (It actually works similar to how Matlab generates
> and manages figures, as far as I understand).

Eugh... sent shivers down my spine there... I'm not sure you can say the words "similar to how Matlab works" in polite company...

> In other words, in this particular application,
> the window's lifetime is much shorter than the
> application's lifetime.

Yup, got it. I think I'd go the way I suggest above, but each to their own!

Cheers,
--
Ian

[Steve Maas]

Alright, after doing some more reading on this topic, it turns out you guys were right. Modern OS are indeed pretty good at cleaning up after a process terminates and it definitely doesn't seem to be necessary anymore to release all your resources right before a program ends. Well, I've learned a lot from this thread, so thanks again for taking the time to respond.

Ian, regarding the Matlab comment, I'm not exactly sure what you are trying to say here, but I just used Matlab as an illustration of a program that creates a variable number of child windows. Nothing more. Definitely didn't intent to give you shivers :)

Best,

Steve

[Ian MacArthur]

On Thu Nov 27 2014 15:26:24, Steve Maas wrote:
> Ian, regarding the Matlab comment, I'm not exactly sure what you are trying to say here, but I just used Matlab as an illustration of a program that creates a variable number of child windows. Nothing more. Definitely didn't intent to give you shivers :)

I’m personally not that keen on Matlab, either as a language, or the GUI that supports it.

So holding it up as an example maybe didn’t have the desired effect...

Maybe that is just me!