|
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.
|
|
|
|
|
Hey. i wanted to ask that i was using the escape sequence \r to write data in files but instead of moving the cursor to the beginning of the current line it moves the cursor to the next line when. However in consloe window it works just fine but in files it functions like \n. As a beginner i am not allowed to use advance stuff like pointers, structure or strings etc etc. So what could be the simplest scenario to move the cursor to the beginning of the current line in a file for the purpose of overwriting the existing txt.
ofstream out("Records.txt" );
out << "This is some text.\rOverwrite";
Output:
This is some text.
Overwrite
Desired Output:
Overwriteome Text.
|
|
|
|
|
I hope this helps. It's from the site that I almost always consult for for C++/STL details:
std::basic_ostream<CharT,Traits>::seekp - cppreference.com[^]
seekp lets you reposition the "cursor" in a read-write file (ofstream) so you can overwrite characters starting at that point. But if your replacement isn't the same size as what you want to overwrite, you'll have to move the rest of the file up (if the replacement is shorter) or down (if the replacement is longer, in which case you have to do this first). It's usually easier to simply create a new file instead manipulating the original. This also preserves the original in case your software misbehaves. 
|
|
|
|
|
It's just not that simple. A file is essentially an array of bytes on disc, which are written sequentially. There is no structure or other information, such as start of line, or record size or anything like that associated with a file(1). When you write a Carriage Return ('\r' hex 0D) to the file, it just appends a CR character at the current location in the file.
Exactly what you need to do, depends on what your exercise is.
If you've got a single string of text as shown above, you'll need to examine each character and decide what to do when you find either a '\n' (start a new line) or a '\r' (move to the beginning of the current line). When you find a newline character, you'll need to write that to the file, and use tellp() to record the current location. When you find a CR ('\r') you'll want to then use seekp() to move to the location returned by the previous tellp(). Don't forget to initialize the variable you use for the result of tellp() when you open the file.
If, on the other hand, you have pairs of input, e.g an initial string ("This is some text") and then the text to overwrite ("Overwrite") then its a bit simpler. You still need to record your current location in the file, but you won't need to examine each character for a CR or NL. You just need to record where you are in the file before you write the line, then use seekp() to move back there when you get the next line of input.
In both cases, you may need to think about what happens when you have multiple lines of input. Are you expected to then move to then end of the current line and continue on, or continue writing at the current file cursor location.
If you know you will only have a single line of text, followed by a single line to overwrite with, things are simpler still. In this case, you just need to write the first line of text, then seekp(0) to the beginning of the file, and write the second line of text.
Note:
(1) This might not be true for all OS's out there. But if you're using Windows, Linux or OS-X, then that is the case.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Saboor Sarfraz wrote: but instead of moving the cursor to the beginning of the current line it moves the cursor to the next line
Nope. A 'file' never ever does that.
Rather you are attempting to display the file using something else.
And that something else, not the file, is doing that.
Saboor Sarfraz wrote: for the purpose of overwriting the existing txt.
Your code is absolutely correct. For what you state the purpose is.
So the problem is, as I stated above.
If you are on a windows machine you can open a Powershell console or a 'cmd' console. They are NOT the same.
Presumably you are using one of those then running your exe.
So try doing it with the other one.
If perhaps you are using an Apple Mac then you are perhaps out of luck since it always interprets the '\r' in the way you are seeing it behave.
modified 21-Nov-23 11:21am.
|
|
|
|
|
what is your preference?
I'm guessing some people prefer &foo[bar] because they may find the intent to be expressed more clearly.
I find (foo + bar) to be more succinct with less steps, and therefore clearer to me.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
You probably have to be a real C nerd to use (foo + bar). I'm not sure that anyone I work with would grok that they're both the same thing. But maybe I work with journeymen, and not craftsmen?
For me, &foo[bar] gives me a brain cramp when I try to parse it. I'd prefer &(foo[bar]) just to make it obvious what is having it's address taken. Just to be pedantic.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Hail to the parenthesis. I always get comments that I use unnecessary parentheses in my code when I add them to pointer arithmetic or compound statements. My response is always along the lines of "yes I know and you were able to tell at a glance the order in which those statements were executed, and how the data was manipulated". Just put the damn () in there to make it easy for someone else to follow what you're trying to do without having to resort to the language specification. It's so much more maintainable for the next person, or yourself in 18 months when you go back to it.
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
&bar[foo]
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I used to write things like 2[array] to wind up certain colleagues.
(Often the ones that insisted on putting the constant on the LHS of a comparison operator.)
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Peter_in_2780 wrote: the ones that insisted on putting the constant on the LHS of a comparison operator.
|
|
|
|
|
No real preference, I use whichever seems (to me) to make most sense at the time.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
