On 2/23/07, Patrick Elliott <[EMAIL PROTECTED]> wrote:
> I am going to make this easy for you, since the last response directed me to
> wxwidgets, where they have "no" answer.
>
> So far, I have determined a few things.
>
> 1. MFC includes something called "message reflections". This allows messages
> to its main window to be redirected to child windows, or any other class
> with the appropriate code to handle events. These are passed to that new
> handler "before" the window sees them, then any unhandled ones are passed
> back.
recursion_guard = false -- when this event comes back, don't process it
frame:Connect(wx.wxID_ABOUT, wx.wxEVT_COMMAND_MENU_SELECTED,
function (event)
if not recursion_guard then
recursion_guard = true
if (not childwindow:GetEventHandler():ProcessEvent(event)) then
-- process the event by the frame
end
recursion_guard = false
end
end)
See event:Skip(true/false) to change the return value of ProcessEvent
which if the event is derived from a wxCommandEvent will travel of the
chain of parents to the top level window looking for a handler that
doesn't call Skip(true) on the event.
> 2. wxLua has state information that defines the IDs specific to what
> information its events are tagged with when generated. Not sure what happens
> when you make someone else's window the "parent" of the wxLua objects
> though.
The usage of IDs are identical to the way they're used in C++. You can
obviously make a wxWindow in wxLua a child of a window created in C++
since there's no difference between the two.
> 3. There is a function for returning GetEventHandler, which returns the
> event handler being used "by" wxLua to deal with events, which could be your
> own window you just created in the script.
You mean wxWindow::GetEventHandler? It returns the handler for that
window only.
Events are processed in the wxWidgets event loop and registered event
handlers (windows) are checked to see if there are matches (correct id
and they have Connected a function to that event type) and if yes, the
function is called, else look for another possible handler higher up
the handler chain until you've reached the top.
> What this seems to mean to me is that a) that handler will correctly handle
> events for any object you add to the window/container, making it unnecessary
> for the hosting application to do anything. This isn't probably likely. If
> not, then b) you create an MFC class that handles events, *reflect* the main
> windows event stream to there, parse the events before they hosting
> applications main window has seen them for anything smelling wxLua like,
> retrieve the handle for the wxLua *events* sink, pass the event you trapped
> on to that, wait for wxLua to do its thing, then mark the event as "handled"
> in the MFC class and exit, returning control back to the main MFC window of
> the host.
>
> Now, anyone have a clue which, (a) or (b) is needed, and more to the point,
> am I completely barking up the wrong tree here?
Both a and b exist as possibilities to... something? I'm not sure what
it is that you really want to do?
Please give a simple example of what you'd like to achieve.
John Labenski
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users
