|
You are welcome.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
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.
|
|
|
|
|
>The only things you should be doing between beginpaint and endpaint
I was thinking to disregard everything that was rendered in one frame, and then render things all over again. Keeping track of pieces 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 2-Dec-23 3:45am.
|
|
|
|
|
You are welcome to do that, but it may affect the performance in certain scenarios.
|
|
|
|
|
|
It all seems a bit odd until you understand that everything in Windows is message driven. For each message type that you handle you need an event handler, for all the others just let Windows deal with them.
|
|
|
|
|
I might do some searching through CP. There are some excellent articles covering the madness of Windows drawing, GDI, etc. DCs, their variations and purposes are also covered pretty well.
Just keep in mind the point behind InvalidateRectangle - GDI is somewhat smart. It will limit it's drawing to regions it knows it needs to re-draw which is why you need an InvalidateRectangle call.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Addendum
Since I cannot figure out ( user fault ) how to post pictures here ....
If it is OK to post a link to another forum ?
another "include " issue - how to print the path | Qt Forum[^]
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
#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 ?
|
|
|
|
|
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.
|
|
|
|
|
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 )
|
|
|
|
|
The project does not "use the include files". They are putely source code definitions and declarations used by the compiler to build the object file. What hapens in reality is the the compiler reads every file that is (directly or indirectly) named in an #include statement, and builds a new source file that comprises your source code plus all the included text. It then processes that source to create the object file. Each separate object file will then be used as input to the linker, along with all referenced libraries to build the final executable.
|
|
|
|
|
|
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;
};
<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__);
qDebug() << text;
ui->textEdit->append(text);
#endif
text = " Constructor...";
ui->textEdit->append(" Constructor..."); }
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.
|
|
|
|
|
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.
|
|
|
|
|
Many thanks, my own fault...missed ui header.
I always forget to add the "ui...." header created by QT...
The "forward note" error was not too helpful either.
#include "ui_mainwindow_bluewtoothctl_dialog.h"
|
|
|
|
|
Glad I was able to help!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
Recently I have converted the application from 32bit to 64bit in VS 2019,all sources are saying the application is of 64bit I'm unable to launch the application, and I am not able to debug the application because the application need to be attach to process to debug, when searched in the event viewer, I am encountering BEX64 error , and have made sure that all the dependent DLL's are of 64bit, Can anyone please help me to resolve this issue.
I am able to open the application from visual Studio 2019, but not able to launch from exe.
|
|
|
|
|
You need to investigate further and provide more information. It is impossible to guess what may be wrong.
|
|
|
|
|
Member 16142254 wrote: all sources are saying the application is of 64bit
That is ambiguous.
Your code is probably linking to some other dlls. I would first start with checking those.
Member 16142254 wrote: launch the application
You will have a main method. You can start by commenting ALL of the code in that module out except for the main() method call. So everything in the main() method is commented out also.
If that runs then you can start uncommenting.
If it doesn't run then it indicates that the build of that module itself is a problem.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
