Looking for audio level meter widget

[Eliot Blennerhassett]

Before I go and make my own, has anyone made an audio level meter bargraph widget?

I.e. one that has different coloured segments at different levels, and maybe
also a peak indication on top of the bar? and numeric indiator.

[--green---|-yellow-|-red-| | ] [+6dB]
-----------bar----------- ^peak ^number

could be vertical also. Any pointers or code snippets would be great.

thanks

--
Eliot Blennerhassett *:-{)>
AudioScience, Inc

[Ryan Norton]

Hi Eliot,

> I.e. one that has different coloured segments at different levels,
and maybe
> also a peak indication on top of the bar? and numeric indiator.
>
> [--green---|-yellow-|-red-| | ] [+6dB]
> -----------bar----------- ^peak ^number
>
> could be vertical also. Any pointers or code snippets would be
great.

Not sure about what you're talking about here - one that measures
the actual gain of something? Or one that measures the gain of a
particular
frequency (I.E. a partial spectrum analyzer)? From the "^number" I'm
guessing
it's the latter...

Ryan

[Matthieu Brucher]

Hi

It seems something that what I want to do too, a simple view meter -
like in every audio application or some hardware too -.
For the moment, mine is only one color, but it will eventually be
approximately as what you want to do.
http://sourceforge.net/projects/waterfallvst

--
Matthieu BRUCHER
Etudiant en 3ème année à SUPELEC
Option Information, Signaux, Mesures

[Steve Kann]

I made one of these by just having images for each of 7 or 8 states for
the bars, and a class which switches images. Works pretty fast and
without much overhead.

-SteveK

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-users-u...@lists.wxwidgets.org
> For additional commands, e-mail: wx-use...@lists.wxwidgets.org
>

[Eliot Blennerhassett]

I'm talking about a display widget. It wouldn't 'measure' anything directly.
Basically a fancy wxGauge

m=new wxMeter(minvalue=-96, maxvalue=+12)
m->Set(barvalue=-3, peakvalue=+2);

[Jürgen Schuhmacher]

Are you going to integrate any audio related funcionally into the
classes?

Just like RMS, peak hold etc ?

Jürgen

[Eliot Blennerhassett]

Jürgen Schuhmacher wrote:

For my application, the underlying hardware/driver returns RMS and peak values
in dB, with ballistics (i.e. decay timeconstants etc).

- Eliot

[Marc Lindahl]

Is anyone sending events between threads, or implementing event handlers
in different threads, under x11 or gtk? I can't get it to work - and
the same sources do work under wxMac and wxMSW. Any sample code I can
ponder around if so?

[Aj Lavin]

One way to handle events in a thread is to implement a wxEvtHandler
subclass, call it ThreadHandler, that overloads ProcessEvent.
ThreadHandler::ProcessEvent just adds events to a message queue.

You also write a wxThread subclass that handles each event in the
message queue as it becomes available, simply by calling
wxEvtHandler::ProcessEvent.

You can use wxMutex / wxCondition in your message queue implementation
to synchronize the 2 threads

I wrote a threading framework called Threadhandler that does exactly
this:
http://www.ectologic.com/code/

- Aj

--
Ectologic: building Internet applications with open source tools
http://www.ectologic.com/

[Marc Lindahl]

I made my threads e.g.:

class myEvtThread : public wxThread, public wxEvtHandler
{
private:
DECLARE_EVENT_TABLE()
}

shouldn't that be enough to be able to post events, e.g. from another
thread, wxPostEvent(pointer-to-myEvtThread-instance, event) ?

Also, looking at the code for app.cpp, it looks to me like wxApp
inherits from wxEvtHandler, so you can send events right to your wxApp
(and not a frame, for example).... this works in windows and mac but not
linux x11 or gtk....??

I'll take a look at your package - thanks! questions: have you tried it
with 2.5.2 (web page says 2.4) and have you tried it with the x11 or gtk
linux builds?

thanks,
M

[Aj Lavin]

On Sun, 2004-06-27 at 22:06, Marc Lindahl wrote:
> I made my threads e.g.:
>
> class myEvtThread : public wxThread, public wxEvtHandler
> {
> private:
> DECLARE_EVENT_TABLE()
> }
>
> shouldn't that be enough to be able to post events, e.g. from another
> thread, wxPostEvent(pointer-to-myEvtThread-instance, event) ?

You can post events to your myEvtThread object, but they won't be
processed in its thread unless you do something special.

Under normal event processing, if you ..

