C / C++ / MFC

14mins ago

I need help with QT C++ code - adding another primary menu to mdiArea object main menu - using C++ code , not using QTDesigner.

This is desired menu / submenu structure

mdiArea "bar" main menu
primary menu
submenu
submenu

primary menu
submenu
submenu

I do not understand HOW to add second (and more) primary menus .
The attached code is creating another main menu in menu bar. Not desired.

C++

 // add systemctl as submenu to primary menu systemctl
 QMenu *BT_Menu_SubMenu_System = menuBar()->addMenu(tr("&systemctl  ( command )... "))
                              ->addMenu("&systemctl  submenu ... ");


 // add bluetoothctl as submenu to primary menu systemctl

this adds another menu to mdiArea bar

 menuBar()->addMenu(tr("&systemctl  ( command )... "))
     ->addMenu("&bluetoothctl  submenu ... ");

Any help with code and explanation why will be greatly appreciated
Thanks
PS I did post this in another forum and having no luck - no response.

Invalidate rectangle

Calin Negru6hrs 7mins ago

Calin Negru

6hrs 7mins ago

I’m trying to display an animated bitmap in a win32 application with GDIplus. Last time when I talked about this here I was told I should invalidate a rectangle to force the App to refresh/draw another frame. I’m trying to understand the theory for now. I will come up with code in a day or two if necessary. My question is do you create and invalidate between beginpaint and endpaint a rectangle that has no particular purpose or does it have to be a rectangle that actually does something.
I’m having a difficult time understanding the connection between a rectangle and the rendering process of a win32 api window

CPallini5hrs 47mins ago

CPallini

5hrs 47mins ago

Roughly speaking, the invalidated rectagle will be redrawn in the next WM_PAINT call (other parts of the client area are not redrawn). So, if you need to update a portion of the client area then invalidate the corresponding rectangle and then call UpdateWindow().
In simple scenarios you can invalidate the entire client area and then call UpdateWindow().
See, for instance: Invalidating the Client Area - Win32 apps | Microsoft Learn[^].

"In testa che avete, Signor di Ceprano?"
-- Rigoletto

Calin Negru5hrs 8mins ago

Calin Negru

5hrs 8mins ago

Basically I need a rectangle taking the whole window for my game, I think I understand, I’ll post a followup if I’ll run into trouble setting things. Thank you.

CPallini4hrs 52mins ago

CPallini

4hrs 52mins ago

You are welcome.

"In testa che avete, Signor di Ceprano?"
-- Rigoletto

Richard MacCutchan4hrs 35mins ago

4hrs 35mins ago

The only things you should be doing between BeginPaint and EndPaint is redrawing/rewriting the parts of the client window that may have changed. Outside of the WM_PAINT handler, you decide which part (or all) of the window needs to be repainted. You then set those values into a call to InvalidateRect, which will post a WM_PAINT message to your message queue.

Calin Negru2hrs 53mins ago

Calin Negru

2hrs 53mins ago

>The only things you should be doing between beginpaint and endpaint

I was thinking to flush it all, and redraw everything from scratch every frame. Keeping track of things that visually change in my game ( if that’s what you mean) seems like a burden at this point.
So far I’m only looking for a way to trigger a new paint event

modified 1hr ago.

Richard MacCutchan2hrs 20mins ago

another "include" question...

2hrs 20mins ago

You are welcome to do that, but it may affect the performance in certain scenarios.

Salvatore Terress28-Nov-23 5:28

28-Nov-23 5:28

Hope nobody gets uptight with basic question...

Here is how QT .pro "links" with BT_Utility_Library,
now I need to add "include" CORRECT BT_Utility_Library header.

I will freely admit that I have newer mastered "../.." - whatever it is called -
and intelisense is not helping.

Can you help me ?
Thanks

unix:!macx: LIBS += -L$$OUT_PWD/../../../CCC_SOURCE/BT_Utility_Library/ -lBT_Utility_Library

INCLUDEPATH += $$PWD/../../../CCC_SOURCE/BT_Utility_Library
DEPENDPATH += $$PWD/../../../CCC_SOURCE/BT_Utility_Library

