I have just started learning wxWidgets, version 3.0, with C++. I have noted, that event handling in wxWidgets is done by Event tables. But one tutorial also mentioned Connect() - actually it just said : " this tutorial will be using event tables, not Connect() " .
I would like to know, what is the philosophy behind Event tables and behind Connect() ? What is the difference, when is one more suitable than the other... Thank you.
First, don't use Connect() which was superseded by Bind() which is better in every way.
Second, both static (using event tables) and dynamic (using Bind()) methods of handling events work and you can use whichever you prefer. Personally, I recommend using Bind() because
It is much more flexible: can be used to connect the event on one object to any other object or even a free function or, in C++11, a lambda.
It is safer and catches most common errors such as using wrong event handler signature at compile time.
It is "dynamic", i.e. you can connect and disconnect the handler at any time.
The main advantages of the event tables are that
They are slightly shorter, especially in pre 3.0 versions.
They are much more common in documentation, examples, tutorials, ... just because they had a 15 year head start on Bind().
However they are clumsier to use because they require subclassing (deriving a new class from) an object in order to handle non-command events in it and they don't detect all errors at compile-time allowing you to write code that compiles fine but crashes at run-time.
Related
What exactly is an event table and what does it do? I am asking regarding wxWidgets but maybe its a general GUI programming concept, so please correct me on that.
To keep it simple, the evend table tells which function to call when which event occurrs.
However, it is an old way of mapping events to functions.
It is no longer recommanded because isn't very flexible, and use macro tricks to do its job.
Macros themselves are generally not very recommanded in C++.
Unless you must stick to C++03, you should no longer use event tables.
Instead, you should use the bind method for New WXWidgets projects in C++11 or later.
Bind is more flexible, and don't use macro.
You will find this recommandation in the WXWidgets tutorials, too.
You must still be able to read and understand old event tables, though, because many samples haven't been updated for ages.
An event table tells wxWidgets to map events to member functions. It should be defined in a .cpp file.
wxBEGIN_EVENT_TABLE()
is an example of a macro
In addition to the other answers, I'd like to say that if you're starting learning wxWidgets, you should know that event tables are a legacy way of handling events and that using Bind() is the preferred way of doing it in the new code.
In particular, Bind() is much less "magic", and doesn't use any macros.
I am new to Qt and have taken over a project from a developer who left our company. I see several places in his code where a signal is emitted, but there is no connection to a slot or other reference in the code to the signal. Is there a reason to do this that I am unaware of?
I have searched through the code trying to find anything that would reference the signals being emitted, but I cannot find anything other than the code that does the emit.
//from the header file
signals:
void newInstance();
void SingleInstance::newConnection()
{
emit newInstance(); // this is not referenced anywhere else in the project
qDebug() << "New connection loading...";
mSocket = mServer.nextPendingConnection();
connect(mSocket,SIGNAL(readyRead()),this,SLOT(readyRead()));
}
There are no errors and the application runs fine. I am just trying to see if there is something I am missing because of lack of experience with Qt.
One could ask: Why stop at your application? Qt provides lots and lots of signals that are not used anywhere either - neither your application uses them, nor do the Qt modules that you likely use need them. Would you wish to remove those signals? Why not?
In typical Qt applications, most signals are not connected. That's by design: the signals are there to indicate "interesting" situations, that might be useful to someone. Whether the "someone" is there to use them (connect to them) is not a given. Signals and slots are means of decoupling software elements: when designing an API (e.g. a class), you might wish to provide relevant signals that might be of use later.
Signals in your application code, that happen not to be connected, shouldn't be immediately thought of as being redundant. Think of why would the author of that code include these signals. They might have had a need for them that has now passed (look in the git history around the time that code was added and see if any references to these signals were added as well, but later removed) - in this case you might consider to remove the signals. But this is a rather narrow case, and you should first understand the design intent that the signals represent. Assuming a competent team, those signals were put there for some reason. Understanding that likely reason (or reasons) is the prerequisite to changing the code. This is the case with any code, not only with signal definitions.
Also: make sure that no other projects within your organization depend on the repository that holds the code you're using. Someone could be using it as a git submodule, for example. And they may be using those signals. You need to make sure before you start removing functionality.
It depends on the intention. If you do not use you can delete.
Signals express a situation that may be worth handling or reacting to. It is optional to connect to them.
Signals, as well as the rest of the API, is a contract. You cannot change the contract without breaking functionality.
If you stop emitting the signal, part of a project depending on such module may fail (or just stop working as intended, which may be worse and harder to detect). You should in this case document it, change API version...
If not emitted at all anymore, you should remove the signal declaration too (or marking it someway deprecated), so, at least, compilation will fail in depending modules (if using the Qt 5 syntax, if still using the SIGNAL macro it will be harder to detect, and in real-time only).
Obviously, it's not the same the API of a base-level module, than a class in a top-level project that no one depends on and where you have full control.
The question is in the title: How can I have the callback for SetWinEventHook have some context information? Usually functions that take callbacks also take a context parameter they pass on to the callbacks, but not this one.
Using a global (including thread_local) variable as suggested in SetWinEventHook with custom data for example is almost certainly unacceptable.
There may be more than one caller to the utility function that sets the WinEvent hook to do something so global is out. thread_local may work, but it also may not. What if the callback calls the same utility function and sets yet another hook? They will both get called next time I pump messages. Using thread_local requires me to define a contract that forbids a single thread to set more than one WinEvent hook through me, and requires my callers to abide by it. That's a pretty arbitrary and artificial limitation and I prefer not to set it.
I'm reimplementing in C++ a little PoC I had in C#. There I could simple use capturing lambdas and they would convert to function pointers that I can pass via P/Invoke to SetWinEventHook. C++ unfortunately doesn't have that feature (probably because it requires allocating WX memory and dynamically generating a little code, which some platforms don't allow), but perhaps there is a platform-specific way to do this?
I seem to remember that ATL did something like that in the past, and I guess I can probably implement something like this too, but maybe there's a better way? If not, perhaps somebody has already written something like that?
(Another valid solution would be a clever-enough data structure and algorithm to solve the reentrancy problem.)
I need something (like annotations, reflections, defines, or something completely different) that I can add to a arbitrary function or function call.
For every function f, which has this something added, a specific function t should be invoked with the parameters of f.
The function t should now send its parameters over the network to a other program.
Is there a way to do something like this?
The general principle behind this is called marshalling, where the parameteres of a function are wrapped up in a way that you can send them to some other computer. The sender marshalls the parameters, the receiver unmarshalls. Both need to have an understanding on the types, and must do it in a way consistent with the different computer architectures.
Remote procedure calls (RPC) are one way of sending function calls from one computer to another, and need some marshalling behind them.
XMLRPC, as pointed out by Victor, is one way to do it, where the marshalling happens via XML. There are lots of other packages, and googling for RPCs and marshalling should give more possibilities, but XMLRPC might be just what you want.
CORBA and DCOM are related mechanism. The idea of sending function calls between computers is one major concept in distributed systems, so maybe look a round a little more, probably there are very simple solutions to your specific problem.
XMLRPC library might be the one you're looking for, if you just want to call the function on the remote machine. It generates the code for marshalling the parameters using the XML RPC specs.
You can use Google Protocol Buffers for this: https://developers.google.com/protocol-buffers/docs/overview
It is an easy to use and portable serialisation library. In addition you will be able to write programs able to 'talk' to your C++ code (deserialize objects serialised by your C++ code) in different languages, like Python, Java, and others, which can be very useful, for example for easier testing.
If you are in a Linux/BSD environment, do 'man rpcgen'. I found it easier to build distributed apps with than DCE/CORBA.
Let's give what you are trying to do a name, 'inter-process function call' or IFC.
I have been working on a IFC compiler (ifcc) for generating scalable cloud apps with realtime browser based visibility built into the apps.
The prototype compiler is working. The visibility portion of the framework is also working but not yet integrated into the compiler for generating instrumented code.
Ifcc takes as its input a C include file and based on the function prototype declarations in the .h file, it generates C source code for marshalling, and, client and server proxy/stubs suitable for use in a heterogenous (takes care of byte ordering/big endian/little endian) environment.
And, Oh, by the way, ifcc is a smart compiler. It not only handles arrays, typedefs, nested structures, etc. but it also does arbitrary pointer chasing. E.g. if you call a function with a pointer to doubly link list, it will package it up, send it and recreate the doubly link list at the receiving end.
If people are interested in playing with it, add a comment with output of 'uname -a' of your system as well as which compiler you are using. If there is lots of interest I may make it available for developers to learn/play/experiment with.
Me and a friend are developing an application which uses Boost::Python. I have defined an interface in C++ (well a pure virtual class), exposed through Boost::Python to the users, who have to inherit from it and create a class, which the application takes and uses for some callback mechanism.
Everything that far goes pretty well. Now, the function callback may take some time (the user may have programmed some heavy stuff)... but we need to repaint the window, so it doesn't look "stuck".We wanted to use Boost::Thread for this. Only one callback will be running at a time (no other threads will call python at the same time), so we thought it wouldn't be such a great deal... since we don't use threads inside python, nor in the C++ code wrapped for python.
What we do is calling PyEval_InitThreads() just after Py_Initialize(), then, before calling the function callback inside it's own boost thread, we use the macro PY_BEGIN_ALLOW_THREADS and, and the macro PY_END_ALLOW_THREADS when the thread has ended.
I think I don't need to say the execution never reaches the second macro. It shows several errors everytime it runs... but t's always while calling the actual callback. I have googled a lot, even read some of the PEP docs regarding threads, but they all talk about threading inside the python module (which I don't sice it's just a pure virtual class exposed) or threading inside python, not about the main application calling Python from several threads.
Please help, this has been frustrating me for several hours.
Ps. help!
Python can be called from multiple threads serially, I don't think that's a problem. It sounds to me like your errors are just coming from bad C++ code, as you said the errors happened after PY_BEGIN_ALLOW_THREADS and before PY_END_ALLOW_THREADS.
If you know that's not true, can you post a little more of your actual code and show exactly where its erroring and exactly what errors its giving?