#define BT_DATABASE_TEST "../../BT_DATABASE/BluetoothDatabase.txt"
constchar *command = "bluetoothctl show | tee " BT_DATABASE_TEXT " | tee /tmp/temp";
2. Maybe something like this:
std::string var = "blah_blah.txt";
std::string command = std::string("bluetoothctl show | tee ") + var + std::string("" | tee /tmp/temp");
QP->start("/bin/sh", QStringList() << "-c" << command.c_str());
Yes. If objects belong to different classes, the only way to store them in a container is to use pointers, because the container allocates the same amount of memory for each entry. If you also want the container to delete an entry when you erase it, declare it as, for example, vector<unique_ptr<T>>.
If you can handle raw pointers, then C++ smart pointers should be easy to understand. Google for C++ unique_pointer tutorial and read through a few of the returned hits. It's fairly straight forward, and in general new C++ development should use the smart pointers instead of using raw (e.g. new/delete).
The problem is I hate complicated syntax. Containers are already complicated syntax for me, combine that with another object (pointer) from a library and it becomes unintelligible mess. I will use a complicated feature when I really need to use it and there is no other way around it. Usually I need to use a feature a couple months before I can move on to something more complicated.
I think you need an "event"; like a timer tick; in order to create a "frame loop" (update and paint).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Windows is event-driven, it doesn't have regular animation frame updates.
You can use SetTimer() to get WM_TIMER messages as often as you want, then invalidate your window to get the WM_PAINT message and repaint.
GDI performance is not very good though, so to reduce flicker you'll probably want to draw to an offscreen compatible device context and then BitBlt() that to the screen. Or use Direct2D - but then you'll have a new problem to think about.
I had in mind switching my videogame from DirectX to GDI. After some attempts at getting a win app working the way I need it and failing I will probably give up on the idea. I should probably keep using DirectX. Thanks for your help Richard and everyone else. Sorry for taking your time, this GDI idea is just a dead end.
modified 10-Aug-22 9:06am.
Last Visit: 31-Dec-99 19:00 Last Update: 1-Dec-23 7:42