MarkTJohnson28-Nov-23 5:32

MarkTJohnson

28-Nov-23 5:32

single dot is the current directory, double dots are one level UP (closer to the root directory) from where you are. So backtrack to the root and then go down the correct path.

I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.

jschell28-Nov-23 5:58

jschell

28-Nov-23 5:58

Adding to what the other reply said.

Salvatore Terress wrote:
-L$$OUT_PWD/../../../CCC_SOURCE/BT_Utility_Library/ -lBT_Utility_Library

In that '$OUT_PWD' is a directory.

Then each '..' moves UP the directory tree. So it moves up three levels.
Then it expects to find CCC_SOURCE

Whether it does so depends on whether '$OUT_PWD' is set to a correct value.

This can be further complicated by whether '$OUT_PWD' is a full directory or a partial directory. So if it is something like './MyStuff/Programs' (where the dot is important) then it is a partial directory. But if there is no dot then it is a full directory that must exist at the root of your file system.

Richard MacCutchan28-Nov-23 6:16

28-Nov-23 6:16

Each double dot means move up to the parent of the current directory. The variable $$PWD will refer to the current directory, when this statement is processed. So assuming a project tree like:

home
  -- terress
    -- dev
      -- myproject
        -- btsamples
          -- test -> assume this is $PWD

then the above statement will expect to find BT_Utility_Library in a directory named CCC_SOURCE in /home/terress/dev.

k505428-Nov-23 7:11

k5054

28-Nov-23 7:11

