I need a two page message for a help button, so I have the callback

procedure Help (Self: access Gtk.Button.Gtk_Button_Record'Class) is
begin
Show ("Page 1");
Show ("Page 2");
end Help;

where

procedure Show (Message: Glib.UTF8_String) is
Dialog : Gtk.Message_Dialog.Gtk_Message_Dialog;
Response: Gtk.Dialog.Gtk_Response_Type;
begin
Gtk.Message_Dialog.Gtk_New (Dialog,
Parent => Parent,
Flags => Modal,
The_Type => Message_Info,
Buttons => Buttons_Close,
Message => Message);
Response := Gtk.Message_Dialog.Run (Dialog);
Gtk.Message_Dialog.Close (Dialog);
end Show;

The problem is: When the first dialog's Close button is pressed, the next page appears, but the first is not closed. When the second page's Close is pressed, the window disappers, but the first dialog window is still there. Only pressing the red cross on the window's right upper edge closes the dialog.

What's wrong with my code?

On 2021-09-08 15:52, AdaMagica wrote:
> I need a two page message for a help button, so I have the callback
>
> procedure Help (Self: access Gtk.Button.Gtk_Button_Record'Class) is
> begin
> Show ("Page 1");
> Show ("Page 2");
> end Help;
>
> where
>
> procedure Show (Message: Glib.UTF8_String) is
> Dialog : Gtk.Message_Dialog.Gtk_Message_Dialog;
> Response: Gtk.Dialog.Gtk_Response_Type;
> begin
> Gtk.Message_Dialog.Gtk_New (Dialog,
> Parent => Parent,
> Flags => Modal,
> The_Type => Message_Info,
> Buttons => Buttons_Close,
> Message => Message);
> Response := Gtk.Message_Dialog.Run (Dialog);
> Gtk.Message_Dialog.Close (Dialog);
> end Show;
>
> The problem is: When the first dialog's Close button is pressed, the next page appears, but the first is not closed. When the second page's Close is pressed, the window disappers, but the first dialog window is still there. Only pressing the red cross on the window's right upper edge closes the dialog.
>
> What's wrong with my code?

You must call Destroy on the dialog to kill its window.

P.S. Note, that when the object reference is "floating" you have to sink
it first before calling Destroy. However, in your case after Run all
references must be OK.

P.P.S. Modal dialogs is the root of all evil...

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Dmitry A. Kazakov schrieb am Mittwoch, 8. September 2021 um 17:02:52 UTC+2:
> You must call Destroy on the dialog to kill its window.
Thanks, Dmitry, that worked.
> P.P.S. Modal dialogs is the root of all evil...
Whar else would you recommend?

On 2021-09-08 19:09, AdaMagica wrote:
> Dmitry A. Kazakov schrieb am Mittwoch, 8. September 2021 um 17:02:52 UTC+2:
>> You must call Destroy on the dialog to kill its window.
> Thanks, Dmitry, that worked.
>> P.P.S. Modal dialogs is the root of all evil...
> Whar else would you recommend?

Just common sense of ergonomic UI, because I am no expert in this.

I do not like dialogs because they cover other UI elements and require
switching user attention.

If I need some input field I usually reserve a place on the screen with
confirmation and cancel buttons. I try to implement
checking-while-typing when possible and not too annoying.

A confirmation/commit button is IMO preferable, however modern UIs tend
to commit changes as soon as the UI element loses the focus.

For settings I use tabbed views. They tend to grow out of any measure.
Not a perfect solution, but IMO much better than dialogs and in any case
better than tree views when you need to expand and collapse nodes
looking for a setting parameter.

Modal dialogs are OK for emergencies when continuation is absolutely
impossible without user intervention.

One of few advantages of GTK is that widgets and containers
automatically expand and shrink. One should use this feature and avoid
fixed sizes. The minimum widget size, e.g. of a label or edit field can
be set.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Wednesday, September 8, 2021 at 8:01:35 PM UTC+1, Dmitry A. Kazakov wrote:
> On 2021-09-08 19:09, AdaMagica wrote:
> > Dmitry A. Kazakov schrieb am Mittwoch, 8. September 2021 um 17:02:52 UTC+2:

> I do not like dialogs because they cover other UI elements and require
> switching user attention.
>

Spot on in my view.

Modality, which a vast majority of dialogs are, are anathema to a good user experience.

Apple used to know this, once, but they've relented in the face of ever increasing costs of actually giving a shit. Windows, and Linux, well, ...

You'd think that the open source software community would take one (or three) steps back, look at the literature, look at the evidence, and change their ways.

They won't. Not enough $$ in it, sadly.

Rant over.

Cheers,
M