.. send the event using wxEvtHandler::AddPendingEvent, which is
equivalent to wxPostEvent, then the event is added to the list of
pending events for the object, and is processed sometime later by the
main thread in idle time.

.. send the event using wxEvtHandler::ProcessEvent, it calls the event
handler and so the event is processed in the calling thread.

If you want to handle the event in neither the calling thread (as
wxEvtHandler::ProcessEvent does) nor the main thread( as
wxEvtHandler::AddPendingEvent / wxPostEvent do), then you have to do
something special.

> Also, looking at the code for app.cpp, it looks to me like wxApp
> inherits from wxEvtHandler, so you can send events right to your wxApp
> (and not a frame, for example).... this works in windows and mac but not
> linux x11 or gtk....??

Dunno.

> I'll take a look at your package - thanks! questions: have you tried it
> with 2.5.2 (web page says 2.4) and have you tried it with the x11 or gtk
> linux builds?

I have only used wxWidgets 2.4 so far. Threadhandler works fine on both
wxGTK and wxMSW.

[Marc Lindahl]

On Monday, June 28, 2004, at 03:52 AM, Aj Lavin wrote:

> On Sun, 2004-06-27 at 22:06, Marc Lindahl wrote:
>> I made my threads e.g.:
>>
>> class myEvtThread : public wxThread, public wxEvtHandler
>> {
>> private:
>> DECLARE_EVENT_TABLE()
>> }
>>
>> shouldn't that be enough to be able to post events, e.g. from another
>> thread, wxPostEvent(pointer-to-myEvtThread-instance, event) ?
>
> You can post events to your myEvtThread object, but they won't be
> processed in its thread unless you do something special.
>
> Under normal event processing, if you ..
>
> .. send the event using wxEvtHandler::AddPendingEvent, which is
> equivalent to wxPostEvent, then the event is added to the list of
> pending events for the object, and is processed sometime later by the
> main thread in idle time.
>
> .. send the event using wxEvtHandler::ProcessEvent, it calls the event
> handler and so the event is processed in the calling thread.
>
> If you want to handle the event in neither the calling thread (as
> wxEvtHandler::ProcessEvent does) nor the main thread( as
> wxEvtHandler::AddPendingEvent / wxPostEvent do), then you have to do
> something special.

"Do something special" like...?

Do I need to e.g. push the thread/evtHandler onto the main event
handler stack from the wxApp thread?

[Aj Lavin]

.. like extend the wxWidgets event processing framework to accommodate
processing events in a thread. I tried to give you the basic idea in my
first post.

To elaborate a bit, I override wxEvtHandler::ProcessEvent with an
implementation that pushes the event onto my own custom event queue,
which in turn is processed in a loop within my wxThread::Entry function.
I use wxCondition::WaitTimeout in the thread to wait for events to
appear on the queue and wxCondition::Signal in the calling thread to
signal that an event has been posted.

In order to process an event, the processing thread passes the event as
the argument to a method on the eventhandler subclass which in turn just
calls wxEvtHandler::ProcessEvent ( this to avoid calling the override of
that method).

> Do I need to e.g. push the thread/evtHandler onto the main event
> handler stack from the wxApp thread?

I don't think I understand that. In any case, I think you will have to
override wxThread::Entry with a method that processes events. If it's
not called from wxThread::Entry, then it's not happening in a thread.

HTH,

[Marc Lindahl]

According to the wx documentation (e.g. multithreading overview) the
event handling framework is the recommended way to pass information
between threads. It seems this is provided already, which is why I'm
wondering- why do I need to make my own framework for it?

>
> To elaborate a bit, I override wxEvtHandler::ProcessEvent with an
> implementation that pushes the event onto my own custom event queue,
> which in turn is processed in a loop within my wxThread::Entry function.
> I use wxCondition::WaitTimeout in the thread to wait for events to
> appear on the queue and wxCondition::Signal in the calling thread to
> signal that an event has been posted.

I saw that, but I want to use PostEvent... disconnecting the queues so
they are nonblocking makes it thread safe and fits the paradigm of my
program.

So I'm wondering, if my thread also inherits from wxEvtHandler, as
outlined above, don't I get the default implementations of ProcessEvent,
etc. etc.? Shouldn't it 'just work'?

>
> In order to process an event, the processing thread passes the event as
> the argument to a method on the eventhandler subclass which in turn just
> calls wxEvtHandler::ProcessEvent ( this to avoid calling the override of
> that method).
>
> > Do I need to e.g. push the thread/evtHandler onto the main event
> > handler stack from the wxApp thread?
>
> I don't think I understand that.

