|
I am assuming that your QP pointer is a reference to an object of QProcess Class | Qt Core 6.3.2[^]. As stated in the documentation the start method assumes the device mode as ReadWrite, which if it follows the normal rules, suggests you can write to and read from the started process. But writing will only work if the started process is waiting for input on its stdin stream. As far as I can see your started process is a simple shell pipeline to write some data to stdout and a couple of files. So it is not likely to be waiting for input from an external source.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: Not sure where to start.
The logical place is a tutorial on QProcess. You can only communicate with an independent process in this way, when the input and output streams are connected. The default option to the start method sets QIODeviceBase::OpenMode mode = ReadWrite. Does that mean that you can write to the process or not? Only a QT expert can advise on the answer.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
1. You can concatenate strings. Like this:
#define BT_DATABASE_TEST "../../BT_DATABASE/BluetoothDatabase.txt"
const char *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());
Mircea
|
|
|
|
|
Member 14968771 wrote: 1. Why putting #define in char "string"...
The preprocessor does not see #define directives inside string literals.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
I can`t think of a way to store in an array objects of different type but with same base class so I`m going to use a STL container instead:
class somebaseclass
{
}
class derivedclass: private somebaseclass
{
}
class anotherderivedclass: private somebaseclass
{
}
vector<somebaseclass *> * AllObjects;
derivedclass * Derived1 = new derivedclass[1];
anotherderivedclass * Derived2 = new anotherderivedclass[1];
AllObjects->push_back((somebaseclass)Derived1);
AllObjects->push_back((somebaseclass)Derived2);
Is this how it should be done?
modified 10-Aug-22 9:47am.
|
|
|
|
|
That works but the more modern (and safe) way to do it is to use unique_ptr instead of raw pointers. Something like this:
std::unique_ptr<Base> p1 = make_unique<Derived1>(args1);
std::unique_ptr<Base> p2 = make_unique<Derived2>(args2);
std::vector<std::uniqe_ptr<Base>> container;
container.push_back (p1);
container.push_back (p2);
Mircea
|
|
|
|
|
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>>.
|
|
|
|
|
Quote: because the container allocates the same amount of memory for each entry
that is an interesting fact
modified 10-Aug-22 13:36pm.
|
|
|
|
|
Yes, except for:
1. Why are you using an array size reference in your instantiations? All you should need is:
derivedclass * Derived1 = new derivedclass();
2. Your container is defined to use somebaseclass * types, so your calls to push_back should be:
AllObject->push_back((somebaseclass*)Derived1);
or better still, using proper C++ casts:
AllObject->push_back(reinterpret_cast<somebaseclass*>(Derived1));
|
|
|
|
|
|
You are welcome. I also think @Mircea-Neacsu's advice about unique_ptr is well worth taking.
|
|
|
|
|
pointers from a library, that`s a topic that`s a bit too advanced or complicated for my present day understanding.
|
|
|
|
|
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).
Keep Calm and Carry On
|
|
|
|
|
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.
|
|
|
|
|
It's a lot simpler than classes and inheritance. 
|
|
|
|
|
Richard you really think so?
|
|
|
|
|
Did you notice the icon?
|
|
|
|
|
|
I guess converting the object(pointer) back to it`s original form when time comes to use it somewhere works the same
derivedclass * DerClpointer1 = (derivedclass *)AllObjects->at(0);
Is there a way to check is the conversion is valid? like if an object is of a certain type. For instance how do I convert all objects to their derived state type in a for loop?
for(int i =0; i< AllObjects->size();i++ )
{
}
modified 13-Aug-22 9:27am.
|
|
|
|
|
Calin Cali wrote: guess converting the object(pointer) back to it`s original form when time comes to use it somewhere works the same
Yes it should do, but you need to run some tests to make sure.
|
|
|
|
|
I`m trying to animate things in a basic window. The code I have should get a rectangle (rc) move to the right however that does not happen, it`s all static.
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
static RECT rcBmp;
static HDC hdcCompat;
static HBITMAP hbmp;
static RECT rc;
static RECT rc2;
static RECT rc3;
static RECT rc4;
HBRUSH hbrWhite, hbrGray;
const COLORREF SomeColor = RGB(255,255,255);
const COLORREF SomeColor2 = RGB(0,0,1);
hbrWhite = CreateSolidBrush(SomeColor);
hbrGray = CreateSolidBrush(SomeColor2);
int y = 0;
HDC hdc = (HDC) wParam;
switch (uMsg)
{
case WM_CREATE:
return 0L;
case WM_ERASEBKGND:
GetClientRect(hwnd, &rc);
SetMapMode(hdc, MM_ANISOTROPIC);
SetWindowExtEx(hdc, 100, 100, NULL);
SetViewportExtEx(hdc, rc.right, rc.bottom, NULL);
FillRect(hdc, &rc, hbrWhite);
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return 0;
case WM_PAINT:
{
PAINTSTRUCT ps;
HDC hdc = BeginPaint(hwnd, &ps);
SetRect(&rc,x, 20, 40, 40);
FillRect(hdc, &rc, hbrGray);
SetRect(&rc2,60, 60, 80, 80);
FillRect(hdc, &rc2, hbrGray);
EndPaint(hwnd, &ps);
}
return 0;
}
return DefWindowProc(hwnd, uMsg, wParam, lParam);
}
void GameUpdate()
{
x = x +1;
}
[Edit] it looks like WM_PAINT isn`t triggered every frame, only if I minimize and then maximize the window a change takes place
modified 9-Aug-22 14:35pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
