wxlua-users Mailing List for wxLua (Page 158)

On 7/18/05, The Doctor <the...@bl...> wrote:
> John, please can you confirm if this would work?
>=20
> local popMenu =3D wx.wxMenu()
> -- add normal menu items
> -- to position the menu for a button use local rect =3D
> mybutton.GetRect() to find the bottom left.
> mywindow.PopupMenuXY(popMenu, mouseEvt.GetX(), mouseEvt.GetY())
>=20
> It's an example you sent when I needed to make a popup menu. I got that m=
enu to work with explicit co-ordinates, as I never did get mouseEvt to work=
, it's a nil value that can't be indexed, according to the error message I =
got.
It shouldn't be nil , maybe a typo. This code shows the popup menu for
a right down mouse event with control down and for positioning below a
button. Again, if you can provide the simplest full example of some
code I would appreciate it since I wouldn't have to write it from
scratch.
function main()
 frame=3Dwx.wxFrame(wx.wxNull,-1,"Frame",wx.wxDefaultPosition,wx.wxSize(=
400,400))
 popMenu =3D wx.wxMenu()
 popMenu:Append(11, "Menu Item")
 =20
 panel =3D wx.wxPanel(frame, -1)
 =20
 textCtrl =3D wx.wxTextCtrl(panel, -1, "", wx.wxPoint(5,5),
wx.wxSize(300, 200))
 function textRightDown(event)
 if (event:ControlDown()) then=20
 textCtrl:PopupMenu(popMenu, event:GetPosition())
 end
 end
 textCtrl:ConnectEvent(-1, wx.wxEVT_RIGHT_DOWN, textRightDown)
 =20
 button =3D wx.wxButton(panel, 12, "Button", wx.wxPoint(5, 210))
 function buttonDown(event)
 local width, height =3D button:GetSize()
 button:PopupMenuXY(popMenu, 0, height)
 event:Skip()
 end
 button:ConnectEvent(12, wx.wxEVT_COMMAND_BUTTON_CLICKED, buttonDown)
=20
 frame:Centre()
 frame:Show(wx.TRUE)
end
main()
> I really need help here, there is no documentation, and nothing at all on=
 Google. This is like shooting at a tiny hole in a distant wall, while wear=