To add to what the others have said, the same convention is used in Windows as well. At the command line, if you type cd ..\.. you move up 2 folders from the current one (assuming that you're at least 2 levels deep).

"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown

Salvatore Terress28-Nov-23 8:38

28-Nov-23 8:38

Update / followup

This is how .pro (QT project file) is "linked" to libraries. OK

unix:!macx: LIBS += -L$$OUT_PWD/../BT_LIBRARY/CCC_SOURCE/BT_Utility_Library/ -lBT_Utility_Library

INCLUDEPATH += $$PWD/../BT_LIBRARY/CCC_SOURCE/BT_Utility_Library
DEPENDPATH += $$PWD/../BT_LIBRARY/CCC_SOURCE/BT_Utility_Library

unix:!macx: LIBS += -L$$OUT_PWD/../BT_LIBRARY/CCC_SOURCE/TEST_DIALOG/untitled_TEST/ -luntitled_TEST

INCLUDEPATH += $$PWD/../BT_LIBRARY/CCC_SOURCE/TEST_DIALOG/untitled_TEST
DEPENDPATH += $$PWD/../BT_LIBRARY/CCC_SOURCE/TEST_DIALOG/untitled_TEST

These are header files

C++

#include "bt_utility_library.h"
#include "BT_Utility_Library_global.h"

#include "../untitled_TEST/mainwindow_test_dialog.h"

the
mainwindow_test_dialog.h

is liked "one up " and then use "subproject"...level

So my question remains

are linking library project "path"
NOT
related to linking "include " path ?

Richard MacCutchan28-Nov-23 22:57

28-Nov-23 22:57

Salvatore Terress wrote:
are linking library project "path"
NOT
related to linking "include " path ?

They are linked in the sense that both are required to build your application, but in another sense they are totally separate. Header files are used by the compiler to generate correct calling code to external class methods and functions, but with the actual addresses of the function incomplete. Library files are in two parts. The first are required by the linker phase to provide the actual addresses of the external methods and functions. The linker calculates the real addresses and plugs them into your code so all the calls actually work. The second part, the code in the library files that does the work, can be in one of two places. Firstly it may be in a simple archive (.a type) that is built into your application by the linker, and loaded with it when it runs. Secondly, it can be in a shared object file (.so type) which is loaded into memory when required by the operating system.

So it does not matter where these files are when you are building your project, only that the compiler and linker can find them when required.

Salvatore Terress6mins ago

6mins ago

Nice explanation, thanks.
I need to come up with "flow chart" how QT project actually use the "include this " -
the lowest level would be

C code ... ( what to call this - it will be part or QR .pro (project) file / folder )

header ( declaration )
code (definition )

error: member access into incomplete type

Maximilien29-Nov-23 3:33

Maximilien

29-Nov-23 3:33

Salvatore Terress wrote:
I will freely admit that I have newer mastered "../.." - whatever it is called -

It's called a relative path.

it's used instead of using an absolute path; makes the code more portable by not fixing a hard-coded absolute path.

What are the differences between absolute and relative paths? | Enable Sysadmin

CI/CD = Continuous Impediment/Continuous Despair

Salvatore Terress27-Nov-23 7:07

Re: error: member access into incomplete type

27-Nov-23 7:07

could somebody PLEASE explain to me and help me to understand the error.

I can build and show the dialog object

// build basic dialoog
MainWindow_Bluewtoothctl_Dialog *MWBD = new MainWindow_Bluewtoothctl_Dialog();
MWBD->show();

however I cannot access its "ui" and getting the "incomplete error ".

I build a local function and then have access to "ui".

QT_BEGIN_NAMESPACE
namespace Ui { class MainWindow_Bluewtoothctl_Dialog; }
QT_END_NAMESPACE

class MainWindow_Bluewtoothctl_Dialog : public QDialog
{
Q_OBJECT

public:
MainWindow_Bluewtoothctl_Dialog(QWidget *parent = nullptr);
~MainWindow_Bluewtoothctl_Dialog();
// adds

BT_Utility_Library *BTUL;

QString text;
QString EditText(QString );
QString EditText(QString, QWidget*);
QString EditText(QString, QWidget*, QWidget*);
QString Command(QString );
private:
public:
Ui::MainWindow_Bluewtoothctl_Dialog *ui;
};

C++

<pre lang="C++">MainWindow_Bluewtoothctl_Dialog::MainWindow_Bluewtoothctl_Dialog(QWidget *parent)
    : QDialog(parent)
    , ui(new Ui::MainWindow_Bluewtoothctl_Dialog)
{
    ui->setupUi(this);
#ifdef TRACE
    text = " TASK MainWindow_Bluewtoothctl_Dialog ";
    text += " ";
    text += Q_FUNC_INFO;
    text += "  @ line  ";
    text += QString::number(__LINE__);
    //text += "  TASK    index ";
    //text += QString::number(index);
    qDebug() << text;
    ui->textEdit->append(text);
#endif
    text = " Constructor...";
    ui->textEdit->append(" Constructor..."); // OK here 
}

MainWindow_Bluewtoothctl_Dialog::~MainWindow_Bluewtoothctl_Dialog()
{
    delete ui;
}

// build basic dialoog
MainWindow_Bluewtoothctl_Dialog *MWBD = new MainWindow_Bluewtoothctl_Dialog();
MWBD->show();

// add function to bypass "INCOMPLETE WHATEVER
text = " add function to bypass INCOMPLETE WHATEVER ";
MWBD->EditText(text);

// TEST ui
MWBD->ui->textEdit->append(text);

this fails with "incomplete error " why ?

Here is full error:

mainwindow.cpp:595:17: error: member access into incomplete type 'Ui::MainWindow_Bluewtoothctl_Dialog'
        MWBD->ui->textEdit->append(text);
                ^
/mnt/07b7c3f8-0efb-45ab-8df8-2a468771de1f/BT_NOV26_BACKUP/BT_NOV26/FT857_CAT_Bluetooth/BluetoothctldIALOG_Object/Bluetoothctl_Dialog/mainwindow_bluewtoothctl_dialog.h:16:22: note: forward declaration of 'Ui::MainWindow_Bluewtoothctl_Dialog'
namespace Ui { class MainWindow_Bluewtoothctl_Dialog; }
                     ^

Thanks for your help.

Richard Andrew x6427-Nov-23 11:17

Richard Andrew x64

27-Nov-23 11:17

I think it's telling you that the type represented by ui has not been completely declared.

Make sure you are #including the header files for all the types you are using.

The difficult we do right away...
...the impossible takes slightly longer.

SOLVED Re: error: member access into incomplete type

Salvatore Terress27-Nov-23 11:44