If you look at the 'event' sample code, they show a custom event
handler, pushed on the handler stack. If the main wxApp thread (or
primary frame?) is servicing events, then I was wondering - should my
thread-eventhandlers be pushed on the main handler stack in order to get
events, or would they be posted to their own separate event handlers?

> In any case, I think you will have to
> override wxThread::Entry with a method that processes events. If it's
> not called from wxThread::Entry, then it's not happening in a thread.

for example call ProcessPendingEvents() in an infinite loop? I tried
that - nothing...

Of course, this may be a symptom of the *other* problem I'm having -
wxApp doesn't seem to process events in wx11 while it does in wxMSW and
wxMAC :(

>
> HTH,
>
> Aj

[chris mellon]

It's the recommended way to pass events FROM a worker thread TO the main thread.
Doing it the other way around isn't trivially supported. It's a bit of
a gotcha, because the obvious way (multiple inherit from wxThread and
wxEvtHandler), which you and I and probably lots of other people have
tried doesn't work. It will APPEAR to work with simple testing, which
is even worse.

Basically, there is only one event loop for a wxApp. It runs in the
main thread. When you post an event to a wxEvtHandler, that
wxEvtHandler gets added to a list of handlers that have pending
events. During idle time in the "real", os-specific event loop, wx
goes through that list and processes the pending events. The end
result of this is that if you do things the obvious way, it may appear
to work but your event handler is being actually being called in the
context of the main thread, not your worker thread. The way around
this is to provide your own implementation of ProcessEvent (and a
couple other functions), as Aj did, so that your custom wxEvtHandler
has it's own event loop and doesn't get involved in the main threads.
I wrote a similiar system but never fully tested it, his is probably
better. It'd be very nice if something like this could eventually make
into the wx core because it's a very commonly asked question and, as I
said, the reason the obvious approach doesn't actually work is a
little complicated and confusing (and, worse, it will often APPEAR to
work without actually doing what you want).

[Marc Lindahl]

Ah - OK. Well the doc doesn't make that clear. That's really bad -
that mechanism was one of the main reasons I chose wx over other
frameworks.

BTW - that does *not* seem to work under wX11 or wxGTK, though it does
for wxMSW and wxMac.

> Doing it the other way around isn't trivially supported. It's a bit of
> a gotcha, because the obvious way (multiple inherit from wxThread and
> wxEvtHandler), which you and I and probably lots of other people have
> tried doesn't work.

It should... I'd consider this a serious shortcoming!

Looking at the source code, event.cpp and event.h, maybe I'm missing
something but I see some specific thread support (wxUSE_THREADS) and
nothing to preclude using the class for a thread...?

> It will APPEAR to work with simple testing, which
> is even worse.

Probably due to the issues I'm having with wx11 it doesn't seem to work
with simple testing.

>
> Basically, there is only one event loop for a wxApp. It runs in the
> main thread. When you post an event to a wxEvtHandler, that
> wxEvtHandler gets added to a list of handlers that have pending
> events. During idle time in the "real", os-specific event loop, wx
> goes through that list and processes the pending events. The end
> result of this is that if you do things the obvious way, it may appear
> to work but your event handler is being actually being called in the
> context of the main thread, not your worker thread.

It is? At least in some of the implementations (though it seems to be
commented OUT of X11), the event loop acquires a mutex while actually
processing the event, and calls the function using the proper pointer,
it looks like (though I'm not at all sure how this relates to
detached/attached threads and contexts...)

> The way around
> this is to provide your own implementation of ProcessEvent (and a
> couple other functions), as Aj did, so that your custom wxEvtHandler
> has it's own event loop and doesn't get involved in the main threads.

I'm wondering - do I really need a totally custom implementation of
wxEvtHandler? (ugh!) Can I just overload some parts of it? Or is it
the evtloop that needs customization?

> I wrote a similiar system but never fully tested it, his is probably
> better. It'd be very nice if something like this could eventually make
> into the wx core because it's a very commonly asked question and, as I
> said, the reason the obvious approach doesn't actually work is a
> little complicated and confusing (and, worse, it will often APPEAR to
> work without actually doing what you want).

Or, perhaps evtloop.cpp needs work and that would solve it? If the
context of the event functions could be preserved then does it matter
that there's only one event loop?

[Martin Wegner]

Hello,

chris mellon wrote:

> [...]

>
>It's the recommended way to pass events FROM a worker thread TO the main thread.
>Doing it the other way around isn't trivially supported. It's a bit of
>a gotcha, because the obvious way (multiple inherit from wxThread and
>wxEvtHandler), which you and I and probably lots of other people have
>tried doesn't work. It will APPEAR to work with simple testing, which
>is even worse.
>
>
>

As I described in another thread started by me today ("custom events are
not processed"), it does also not work for me to pass events FROM the
worker thread TO the main thread. Since you say it has to work, I would
be very pleased if you could take a look into the thread and the
problems I described there.

> [...]

Regards,

martin

--
Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12
--
Homepage: http://mwegner.de.ms/
Powered by Gentoo Linux (http://www.gentoo.org/)

[Martin Wegner]

Hello,

Martin Wegner wrote:

>Hello,
>
>chris mellon wrote:
>
>
>
>>[...]
>>
>>It's the recommended way to pass events FROM a worker thread TO the main thread.
>>Doing it the other way around isn't trivially supported. It's a bit of
>>a gotcha, because the obvious way (multiple inherit from wxThread and
>>wxEvtHandler), which you and I and probably lots of other people have
>>tried doesn't work. It will APPEAR to work with simple testing, which
>>is even worse.
>>
>As I described in another thread started by me today ("custom events are
>not processed"), it does also not work for me to pass events FROM the
>worker thread TO the main thread. Since you say it has to work, I would
>be very pleased if you could take a look into the thread and the
>problems I described there.
>
>
>

I've just tested another thing that came to my mind: I did not use my
custom event but used a wxCommandEvent (chat message stored via
SetString() ) and posted it to the event queue: the result was that it
was also not processed (!) although I set up a callback using
EVT_COMMAND(MAIN_FRAME_ID, EVENT_ID, WChat::OnChatMessage)!
(MAIN_FRAME_ID and EVENT_ID are constants defined by me.)

So it seems that all events I post manually to the event queue are not
processed. Why?

[Marc Lindahl]

On Mon, 2004-06-28 at 16:33, Martin Wegner wrote:
> Hello,
>
> Martin Wegner wrote:
>
> >Hello,
> >
> >chris mellon wrote:
> >
> >
> >
> >>[...]
> >>
> >>It's the recommended way to pass events FROM a worker thread TO the main thread.
> >>Doing it the other way around isn't trivially supported. It's a bit of
> >>a gotcha, because the obvious way (multiple inherit from wxThread and
> >>wxEvtHandler), which you and I and probably lots of other people have
> >>tried doesn't work. It will APPEAR to work with simple testing, which
> >>is even worse.
> >>
> >As I described in another thread started by me today ("custom events are
> >not processed"), it does also not work for me to pass events FROM the
> >worker thread TO the main thread. Since you say it has to work, I would
> >be very pleased if you could take a look into the thread and the
> >problems I described there.
> >
> >
> >
> I've just tested another thing that came to my mind: I did not use my
> custom event but used a wxCommandEvent (chat message stored via
> SetString() ) and posted it to the event queue: the result was that it
> was also not processed (!) although I set up a callback using
> EVT_COMMAND(MAIN_FRAME_ID, EVENT_ID, WChat::OnChatMessage)!
> (MAIN_FRAME_ID and EVENT_ID are constants defined by me.)

what about trying
EVT_COMMAND(-1, EVENT_ID, WChat::OnChatMessage)

[Martin Wegner]

Hello,

Marc Lindahl wrote:

>>>>[...]

>>>>
>>>As I described in another thread started by me today ("custom events are
>>>not processed"), it does also not work for me to pass events FROM the
>>>worker thread TO the main thread. Since you say it has to work, I would
>>>be very pleased if you could take a look into the thread and the
>>>problems I described there.
>>>
>>I've just tested another thing that came to my mind: I did not use my
>>custom event but used a wxCommandEvent (chat message stored via
>>SetString() ) and posted it to the event queue: the result was that it
>>was also not processed (!) although I set up a callback using
>>EVT_COMMAND(MAIN_FRAME_ID, EVENT_ID, WChat::OnChatMessage)!
>>(MAIN_FRAME_ID and EVENT_ID are constants defined by me.)
>>
>>
>
>what about trying
>EVT_COMMAND(-1, EVENT_ID, WChat::OnChatMessage)
>
>
>

Tried it, but does also not work :(

[chris mellon]

On Mon, 28 Jun 2004 22:05:53 +0200, Martin Wegner <mehrwer...@web.de> wrote:
>
> Hello,
>
> chris mellon wrote:
>
> > [...]
> >
> >It's the recommended way to pass events FROM a worker thread TO the main thread.
> >Doing it the other way around isn't trivially supported. It's a bit of
> >a gotcha, because the obvious way (multiple inherit from wxThread and
> >wxEvtHandler), which you and I and probably lots of other people have
> >tried doesn't work. It will APPEAR to work with simple testing, which
> >is even worse.
> >
> >
> >
> As I described in another thread started by me today ("custom events are
> not processed"), it does also not work for me to pass events FROM the
> worker thread TO the main thread. Since you say it has to work, I would
> be very pleased if you could take a look into the thread and the
> problems I described there.
>
> > [...]

I've been looking at that thread too. I'm afraid I don't have anything
much to add, the code is very similiar to mine (except for creating
event objects on the heap - events are normally created on the stack
and copied around via the copy constructor. Creating them on the heap
will create memory leaks). However, I've only tested this on wxMSW.
It's looking more like this is a bug with wxX11 (does wxGTK work?),
and I don't have the knowledge to track it down.

[Martin Wegner]

Hello,

chris mellon wrote:

>>>It's the recommended way to pass events FROM a worker thread TO the main thread.
>>>Doing it the other way around isn't trivially supported. It's a bit of
>>>a gotcha, because the obvious way (multiple inherit from wxThread and
>>>wxEvtHandler), which you and I and probably lots of other people have
>>>tried doesn't work. It will APPEAR to work with simple testing, which
>>>is even worse.
>>>
>>As I described in another thread started by me today ("custom events are
>>not processed"), it does also not work for me to pass events FROM the
>>worker thread TO the main thread. Since you say it has to work, I would
>>be very pleased if you could take a look into the thread and the
>>problems I described there.
>>
>>
>>
>>>[...]
>>>
>>>
>
>I've been looking at that thread too. I'm afraid I don't have anything
>much to add, the code is very similiar to mine (except for creating
>event objects on the heap - events are normally created on the stack
>and copied around via the copy constructor. Creating them on the heap
>will create memory leaks). However, I've only tested this on wxMSW.
>It's looking more like this is a bug with wxX11 (does wxGTK work?),
>and I don't have the knowledge to track it down.
>
>
>

If you mean the allocating with the new operator by creating it on the
heap, I've also tested creating it on the stack with the same result.
Currently I'm using wxGTK not wxX11, so it has to be a problem of wxGTK.

Since this seems to be an obvious bug, how can we inform the wx staff
about it? I remember seeing wxWidgets at SourceForge, maybe they use the
Bug Tracker there ...

[chris mellon]

<snip>

> >I've been looking at that thread too. I'm afraid I don't have anything
> >much to add, the code is very similiar to mine (except for creating
> >event objects on the heap - events are normally created on the stack
> >and copied around via the copy constructor. Creating them on the heap
> >will create memory leaks). However, I've only tested this on wxMSW.
> >It's looking more like this is a bug with wxX11 (does wxGTK work?),
> >and I don't have the knowledge to track it down.
> >
> >
> >
> If you mean the allocating with the new operator by creating it on the
> heap, I've also tested creating it on the stack with the same result.
> Currently I'm using wxGTK not wxX11, so it has to be a problem of wxGTK.
>
> Since this seems to be an obvious bug, how can we inform the wx staff
> about it? I remember seeing wxWidgets at SourceForge, maybe they use the
> Bug Tracker there ...
>

Write a patch to the minimal sample that demonstrates the bug (as
small as possible, using built in events rather than custom ones) and
post it to the SF bug tracker.

>
> Regards,
>
> martin
>
> --
> Get my public GPG key from pgp.mit.edu or wwwkeys.pgp.net - Key ID: 0x44085D12
> --
> Homepage: http://mwegner.de.ms/
> Powered by Gentoo Linux (http://www.gentoo.org/)
>
>
>
>

> signature.asc - 1K
>

[Martin Wegner]

Hello,

chris mellon wrote:

> [...]

>
>Write a patch to the minimal sample that demonstrates the bug (as
>small as possible, using built in events rather than custom ones) and
>post it to the SF bug tracker.
>
>

This is no longer necessary, I think:

Thanks to a hint of Łukasz Michalski in the other thread "custom events
are not processed" I was able to resolve my problem using custom events
with wxGTK: I had to call the wxEvent constructor also when an instance
is created using the copy constructor. Since I didn't do it, all events
that were cloned for the event queue did not have my custom event type.
I want to thank everybody who made suggestions how to resolve this issue.

@Marc Lindahl: Is it possible that you have the same bug?

[Marc Lindahl]

On Tue, 2004-06-29 at 16:30, Martin Wegner wrote:
> Hello,
>
> chris mellon wrote:
>
> > [...]
> >
> >Write a patch to the minimal sample that demonstrates the bug (as
> >small as possible, using built in events rather than custom ones) and
> >post it to the SF bug tracker.
> >
> >
> This is no longer necessary, I think:
>
> Thanks to a hint of Łukasz Michalski in the other thread "custom events
> are not processed" I was able to resolve my problem using custom events
> with wxGTK: I had to call the wxEvent constructor also when an instance
> is created using the copy constructor. Since I didn't do it, all events
> that were cloned for the event queue did not have my custom event type.
> I want to thank everybody who made suggestions how to resolve this issue.
>
> @Marc Lindahl: Is it possible that you have the same bug?

I don't think so since it works on wxMSW and wxMac but not wxX11 or
wxGTK... anyway here is the class def for the custom event:

class wxDebugStatusEvent : public wxEvent
{
public:
wxDebugStatusEvent( const wxString& debug = wxT("default debug event"))
: wxEvent(0, wxEVT_DEBUG_STATUS),
m_debug(debug)
{ }

wxDebugStatusEvent(const wxDebugStatusEvent & event)
: wxEvent(event),
m_debug(event.m_debug)
{ }

wxString GetDebug() const { return m_debug; } ///< get Debug
string

void SetDebug(const wxString& debug) { m_debug = debug; } ///< set
Debug string

virtual wxEvent *Clone() const { return new
wxDebugStatusEvent(*this); }

private:
wxString m_debug;

private:
DECLARE_DYNAMIC_CLASS(wxDebugStatusEvent)
};

.... and the other interesting stuff:

DECLARE_EVENT_TYPE(wxEVT_DEBUG_STATUS, wxDEBUG_STATUS_ID)
(wxDEBUG_STATUS_ID is my enum)

DEFINE_EVENT_TYPE(wxEVT_DEBUG_STATUS)

#define EVT_DEBUG_STATUS(id, fn) \
DECLARE_EVENT_TABLE_ENTRY( \
wxEVT_DEBUG_STATUS, id, -1, \
(wxObjectEventFunction)(wxEventFunction) wxStaticCastEvent(
wxDebugStatusEventFunction, &fn ), \
(wxObject *) NULL \
),

typedef void
(wxEvtHandler::*wxDebugStatusEventFunction)(wxDebugStatusEvent&);

...and then in actual use in thread, where m_app is a pointer to my
wxApp:
wxDebugStatusEvent debugEvent(wxT("Thread created"));
wxPostEvent(m_app, debugEvent);

in my wxApp:

BEGIN_EVENT_TABLE(myApp wxApp)
EVT_DEBUG_STATUS(-1, myApp::UIDebugEvent)
...etc

>
> Regards,
>
> martin

[Martin Wegner]

Hello,

Marc Lindahl wrote:

> [...]
>

>>@Marc Lindahl: Is it possible that you have the same bug?
>>
>>
>
>I don't think so since it works on wxMSW and wxMac but not wxX11 or
>wxGTK... anyway here is the class def for the custom event:
>
>class wxDebugStatusEvent : public wxEvent
>{
>public:
> wxDebugStatusEvent( const wxString& debug = wxT("default debug event"))
> : wxEvent(0, wxEVT_DEBUG_STATUS),
> m_debug(debug)
> { }
>
> wxDebugStatusEvent(const wxDebugStatusEvent & event)
> : wxEvent(event),
> m_debug(event.m_debug)
> { }
>
>

Could you please try this here:

wxDebugStatusEvent(const wxDebugStatusEvent & event)
: wxEvent(-1, wxEVT_DEBUG_STATUS),
m_debug(event.m_debug)
{ }

Perhaps you have just not posted it: have you IMPLEMENT_DYNAMIC_CLASS in
your cpp file?

[Marc Lindahl]

On Wed, 2004-06-30 at 09:13, Martin Wegner wrote:
> Hello,
>
> Marc Lindahl wrote:
>
> > [...]
> >
> >>@Marc Lindahl: Is it possible that you have the same bug?
> >>
> >>
> >
> >I don't think so since it works on wxMSW and wxMac but not wxX11 or
> >wxGTK... anyway here is the class def for the custom event:
> >
> >class wxDebugStatusEvent : public wxEvent
> >{
> >public:
> > wxDebugStatusEvent( const wxString& debug = wxT("default debug event"))
> > : wxEvent(0, wxEVT_DEBUG_STATUS),
> > m_debug(debug)
> > { }
> >
> > wxDebugStatusEvent(const wxDebugStatusEvent & event)
> > : wxEvent(event),
> > m_debug(event.m_debug)
> > { }
> >
> >
> Could you please try this here:
>
> wxDebugStatusEvent(const wxDebugStatusEvent & event)
> : wxEvent(-1, wxEVT_DEBUG_STATUS),
> m_debug(event.m_debug)
> { }

Well, guess what? That WORKED!!! Thanks!!
OK, now.... why?? Shouldn't it figure it out from the event type?
And the -1... that's the ID of the event-generating 'window', right? So
-1 == wxANY? But, assuming I cared about the ID, how would I go about
propogating that? Maybe:
wxDebugStatusEvent(int winid = 0,const wxDebugStatusEvent &
event)
: wxEvent(winid, wxEVT_DEBUG_STATUS),
m_debug(event.m_debug)
{ }

>

Yes I did - won't compile otherwise!

Thanks for your help!!

>
> Regards,
>
> martin

[Marc Lindahl]

If, as people have been saying, you can have a wxThread also inherit
from wxEvtHandler and have it's own event handler, then how in the wx
world can you start a thread and then communicate with it? Anything
within wx that can do this? I want to have 'long running threads' that
I can give instructions to...

[Vadim Zeitlin]

On Wed, 30 Jun 2004 18:57:26 -0400 Marc Lindahl <ma...@bowery.com> wrote:

ML> If, as people have been saying, you can have a wxThread also inherit
ML> from wxEvtHandler and have it's own event handler, then how in the wx
ML> world can you start a thread and then communicate with it? Anything
ML> within wx that can do this? I want to have 'long running threads' that
ML> I can give instructions to...

There is no generic built in mechanism for inter thread communication in
wxWindows. But with the classes which you do have you can implement
whatever best suits your needs, e.g. either have a simple flag which is set
from the main thread and tells the other one(s) to do something or
implement a real message queue.

Regards,
VZ

[Casey ODonnell]

Whether it is the right/good/best solution or not...I've been using
wxMutex and pointers to a data structure owned by the wxApp object.
So in my thread constructors I pass in a pointer to some data
structure that I want to share between threads. Then using the
wxMutex classes I can ensure that they don't munge one anothers data.
I've refered to it (correctly or not) as a shared memory space for the
threads to communicate through.

Cheers.
CKO

[Chris Mellon]

Take a look at Aj Lavin's Threadhandler classes:

http://www.ectologic.com/code/

[Marc Lindahl]

On Thu, 2004-07-01 at 09:15, Chris Mellon wrote:
> Take a look at Aj Lavin's Threadhandler classes:
>
> http://www.ectologic.com/code/

Yeah, I downloaded that - Aj had posted previously. Though, unless I'm
missing something, I'm stumped why there's no PostEvent type thing -
instead it looks like he only has ProcessEvent and some mutex, which
means the threads are blocking each other... maybe I can extend it...

Or... maybe UNIX sockets? maybe a wx wrapper for them (dunno if a
similar thing exists in windoze or osx?)

[Marc Lindahl]

On Thu, 2004-07-01 at 08:19, Casey ODonnell wrote:
> Whether it is the right/good/best solution or not...I've been using
> wxMutex and pointers to a data structure owned by the wxApp object.
> So in my thread constructors I pass in a pointer to some data
> structure that I want to share between threads. Then using the
> wxMutex classes I can ensure that they don't munge one anothers data.
> I've refered to it (correctly or not) as a shared memory space for the
> threads to communicate through.

Which is good for a mailbox type of exchange... I was hoping for a queue
type of deal, like the event system.

>
> Cheers.
> CKO
>
> > ML> If, as people have been saying, you can have a wxThread also inherit
> > ML> from wxEvtHandler and have it's own event handler, then how in the wx
> > ML> world can you start a thread and then communicate with it? Anything
> > ML> within wx that can do this? I want to have 'long running threads' that
> > ML> I can give instructions to...
> >
> > There is no generic built in mechanism for inter thread communication in
> > wxWindows. But with the classes which you do have you can implement
> > whatever best suits your needs, e.g. either have a simple flag which is set
> > from the main thread and tells the other one(s) to do something or
> > implement a real message queue.
>

[Aj Lavin]

Hi Marc,

On Thu, 2004-07-01 at 14:03, Marc Lindahl wrote:
> On Thu, 2004-07-01 at 09:15, Chris Mellon wrote:
> > Take a look at Aj Lavin's Threadhandler classes:
> >
> > http://www.ectologic.com/code/
>
> Yeah, I downloaded that - Aj had posted previously. Though, unless I'm
> missing something, I'm stumped why there's no PostEvent type thing -
> instead it looks like he only has ProcessEvent and some mutex, which

> means the threads are blocking each other... [...]

There is no ThreadHandler::AddPendingEvent (which would be called by
wxPostEvent) because wxEvtHandler::AddPendingEvent is not a virtual
function in wxWidgets 2.4. Luckily, wxEvtHandler::ProcessEvent is
virtual.

ProcessEvent and wxPostEvent basically do the same thing when used with
a ThreadHandler object: they both cause the event to be handled in the
ThreadHandler's thread pool.

wxPostEvent calls wxEvtHandler::AddPendingEvent which eventually causes
ThreadHandler::ProcessEvent to be called. The only difference is calling
ThreadHandler::ProcessEvent directly will be slightly faster.

The mutex you refer to is only held by the calling thread long enough to
call wxCondition::Signal, which never blocks, and is only held by the
event-processing thread long enough to check whether the event queue is
empty.

The mutex / condition trick for inter-thread communication can probably
be found in any book that covers pthreads. I learned it from "Unix
Network Programming" by W. Richard Stevens, which is excellent btw.

[Marc Lindahl]

Hi Aj,
Thanks for the enlightening post. BTW, I successfully compiled your
Threadhandler package under wx2.5.2, fedora and GTK+. Also compiled
with x11, but with x11 all the menu picks cause a seg fault - I'm
getting the same thing in my program. Also some calls you use are
depreciated:

g++ -c `wx-config --cxxflags` -o threadhandler.o threadhandler.cpp
threadhandler.cpp: In member function `virtual bool
ThreadHandler::HasDynamicHandler(wxEvent&)':
threadhandler.cpp:318: warning: `First' is deprecated (declared at
/opt/wx-gtk-2.5.2/include/wx/list.h:1022)
threadhandler.cpp:324: warning: `Data' is deprecated (declared at
/opt/wx-gtk-2.5.2/include/wx/list.h:1015)
threadhandler.cpp:339: warning: `Next' is deprecated (declared at
/opt/wx-gtk-2.5.2/include/wx/list.h:1013)

I'm going to check out this package a little more...

[Aj Lavin]

On Thu, 2004-07-01 at 21:42, Marc Lindahl wrote:
> Hi Aj,
> Thanks for the enlightening post. BTW, I successfully compiled your
> Threadhandler package under wx2.5.2, fedora and GTK+.

I haven't used wxWidgets 2.5 yet and do not support it for
Threadhandler, but I am glad you had some success with it.

> Also compiled with x11, but with x11 all the menu picks cause
> a seg fault - I'm getting the same thing in my program.

Does the "thread" sample work Ok under x11? I have only tested wxGTK and
wxMSW so far.

> Also some calls you use are

> depreciated: [...]

Good catch. I was mimicking the code in
wxEvtHandler::ProcessPendingEvents() that uses the same deprecated
calls. I'll clean it up in the next release.

Regards,

[Marc Lindahl]

On Fri, 2004-07-02 at 04:12, Aj Lavin wrote:
> On Thu, 2004-07-01 at 21:42, Marc Lindahl wrote:
> > Hi Aj,
> > Thanks for the enlightening post. BTW, I successfully compiled your
> > Threadhandler package under wx2.5.2, fedora and GTK+.
>
> I haven't used wxWidgets 2.5 yet and do not support it for
> Threadhandler, but I am glad you had some success with it.

Good success - 2.5.2 (because I'm not sure about previous versions,
there were differences)

>
> > Also compiled with x11, but with x11 all the menu picks cause
> > a seg fault - I'm getting the same thing in my program.
>
> Does the "thread" sample work Ok under x11? I have only tested wxGTK and
> wxMSW so far.

No, the thread sample, and anything with menu bar, segfaults when you
pick a dropdown menu (like about, quit, anything).

>
> > Also some calls you use are
> > depreciated: [...]
>
> Good catch. I was mimicking the code in
> wxEvtHandler::ProcessPendingEvents() that uses the same deprecated
> calls. I'll clean it up in the next release.

Check the 2.5.2 sources, they probably updated it...

>
> Regards,
>
> Aj