So I'm trying to encapsulate a timer class which will handle all of the gory details of multi-threading and timers.
Here's my code:
TimedEvent.h
class TimedEvent : public QObject
{
Q_OBJECT
public:
explicit TimedEvent(QObject *parent = 0);
TimedEvent(const int intervalInMsecs);
virtual void TimeoutWorkProcedure() = 0;
private slots:
void TimeoutWorkThread();
protected:
QTimer *myTimer;
};
TimedEvent.cpp
TimedEvent::TimedEvent(QObject *parent) :
QObject(parent)
{
}
TimedEvent::TimedEvent(const int intervalInMsecs)
{
// Create timer
//
myTimer = new QTimer(this);
// Connect the timeout signal to our virtual callback function
//
connect(myTimer, SIGNAL(timeout()), this, SLOT(TimeoutWorkThread()));
myTimer->start(intervalInMsecs);
}
void TimedEvent::TimeoutWorkThread()
{
QtConcurrent::run(this, &TimedEvent::TimeoutWorkProcedure());
}
The idea was TimedEvent would be a base class and I would be able to create derived classes very easily.
class MyClass : public TimedEvent
{
public:
MyClass( const int timeoutInMsecs );
TimeoutWorkProcedure(){ do some background stuff };
};
The problem is I cannot figure out what to pass to the QtConcurrent::run call. Not sure this is even possible. I could move the QTConcurrent::run call to the derived class, but I anticipate there being several of these derived classes.
Any ideas would be appreciated.
K.
This code:
void TimedEvent::TimeoutWorkThread()
{
QtConcurrent::run(this, &TimedEvent::TimeoutWorkProcedure);
}
is perfectly fine and will do what you expect. It will call an overridden version of TimeoutWorkProcedure.
Related
I have a very simple and yet complicated (atleast for me) question on how to call a method/function outside a class but on a same namespace in c++/cli.
I know that you need to create an instance of an object before you can call a method which is inside a class, something like:
namespace Cars {
public ref class MyClass
{
void Honda(int i)
{
//some code
}
}
void Register()
{
MyClass c;
c.Honda(1);
//some code
}
}
But how do I do the opposite? Like how do I call Register() inside the MyClass::Honda function if they are on the same namespace but not on the same class?
I tried Cars::Register() but it gives an error saying that:
Register() is not a member of "Cars".
Edit: I added the actual code that I tried to access the Register() method.
namespace Cars {
public ref class MyClass
{
void Honda(int i)
{
Cars::Register();
}
}
void Register()
{
//some code
}
}
The line Cars::Register(); do not give any error when I save but when I try to rebuild my application it gives the error below:
Error C2039 'Register': is not a member of 'Cars'
Error C3861 'Register': identifier not found
Just to note that when I put Register() inside the MyClass, everything works well (for some reason I just need to put it outside the class)
Thanks!
There are 2 issues in your code:
Missing ; at the end of the definition for ref class MyClass.
Register() should be defined (or at least declared) before calling it.
Fixed version:
namespace Cars
{
// Defintion:
void Register()
{
//some code
}
public ref class MyClass
{
void Honda(int i)
{
Cars::Register();
}
};
}
Or alternatively:
namespace Cars
{
// Declaration:
void Register();
public ref class MyClass
{
void Honda(int i)
{
Cars::Register();
}
};
// Definition:
void Register()
{
//some code
}
}
Note: since you call Register within the same namespace, you can actually drop the Cars:: qualifier, i.e. simply call: Register();. You also keep it of course, if you think it improves readability.
I'm attempting to run a function concurrently using QtConcurrent but I'm running into issues with one of the arguments.
As a precursor, lets say I have the following classes and "interfaces":
class DataMessage : public QObject {
Q_OBJECT
// ... fields and methods
};
class ITimeStampInfo {
public:
virtual QDateTime timestamp() const = 0;
};
Q_DECLARE_INTERFACE(ITimeStampInfo, "My.TimeStampInfo/1.0")
class IDataLengthInfo {
public:
virtual int dataLength() const = 0;
};
Q_DECLARE_INTERFACE(IDataLengthInfo, "My.IDataLengthInfo/1.0")
class DataMessage1 : public DataMessage, public ITimeStampInfo {
Q_OBJECT
Q_INTERFACES(ITimeStampInfo)
// other fields, etc
QDateTime timestamp() const;
};
class DataMessage2 : public DataMessage, public IDataLengthInfo {
Q_OBJECT
Q_INTERFACES(IDataLengthInfo)
// other fields
int dataLength() const;
};
And a class function called processDataMessages:
void MyClass::processDataMessages(DataMessage *msg) {
// Previous to this function being called, concrete `DataMessage`
// instances are created and passed by pointer into this function
// Determine the data in the message
IDataLengthInfo *dl = qobject_cast<IDataLengthInfo*>(msg);
if (dl) {
qDebug() << "Got a message with IDataLengthInfo";
}
ITimeStampInfo *ts = qobject_cast<ITimeStampInfo*>(msg);
if (ts) {
qDebug() << "Got a message with ITimeStampInfo";
}
// etc
}
This processDataMessages is called in a slot. During normal operation, this function works perfectly and the qDebug() statements execute as expected as the pointer is correct - for example, inspecting the pointer type in the debugger results in a DataMessage1 type, for instance
I now want to run this function asynchronously as potentially, there may be a bit of work to do. If I try to execute this function using QtConcurrent::run from within the slot as follows:
void MyClass::dataReceived(DataMessage *msg) {
// this->processDataMessages(msg);
QtConcurrent::run(this, &MyClass::processDataMessages, msg);
}
Now when I break on the first qobject_cast line in the processDataMessages function, I can see that the msg pointer is of type DataMessage and not any of the DataMessage1 or DataMessage2 types.
Something is being lost during the operation of QtConcurrent::run and its probably something dumb I've missed.
Ok, so as it turns out, the following code works:
QFuture<void> f = QtConcurrent::run(this, &MyClass::processDataMessages, msg);
// Wait for the function to finish
f.waitForFinished();
Doesn't really seem any different to the original but something in the return value may be maintaining state??
I've been reading "The C# Programming Language. 4th Edition" and found the following code sample:
interface I<T>
{
void F();
}
class Base<U>: I<U>
{
void I<U>.F() {...}
}
class Derived<U,V>: Base<U>, I<V>
{
void I<V>.F() {...}
}
...
I<int> x = new Derived<int,int>();
x.F();
Authors state that after calling x.F() the method in Derived will be invoked, because
"Derived<int,int> effectively reimplements I<int>"
I've checked with C# 4.0 compiler and found that this statement actually invokes the method in Base. Can you explain such behaviour?
Thanks in advance.
edit: here is the working code used for check:
using System;
interface I<T>
{
void F();
}
class Base<U>: I<U>
{
void I<U>.F()
{
Console.WriteLine("F() in Base");
}
}
class Derived<U,V>: Base<U>, I<V>
{
void I<V>.F()
{
Console.WriteLine("F() in Derived");
}
}
public class MainClass
{
public static void Main()
{
I<int> x = new Derived<int,int>();
x.F();
}
}
It outputs "F() in Base", so I don't know where I am wrong.
Because both Base and Derived interface from I.
void I<V>.F() {...} The method may be called/triggered from "Derived" but is executing the method defined in the interface.
void F();
I have a class defined as below:
ref class myClass
{
PictureBox^ pic2;
public:
void setPic2() { pic2 = gcnew PictureBox; }
template<typename UnaryOperator>
void setPic2Click(Form^ x, UnaryOperator op) { pic2->Click += gcnew EventHandler(x, op); }
};
And in my Windows form class:
namespace testProject
{
public ref class Form1 : public System::Windows::Forms::Form
{
void Form1_Load(Object^ sender, EventArgs^ e)
{
rect1.setPic2();
rect1.setPic2Click(this, std::bind1st(std::mem_fun(&Form1::pic2_Click), this));
}
void pic2_Click(Object^ sender, EventArgs^ e)
{
// do something...
}
When compiled, it generated this error which is related to the rect1.setPic2Click call...:
error C3374: can't take address of 'testProject::Form1::pic2_Click' unless creating delegate instance
Basically, I tried to encapsulate the interface of the picturebox by create the instance method setPic2Click. Is this the right approach? Any suggestion how to remedy this error?
Your only mistake is that you're trying to mix managed and unmanaged C++/CLI code in a way that doesn't work (and doesn't make sense).
.NET delegates already have a bound first parameter. All you need is:
class1->setPic2Click(gcnew System::EventHandler(this, &Form1::pic2_Click));
and
void setPic2Click(System::EventHandler^ op) {pic2->Click += op;}
I am creating a thread using this call:
m_pThread=AfxBeginThread(read_data,(LPVOID)hSerial);
read_data is a static method in my class.
But I want to call a non static method and make a thread.
As I want to share a variable between this thread and one of my class method.
I tried taking a static variable but it gave some errors.
You cannot create a thread using a non-static member of a function as the thread procedure: the reason is all non-static methods of a class have an implicit first argument, this is pointer this.
This
class foo
{
void dosomething();
};
is actually
class foo
{
void dosomething(foo* this);
};
Because of that, the function signature does not match the one you need for the thread procedure. You can use a static method as thread procedure and pass the this pointer to it. Here is an example:
class foo
{
CWindThread* m_pThread;
HANDLE hSerial;
static UINT MyThreadProc(LPVOID pData);
void Start();
};
void foo::Start()
{
m_pThread=AfxBeginThread(MyThreadProc,(LPVOID)this);
}
UINT foo::MyThreadProc(LPVOID pData)
{
foo* self = (foo*)pData;
// now you can use self as it was this
ReadFile(self->hSerial, ...);
return 0;
}
I won't repeat what Marius said, but will add that I use the following:
class foo
{
CWindThread* m_pThread;
HANDLE hSerial;
static UINT _threadProc(LPVOID pData);
UINT MemberThreadProc();
void Start();
};
void foo::Start()
{
m_pThread=AfxBeginThread(_threadProc,(LPVOID)this);
}
UINT foo::MyThreadProc(LPVOID pData)
{
foo* self = (foo*)pData;
// call class instance member
return self->MemberThreadProc();
}
UINT foo::MemberThreadProc()
{
// do work
ReadFile(hSerial, ...);
return 0;
}
I follow this pattern every time I use threads in classes in MFC apps. That way I have the convenience of having all the members like I am in the class itself.