ing a blindfold, and it's probably easier to pick locks...
The docs, for now, are the Import/*.i files in the source code
download. Look through them to see what is wrapped and what isn't. It
should mostly follow the wxWidgets manual. I think in the future we
can try to make it compatible to wxPython since wxLua has similiar
constraints and functions need to be reworked in similiar ways. (eg.
you can't return values from the input to functions, like
wxWindow::GetSize(int *width, int *height), but rather return both of
them as shown in the code above.)
Regards,
 John Labenski

On 7/18/05, The Doctor <the...@bl...> wrote:
> Hi John, how would I detect a ControlDown when a toolbar button is clicke=
d?
I don't think this is possible, however you can add a wxButton as a
tool and connect to the left down event where you can get the keystate
from the mouse event and save it. Make sure you skip the mouse event
so the button gets it and send the button event. Then take the
appropriate action from the button event.
Regards,
 John Labenski

John, please can you confirm if this would work?
local popMenu = wx.wxMenu()
-- add normal menu items
-- to position the menu for a button use local rect =
mybutton.GetRect() to find the bottom left.
mywindow.PopupMenuXY(popMenu, mouseEvt.GetX(), mouseEvt.GetY())
It's an example you sent when I needed to make a popup menu. I got that menu to work with explicit co-ordinates, as I never did get mouseEvt to work, it's a nil value that can't be indexed, according to the error message I got.
I was hoping to use that as a basis as a translation of the stuff in the wxWidgets manual, which also doesn't work as advertised, when applied to wxLua. I'd hoped to do
if (mouseEvt.ControlDown()) then dostuff end
which seems logical as ControlDown is listed with GetX, and also appears inside the wxLua exe, but it fails, giving the same error as your GetX does.
I tried loads of other things too: event:ControlDown(), event:mouseEvt.ControlDown(), spelling mouseEvent instead of mouseEvt..... all gave some kind of error, and I need a tested example of what works, as a basis for translating other things later.
I really need help here, there is no documentation, and nothing at all on Google. This is like shooting at a tiny hole in a distant wall, while wearing a blindfold, and it's probably easier to pick locks...

Hi John, how would I detect a ControlDown when a toolbar button is clicked?

On 7/15/05, Francesco Montorsi <f18...@ya...> wrote:
> Hi,
> I was revising all my components at wxCode and looking at wxScript I
> was wondering: I know that wxLua provides wrappers for all
> wxWidgets-stuff; i.e. to create apps written in LUA based on wx; but if
> I'm not interested in this but just in using wxLua from a c++ program as
> a script interpreter, can I still use wxLua ?
wxLua currently loads the wxWidgets wrappers by default. However, this
will change so that you can use wxLua as a straight lua interpreter.
We are waiting for a new wrapper mechanism that promises to be more
flexible. Hopefully, soonish.
=20
> My wxScript component actually supports lua, python (more or less, also
> cint & underc) but it's rather difficult to provide a reliable interface
> to multiple script interpreters, specially because some of these (underc
> and cint) are unstable and python gives me some leaks when used from a
> c++ app...
I would have loved to have used wxPython, but after struggling for a
year or so with it, I gave up trying to use it as an embedded C++
interpreter. The problems I had sound similiar to yours, memory leaks
and what not. I believe that python itself is not well suited to
embedding. IIRC, it supports only a single instance at a time, you can
play games to get more, but it was touchy since they're not true
independent interpreters. I don't remember much anymore, but something
about it's memory management made it interact poorly with your own C++
code.
> In the end I'd like to use only lua as script interpreter and I wonder
> if wxLua lets me to use lua in such way.
> When loading a script I need to know which functions are defined in the
> script file, what's their name & I need to be able to call them and
> exchange data using parameters... can I do that with wxLua ?
This is possible, but the API for it is not unified yet. I hope to
write a wxLuaState class that throws together all the little c
functions to make manipulating the lua_State from C++ very easy.
Something along the lines of LuaPlus, but a lot simplier. Currently
the wxLuaInterface will build a list of functions in lua for you.
It's just a matter of getting the new wrappers going and then putting
it all together in a way that would make it easier to use in a C++
program.
I hope this helps,
 John Labenski

Hi,
 I was revising all my components at wxCode and looking at wxScript I
was wondering: I know that wxLua provides wrappers for all
wxWidgets-stuff; i.e. to create apps written in LUA based on wx; but if
I'm not interested in this but just in using wxLua from a c++ program as
a script interpreter, can I still use wxLua ?
My wxScript component actually supports lua, python (more or less, also
cint & underc) but it's rather difficult to provide a reliable interface
to multiple script interpreters, specially because some of these (underc
and cint) are unstable and python gives me some leaks when used from a
c++ app...
In the end I'd like to use only lua as script interpreter and I wonder
if wxLua lets me to use lua in such way.
When loading a script I need to know which functions are defined in the
script file, what's their name & I need to be able to call them and
exchange data using parameters... can I do that with wxLua ?
Thanks,
Francesco

I've thought of something useful, but I don't know if it can be done.
First, the reason for asking...
I can disable a set of controls by wx.wxEnable(nil) on a parent window, but this changes the appearance, often in ways I do not want.
Or, I can make a dialog overlay that is transparent, but this only works in Windows, and I'd have to find ways to prevent tabbing and scrollwheels from affecting the masked controls.
I decided that the best answer might be to use a control that fools transparency by opying the area under the control, as it is made, so it is an image layer that appears to be transparent. There are four advantages:
1. I can disable the group window underneath after the new control is displayed, so the appearance is retained as if there was an active set of controls.
2. As it doesn't need real transparency, it could more likely be platform independent.
3. The disabling of the real surface underneath means that there is no chance of a masked control being interfered with.
4. I can disable or otherwise change singular aspects of the control surface in the moment before the layer mask is shown, and then disable the whole underlying surface. This can give a lot of control over how the disabled controls are displayed in the masking window.
Please can you tell me if this is doable? In effect it must be a display of a screenshot of the relevent area, made the moment before it is displayed as a layer masking the real surface.

On 7/5/05, Ray Gilbert <ray...@sc...> wrote:
> With the birth of my new son I have not had a lot of time to extract new =
interface. But I am working on wxBase and about half way through. Once I ha=
ve wxBase compiling, the rest should be simple.
Yeah, kids can take a lot of time away from the important stuff. :)
Anyway, I just thought I'd check up, since it's been pretty quiet and
I feel bad about breaking the CVS for so long, but I figure it's not
worth it to just temporarily fix it.
=20
> I now have a lua script that can extract compiler conditionals, and anoth=
er to extract function names and classes from tex docs. I was tinkering wit=
h the idea of having a strictly "documented" interface, or a general that a=
lso exposes undocumented classes.
The docs have been know to have bugs in them, get updated slowly, and
there's always the annual arguments about switching away from using
latex. If it was just from the header files the same mechanism could
be used to extract wrapper files for people's own projects too.
Updating them could, hopefully, be done just using a visual diff
program too.
Thanks for your effort,
 John Labenski

With the birth of my new son I have not had a lot of time to extract new =
interface. But I am working on wxBase and about half way through. Once I =
have wxBase compiling, the rest should be simple.
=20
I now have a lua script that can extract compiler conditionals, and =
another to extract function names and classes from tex docs. I was =
tinkering with the idea of having a strictly "documented" interface, or =
a general that also exposes undocumented classes.
=20
It is a little slow going, but I have not come across any major hitches.
=20
Ray
=20
=20

 How are the new wrappers going? Is there anything that I can do to help=
?
Regards,
 John Labenski

On 7/4/05, The Doctor <the...@bl...> wrote:
> Hi John, is the wxEVT_COMMAND_RADIOBUTTON_SELECTED working? I can't get a=
ny kind of response out of that at all.
It seems to work here, maybe you want wxEVT_COMMAND_RADIOBOX_SELECTED?=20
Regards,
 John Labenski

Sorry, was an error with its parenting... :)
Anyway, the Thinger will be ready in a few days at most now.

Hi John, is the wxEVT_COMMAND_RADIOBUTTON_SELECTED working? I can't get any kind of response out of that at all.

On 6/29/05, The Doctor <the...@bl...> wrote:
> --This one is a bug, maybe, the button gets its colour changed and change=
d back, but once it's back the greyed state isn't visible anymore, maybe be=
cause the system colours are made literal.
You change the font color to grey, then back to the default, then
disable it which basicly greys it, but in wxGTK it looks identical as
if you didn't change the color at all. If however the text completey
dissapeared in MSW, this would be an issue with wxWidgets.
-John
=20
> FRAME =3D wx.wxFrame(
> wx.wxNull,
> -1,
> "The Thinger",
> wx.wxPoint(0,0),
> wx.wxSize(436,332)
> )
>=20
> local PANEL=3Dwx.wxPanel(FRAME,-1)
>=20
> BT=3Dwx.wxButton(PANEL,6,"6",wx.wxPoint(9,032),wx.wxSize(20,21))
> BT:SetForegroundColour(wx.wxColour(140,140,140))
> BT:SetForegroundColour(wx.wxNullColour)
> BT:Enable(nil)
>=20
> FRAME:Centre()
> FRAME:Show(wx.TRUE)

On 6/29/05, The Doctor <the...@bl...> wrote:
> I tried PushEventHandler yesterday, and it caused a crash before the prog=
ram showed anything on screen. I also tried SetEventHandler to make a Stati=
cText handle all messages, and also making one button handle all of the mes=
sages from the others, and each test failed. The one thing that has worked =
is using SetEventHandler to the frame or the panel on it, I've not tried ot=
her things.
I'm sorry that all that is untested, at least by me. I guess I still
don't understand why you don't want to just what's below, which is
known to work and would seem to me to be simplier. Swapping out event
handlers is not to be taken lightly, you really have to check out what
going on when you do things like that.
See here for what happens when you push/pop a handler.
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/common/wincmn.cpp?rev=3D=
HEAD&content-type=3Dtext/vnd.viewcvs-markup
search for: void wxWindowBase::PushEventHandler(wxEvtHandler *handler)
Try doing this instead.
function HandleButtonLeftUpEvent(event)=20
 if event.GetId() =3D 1 then
 do stuff...
 else if event.GetId() =3D 2 then=20
 ...
end
function MakeMyButton(parent, id, ...)\
 local button =3D wx.wxButton(parent, id, ...)
 button:ConnectEvent(-1, wx.wxEVT_LEFT_UP, HandleButtonLeftUpEvent)
 button:ConnectEvent(-1, wx.wxEVT_RIGHT_UP, HandleButtonRightUpEvent)
 etc...
 return button
end
All you have to do to create a button is then
 MakeMyButton(PANEL, 10, ...)
 MakeMyButton(PANEL, 11, ...)

I tried PushEventHandler yesterday, and it caused a crash before the program showed anything on screen. I also tried SetEventHandler to make a StaticText handle all messages, and also making one button handle all of the messages from the others, and each test failed. The one thing that has worked is using SetEventHandler to the frame or the panel on it, I've not tried other things.
I've done the code for operator copy and paste, and individual output muting, and the whole program flow is better. I'll try to get two last major things I want to add, then hand it over so people can see what is happening. I'm hoping that wxLua will have some way to customise routes for event handling. As I said in a very recent mail, this will be extremely useful, at least to me..

--This one is a bug, maybe, the button gets its colour changed and changed back, but once it's back the greyed state isn't visible anymore, maybe because the system colours are made literal.
FRAME = wx.wxFrame(
 wx.wxNull,
 -1,
 "The Thinger",
 wx.wxPoint(0,0),
 wx.wxSize(436,332)
)
local PANEL=wx.wxPanel(FRAME,-1)
BT=wx.wxButton(PANEL,6,"6",wx.wxPoint(9,032),wx.wxSize(20,21))
BT:SetForegroundColour(wx.wxColour(140,140,140))
BT:SetForegroundColour(wx.wxNullColour)
BT:Enable(nil)
FRAME:Centre()
FRAME:Show(wx.TRUE)

Todays work will be to try PushEventHandler instead of SetEventHandler, as I read that it was preferred. I just stayed with what appeared to work so far, and also to test what was possible. :)
The override of the button left click was just a matter of testing, I got it with event:Skip() before my own call, placed in the EVT_LEFT_UP handler. I removed the original BUTTON_CLICKED handler... This probably won't be my final answer; I was considering the StaticText, but that won't take a colour change so it can't be used as an indicator. Disabling is not an option, as I need the control to be enabled regardless of its state. I'm just trying stuff to see what can work, before I settle on the best choice.
About the LEFT_UP before DCLICK, I agree, I overlooked for a moment that LEFT_UP must always be detected during a DCLICK, and there seems to be no way to separate them. In this case it will be acceptable though, as the stuff ordered by LEFT_UP is small, fast, and there is no harm in it being done also when DCLICK orders its own stuff. I'll try to separate the orders some time, but it's not a high priority now.
Your point about being pleasantly surprised if a wxButton gives a LEFT_DOWN is exactly the same sort of thing that drove me to this experiment. I want to find a reliable way to get any kind of click I might want from a control. That way I can make more events from one control. It makes motor memory play a bigger part instead of the current high reliance on visual memory. Doing this increases the ease and efficiency of moderately complex user operations, as well as allowing only those methods required to do the task. For example: in my taks I want a control to do a data copy on left click, to toggle a state with double-click, indicating said state on the same control, and to popup a menu of paste options with the right click, all on the same control. I have achieved this, but not yet found the best way, no doubt... I was partly hampered by the alternate bitmaps and toggling not working in wxLua toolbar buttons. :) This made me look for other options... I've now decided that I want this rather badly, the idea of being able to use any or all kinds of mouse click for a single control of many or even all types, is so powerful, to me it makes sense that it should be possible, easily overriding a default behaviour where needed.
Btw, about FRAME:Close(), I remember why I didn't keep it that way now. I tried it again after your mail. I have a handler to catch any attemt to close the frame. It does stuff, then FRAME:Destroy(), cos FRAME:Close() in that handler makes a loop until some stack overflows. :) If there is a better way to avoid that loop, please let me know.
> It would be best to simply call a common function
> to handle the event for all windows if this is what you really want.
It is. But that's the problem. For SpinCtrl's I do this easily, I just use FRAME:ConnectEvent() for wxEVT_COMMAND_SPINCTRL_UPDATED to catch them all and call a function that processes according to ID. This works cos the COMMAND events propagate right back to the frame. While the mouse LEFT_UP, DCLICK and such do not propagate, I have to catch each control I want to click by using a handler for each one, each handler calling the common function. That's a lot of code, even for 3 groups of 6 buttons on separate notebook pages. If I could make some tiny, hidden control with no events of its own, say a StaticText of zero display size, I could make all the click events get handled by that. I'd still have to direct the handling from each real control, but at least the code to do it is very small and neat.
I guess what I'll do is turn over the Thinger before it's complete, so you can see what is being done. I just want to make sure it works as intended, so that the behaviour as seen by the user is clear, and then any code corrections will be easier to do, as there will be a working precedent for what it has to do. Having got the main idea for Operator parameter copying and output enabling sussed (or at least doable), it shouldn't be long now. I suspect a lot will be better changed, but I think we'll get more out of it this way. I'll learn more easily about better coding from modifications to work I've already done, and you'll see an idea that might make some interesting ways to do things, and one that demonstrates what I feel is a need for easier customising of control handling.

On 6/26/05, The Doctor <the...@bl...> wrote:
> I've just seen my first wxLua crash.
>=20
> WXLUA caused a stack fault in module WXMSW254_VC_WXLUA.DLL at 016f:100d10=
eb.
Oops. :(
> It happens consistently, as a result of using X:SetEventHandler(PANEL), w=
here X is a button or other control whose event handling is set elsewhere f=
or common handling of mouse clicks. The program is running ok as far as I k=
now, until the crash is invoked by changing the OS colour scheme. (I discov=
ered this while changing it to see the effects of using wx.wxNullColour.) I=
 commented out all the new code to eliminate things until the bug didn't ha=
ppen, then looked at what addition would alone be enough to cause the crash=
 when the OS scheme was changed, and it's definitely that X:SetEventHandler=
(PANEL) bit. Even with NO code affecting colours by explicit demand, this h=
appens.
I don't think your SetEventHandler(otherWindow) trick will work
without some serious c++ testing.You're probably breaking the chain of
handlers, hence the segfault. However, you may want to explore
PushEventHandler, but I bet you have to Pop it before the window is
destroyed.
What you're doing sounds a little strange, it doesn't make sense to
get the left button press on a wxButton, just get the
wx.wxEVT_COMMAND_BUTTON_CLICKED or if you want to disable the button
use button:Enable(false). Remember, wxWidgets wraps around the native
library and if that doesn't provide a function, neither does wxWidgets
(but they do try to smooth things out as much as possible). I would be
pleasantly surprised if a wxButton emitted a left down event for
example.
In terms of double clicks, it's always down, up, double IIRC.
Finally, FRAME:GetEventHandler():ProcessEvent(event) merely takes the
event you get in a child window, so you've got to set a handler for
it, and then asks the FRAME to handle it as if it was meant for it
(you're on your own doing this for key and mouse events since
wxWidgets may use them as well for some controls and won't expect them
from child windows). It would be best to simply call a common function
to handle the event for all windows if this is what you really want.
Good luck,
 John Labenski

I've just seen my first wxLua crash.
WXLUA caused a stack fault in module WXMSW254_VC_WXLUA.DLL at 016f:100d10eb.
Registers:
EAX=1058adb8 CS=016f EIP=100d10eb EFLGS=00010216
EBX=008afa06 SS=0177 ESP=007b1fd4 EBP=007b2000
ECX=ffffffff DS=0177 ESI=00008a2a FS=18bf
EDX=00000000 ES=0177 EDI=008af9bc GS=0000
Bytes at CS:EIP:
89 4d f8 8b 55 08 8b 42 04 89 45 fc 83 7d f8 ff 
Stack dump:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 007b202c 100d072a 1058adb8 00efa400 007b2074
It happens consistently, as a result of using X:SetEventHandler(PANEL), where X is a button or other control whose event handling is set elsewhere for common handling of mouse clicks. The program is running ok as far as I know, until the crash is invoked by changing the OS colour scheme. (I discovered this while changing it to see the effects of using wx.wxNullColour.) I commented out all the new code to eliminate things until the bug didn't happen, then looked at what addition would alone be enough to cause the crash when the OS scheme was changed, and it's definitely that X:SetEventHandler(PANEL) bit. Even with NO code affecting colours by explicit demand, this happens.

Last questions for the day...
If I make it so a right click and a right double-click call different functions (in this case showing a message box as a test flag with different text on it), the double click won't work, only the right click. Either works alone, but the right-click takes priority. It looks as if it won't wait long enough to establish whether a second click occurs, basically.
Is there an easy way to make it so both types can work? Also, might I need to use event:skip() to override the default action of a button if I find apparent confilcts with standard left clicks?

Can I say Eureka?!
I can say thankyou, anyway.
the simplest answer is this:
:SetEventHandler(PANEL)
I append that to the code that sets up the button, then set the panel to handle the mouse clicks. I looked at your suggestion and basically decided to explicitly set the handler for any control I want to click in various amusing ways >:)
Thanks again, I doubt I'd have got there on my own.
Crow.

I had a go with that code, but it doesn't solve the problem. What if I wanted to right-click that button? or double-click? Getting a standard button-click to call a common function isn't the problem, I can do that and have already used it in the Thinger script, as well as a careful set of valid ID's which is the foundation the whole thing rests on.
I'll look into that FRAME:GetEventHandler():ProcessEvent(event) which looks likely enough, judging by the manual, though I can't yet follow it, it seems adrift without context so far... If you have a small but complete code that would be a great help to start. I'll try adding it to the ones I have but I doubt I can do it as fast or as easily as you can. Anything that works, even if it doesn't directly answer the need, is immensely useful, it is the fastest way I can learn from this, not least cos I like to play with it to see what else works and that gives me new answers to questions I might well never need to ask.
Thanks for the Frame:Close() tip, I forgot that, either from something you said before, or something I found l;ast night and lost in an unsaved copy, and you just saved me some time finding it again. :) I can't remember where I bumped into that before but I tried it and it worked, and I found this morning that I didn't have it anymore.
About propagation, I think it would solve this. The description of the process seems to indicate that it's exactly what I need, though anything that can link all types of mouse click to a single handler will do.

On 6/26/05, The Doctor <the...@bl...> wrote:
> I've tried to get notice of whether the event should propagate by default=
.
>=20
> event:ShouldPropagate()
> This returns an error, invalid method.
>=20
> It has the same structure as event:GetId() which works fine, so being a s=
imple thing I can't see what I could possibly get wrong. Does this mean tha=
t event:ShouldPropagate() doesn't exist in wxLua?
Yes, this is a new thing in 2.6 IIRC, we'll add it. I don't think
it'll solve this issue, but I haven't tried it myself.
=20
> And if control of propagation is missing, is there any way I can solve my=
 mouse-click event problem?
You need to call the frame handler directly,=20
FRAME:GetEventHandler():ProcessEvent(event). This is the wxWidgets
design since you don't want parent of windows getting confused/baraded
by mouse/key events from the children. If you do this make sure that
you assign valid IDs to each window so you can distinguish them in you
event handler using event:GetId().
I hope this helps,
 John Labenski
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This seems to work as expected, you need to call FRAME:Close() not
FRAME:Destroy(). I added some other tests too.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FRAME=3Dwx.wxFrame(wx.wxNull,-1,TITLE,wx.wxDefaultPosition,wx.wxSize(436,31=
4))
PANEL=3Dwx.wxPanel(FRAME,-1)
PAGES=3Dwx.wxNotebook(
 PANEL,
 -1,
 wx.wxPoint(11,30),
 wx.wxSize(405,230),
 wx.wxNB_TOP
)
PAGE1 =3D wx.wxPanel(PAGES, -1)
SPIN1 =3D wx.wxSpinCtrl(PAGE1, -1)
BUTTON1 =3D wx.wxButton(PAGE1, -1, "Press Me", wx.wxPoint(0, 30))
PAGES:AddPage(PAGE1, "Hello")
function HandleEvent(event)
 SPIN1:SetValue(SPIN1:GetValue()+1)
end
PANEL:ConnectEvent(-1, wx.wxEVT_LEFT_UP, HandleEvent)
BUTTON1:ConnectEvent(-1, wx.wxEVT_COMMAND_BUTTON_CLICKED, HandleEvent)
PANEL:ConnectEvent(-1, wx.wxEVT_RIGHT_UP,
 function(event) FRAME:Close() end
)
FRAME:Centre()
FRAME:Show(wx.TRUE)

I've tried to get notice of whether the event should propagate by default.
event:ShouldPropagate()
This returns an error, invalid method.
It has the same structure as event:GetId() which works fine, so being a simple thing I can't see what I could possibly get wrong. Does this mean that event:ShouldPropagate() doesn't exist in wxLua?
And if control of propagation is missing, is there any way I can solve my mouse-click event problem?