| Age | Commit message (Collapse) | Author |
|---|
|
Exit command loop less often too avoid expensive event checking
while in batch mode.
|
|
|
|
* dgud/wx/fixup-batch-break:
Fixup batch break
|
|
* dgud/wx/pr/1425:
wxe_impl.cpp: pointer comparison fix
|
|
Batches was breaked to often, increase the test and break
if batch is done (and queue empty).
|
|
* Fix ordered comparison between (void *) pointer and zero
|
|
With a bad timing in wx:batch() the driver could get stuck
handling commands without ever checking for gui events.
Avoid that by exiting loop after the driver have done cond_wait a
couple of times.
|
|
There seems to be a timeing dependent double delete when doing
reference cleanup after wx:destroy(). wxGraphicsObjects can thus not
be free'ed by wx in the cleanup phase. A guess is that the underlying
rendering context deletes all graphics objects without careeing about
wxWidgets reference counting.
|
|
Commands could be executed twice, if the command was dispatched
from a callback and caused a recursive invocation of command loop.
Solution is to mark op as -1 before calling wxWidgets.
Also commands could be missed when idle processing was done inside
while executing a recursive callback, solved be always resetting peak
index after idle processing is done.
|
|
|
|
Causes issues on mac and observer
|
|
Some events are callbacks inside wxWidgets so idle processing doesn't
take place until operation is completed, for instance move/resize window
on Windows. This way we get some response while mouse button is pressed.
|
|
Avoid copying between command queues, cleaner, faster and
safer implementation.
|
|
After applying a command make sure that it didn't recurse to a callback
invocation, then we must re-start from the saved command queue.
|
|
Instead of popping up an annoying msgbox
|
|
|
|
|
|
|
|
When emulator is stopped all drivers are stopped but not unloaded
and since the clean wx thread stoppage code was in unload callback it
was not called and could cause crashes.
|
|
Remove allocations
|
|
Do not postpone deletion of wx*DC objects since they need to be
deleted directly. Otherwise, if inside showModal, causes an eternal
loop of wxPaint events on Windows.
|
|
Messages was routed via the wxe_server process, which caused process
to never get the message.
|
|
|
|
|
|
Mac doesn't add clicked files to program arguments, a callback
is invoked instead, send msgs to erlang about them.
|
|
Avoids crashes.
|
|
The pid is not available via driver_caller(..) (see wxeCommand constr)
inside driver_monitor callback.
|
|
Previously we could do a cleanup while we where recursed down
and thus delete the objects we where invoking.
|
|
Try to clean up the files a bit
|
|
wxWakeUpIdle doesn't always work on wxGTK and the workaround is to
periodically invoke it, so the gui-thread doesn't get stuck in poll.
Previously it was only called when NOT in batch mode, however if the
wxWakeUpIdle call after a batch_begin command did not wake up the
thread it would still get stuck in poll.
|
|
Event handlers was not removed after objects/process had been
delete/died, which causes memory leakage and that fun's was
kept in the wx_server process. Code that might be purged and
the server died.
|
|
Remove dummy windows and move the console to gui app code before
wxWidgets gets initialized to prevent hangings on current wxWidgets svn
version.
|
|
|
|
|
|
wxWidgets looked in the wrong executable after icons and cursors, stole
wxLua's solution.
Also finds wx-2.9 on windows
|
|
|
|
New testcase showcase the deadlock
|
|
|
|
Could cause a crash in later restarts
|
|
Previously other process wx calls where allowed to execute in the
callback code, but that lead to a deadlock if for example a dialog
was created.
|
|
|
|
|
|
|
|
For instance when DISPLAY was not set
|
|
The idea is to build a separate opengl library which can be reused
by other erlang applications.
|
|
May also be the reason of the crash seen on windows by several others.
|
|
|
|
You could get a reference to another applications memory, if wx had
deleted that applications memory without the drivers knowledge about
it, typically memory allocated by wx and not the application using
classes where wx-driver can't override the desctructors.
When wx allocated new memory and got a pointer to that memory, the
wx-driver detected the same pointer and forwarded the old ref to
erlang.
|
|
|
