wxErlang question

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

wxErlang question

John R. Ashmun-2
I have written an interactive Erlang program which runs on Microsoft Windows 10 & which makes use of wxErlang to open a window which contains buttons for a user to click upon.  Their use is not problematic.

The window has a File menu with the single item "Quit" and of course it also has a widget intended to be used to close it.  The use of these is somewhat problematic:  If I select the "Quit" item, although the Erlang process that created the window successfully receives the message

#wx{ id= ?EXIT,
        event = #wxCommand{ type = command_menu_selected } }

(where I used a

-define(EXIT, ?wxID_EXIT).

macro for some reason.)

and its matching clause apparently succeeds with its call to wxWindow:close( ), in the Erlang shell there appears this message:

=ERROR REPORT==== 1-Nov-2018::14:01:34 ===
Supervisor received unexpected message: {wx,-202,
                                         {wx_ref,35,wxFrame,[]},
                                         [],
                                         {wxClose,close_window}}

My guess is that this report is generated by calling wxWindow:close( Frame, [] ).

I don't understand what "Supervisor" is in this case.  Could it be the process that spawned the process that creates the wxWindow?  The process owning the window and handling the wxCommand event attempts to send a tuple { terminate } to a process in the application that started it, and this appears to succeed, but only as a result of the Quit menu item -- if I click on the window-closing widget, I see no action being taken, but it turns out that the same ERROR REPORT has been queued somewhere; it appears after I subsequently choose the Quit menu item, before the one generated by choosing the Quit menu item.

I would like to learn how to eliminate the error report & how to get the close widget to close the window and send the { terminate } tuple.

About the close_window event, the receive loop is looking for

  #wx{ id = ?CLOSE, event = #wxCommand{ type = close_window } }

where ?CLOSE is an alias for ?wxID_CLOSE

If I had any understanding of how to use Github from Windows 10, I would happily make the sources available, but it's beyond me so far.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wxErlang question

Dan Gudmundsson-2
One problem is:

 #wx{ id = ?CLOSE, event = #wxCommand{ type = close_window } }  
which should be 
#wx{ id = ?CLOSE, event = #wxClose{ type = close_window } }



On Thu, Nov 1, 2018 at 10:49 PM John R. Ashmun <[hidden email]> wrote:
I have written an interactive Erlang program which runs on Microsoft Windows 10 & which makes use of wxErlang to open a window which contains buttons for a user to click upon.  Their use is not problematic.

The window has a File menu with the single item "Quit" and of course it also has a widget intended to be used to close it.  The use of these is somewhat problematic:  If I select the "Quit" item, although the Erlang process that created the window successfully receives the message

#wx{ id= ?EXIT,
        event = #wxCommand{ type = command_menu_selected } }

(where I used a

-define(EXIT, ?wxID_EXIT).

macro for some reason.)

and its matching clause apparently succeeds with its call to wxWindow:close( ), in the Erlang shell there appears this message:

=ERROR REPORT==== 1-Nov-2018::14:01:34 ===
Supervisor received unexpected message: {wx,-202,
                                         {wx_ref,35,wxFrame,[]},
                                         [],
                                         {wxClose,close_window}}

My guess is that this report is generated by calling wxWindow:close( Frame, [] ).

I don't understand what "Supervisor" is in this case.  Could it be the process that spawned the process that creates the wxWindow?  The process owning the window and handling the wxCommand event attempts to send a tuple { terminate } to a process in the application that started it, and this appears to succeed, but only as a result of the Quit menu item -- if I click on the window-closing widget, I see no action being taken, but it turns out that the same ERROR REPORT has been queued somewhere; it appears after I subsequently choose the Quit menu item, before the one generated by choosing the Quit menu item.

I would like to learn how to eliminate the error report & how to get the close widget to close the window and send the { terminate } tuple.

About the close_window event, the receive loop is looking for

  #wx{ id = ?CLOSE, event = #wxCommand{ type = close_window } }

where ?CLOSE is an alias for ?wxID_CLOSE

If I had any understanding of how to use Github from Windows 10, I would happily make the sources available, but it's beyond me so far.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wxErlang question

John R. Ashmun-2
Thank you.

I don't see a change in the (lack of) behavior of the close widget, though.  I'm clearly missing something more.

On Thu, Nov 1, 2018 at 3:49 PM Dan Gudmundsson <[hidden email]> wrote:
One problem is:

 #wx{ id = ?CLOSE, event = #wxCommand{ type = close_window } }  
which should be 
#wx{ id = ?CLOSE, event = #wxClose{ type = close_window } }



On Thu, Nov 1, 2018 at 10:49 PM John R. Ashmun <[hidden email]> wrote:
I have written an interactive Erlang program which runs on Microsoft Windows 10 & which makes use of wxErlang to open a window which contains buttons for a user to click upon.  Their use is not problematic.

The window has a File menu with the single item "Quit" and of course it also has a widget intended to be used to close it.  The use of these is somewhat problematic:  If I select the "Quit" item, although the Erlang process that created the window successfully receives the message

#wx{ id= ?EXIT,
        event = #wxCommand{ type = command_menu_selected } }

(where I used a

-define(EXIT, ?wxID_EXIT).

macro for some reason.)

and its matching clause apparently succeeds with its call to wxWindow:close( ), in the Erlang shell there appears this message:

=ERROR REPORT==== 1-Nov-2018::14:01:34 ===
Supervisor received unexpected message: {wx,-202,
                                         {wx_ref,35,wxFrame,[]},
                                         [],
                                         {wxClose,close_window}}

My guess is that this report is generated by calling wxWindow:close( Frame, [] ).

I don't understand what "Supervisor" is in this case.  Could it be the process that spawned the process that creates the wxWindow?  The process owning the window and handling the wxCommand event attempts to send a tuple { terminate } to a process in the application that started it, and this appears to succeed, but only as a result of the Quit menu item -- if I click on the window-closing widget, I see no action being taken, but it turns out that the same ERROR REPORT has been queued somewhere; it appears after I subsequently choose the Quit menu item, before the one generated by choosing the Quit menu item.

I would like to learn how to eliminate the error report & how to get the close widget to close the window and send the { terminate } tuple.

About the close_window event, the receive loop is looking for

  #wx{ id = ?CLOSE, event = #wxCommand{ type = close_window } }

where ?CLOSE is an alias for ?wxID_CLOSE

If I had any understanding of how to use Github from Windows 10, I would happily make the sources available, but it's beyond me so far.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions