On Fri, Apr 12, 2013 at 4:13 PM, Javier Mr <javiersdevm...@ymail.com> wrote:
> Hi,
>
> i'm using wxLua to make an interface, but i'm facing several crashed and 
> after looking for the source of them i could find it. I have an idea of a 
> posible reason so i will ask in case this is a known behaviour. First several 
> questions?
>
> 1. First in wxWidgets, are events (click, cell changes, tree item activation, 
> etc...) dispatched synchronously or asynchronously?

Asynchronously (in a way), but single threaded. wxWidgets apps
basically "hang" in the native OS event loop until the mouse is moved,
key pressed, etc. You can "pump" the event loop by requesting a
wxIdleEvent or using a wxTimer.

> 2. If asynchronously, could it be posible that to events are dispatcher 
> against the same lua state simultaneaously?.

You will never have two functions called at once by the wxWidgets event loop.

> What i have is a tree control with several items and a grid, so when a item 
> in the tree is activated the grid is filled up. I'm currently connected to 
> events for tree item activation, tree item right click, grid cell changed.
>
> Let's suppose the wxWidget thread running on the main loop is A ( 3. which i 
> belive is the thread that load the lua script, isn't it? ),

Yes, same thread.

> when i activate a tree node a event (evt1) will be queued in the event queue 
> (4. isn't it?), and the main loop will check for pending events it will find 
> the event (evt1) and will dispatch it (5. but will the lua function from the 
> event handler be called by the thread running the main loop (A) or will a 
> second thread be created (B) ?).
>

Never a second thread.

>
> In case question 5 is that a new thread will be created for executing the 
> handler, could another event in the tree (evt2) be queued in the events queue 
> and then the main loop thread (A) dispatch it creating a new thread (C) 
> **accesing** and modifiying the lua state while the previous event thread (B) 
> hasn't return yet?
>

Nobody, including your code, should *ever* try to access any wxWidgets
control from any other thread than the one it was created in.

> My hole test so far have been repainting the grid while clicking several 
> timer over a tree item so the event handler doesn't return inmediatly.
>
> I think all previous questions could be summariazed but, does wxLua protect 
> the access to the lua state from within wxLua?

No, there would be way too many places to put mutexes, it would be really ugly.

A wxLua app works this way.

1) Start Lua... load the libs require("wx") etc.
2) Execute the Lua code, but it quickly gets to the end of the code.
    The code defines functions, creates the wxFrame add child windows,
connect events... but doesn't really do any "work"
3) Then if any wxFrames (or any wxTopLevelWindow derived class) exist,
wxLua starts the wxWidgets event loop and the app "hangs" in it
waiting for user input.

Hope this makes sense,
     John

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users

Reply via email to