如何获得 Qt窗口部件在主窗口中的位置

pos()函数就能解决问题，能够返回坐标点QPoint

如果有父窗口的话，你先试试mapToParent()，返回在父窗口中的坐标，然后再

mapToGlobal()，你试试，我现在没空弄这个，如果还不行的话，我再想想

linuxqt获取applicationdirpath失败是链接线路错误。解决方法有。

1、在设置启动脚本时，先cd到程序所在目录，然后再执行程序。

2、获取程序绝对路径qApp->applicationFilePath()，然后截取出程序路径（这个方法没有测试）。

当我们使用父对象来创建一个对象的时候 ，父对象会把这个对象添加到自己的子对象列表中。当这个父对象被删除的时候，它会遍历它的子对象类表并且删除每一个子对象，然后子对象们自己再删除它们自己的子对象，这样递归调用直到所有对象都被删除。 这种父子对象机制会在很大程度上简化我们的内存管理工作，减少内存泄露的风险。我们需要显试删除（就是用DELETE删除）的对象是那些使用NEW创建的并且没有父对象的对象(切记是new的才要delete,通过成员函数获得的对象,没有特殊说明的,千万不要随便delete)。如果我们在删除一个对象的父对象之前删除它，QT会自动地从它的父对象的子对象列表中移除它的。 Qt 自动回收不像Java这种，有垃圾回收机制。 Qt 自动回收是靠父子关系。父亲销毁了。他的孩子也销毁。 所以为什么 main函数 里面main widget是分配在栈上的原因。其他new出来的东西都以这个widget作为父亲。 当程序最后结束了，main widgetd栈。。父亲被销毁。。孩子跟着被销毁。。 所以如果你自己new 出来的。没有父亲，不删除就会造成内存泄漏。 ------------------------------ 转载-------------------------------------------- Qt中帮程序员做了一些内存回收的事情，但正因为这些反而让对此不熟悉的人会屡屡犯错。 收录一篇不错的文章：在C++中学习过程中，我们都知道：delete 和 new 必须 配对使用(一一对应)：delete少了，则内存泄露，多了麻烦更大。Qt作为C++的库，显然是不会违背C++的前述原则的。可是:在Qt中，我们很多时候都疯狂地用new，却很少用delete，缺少的 delete 去哪儿了？！ 注：本文暂不涉及智能指针(smart pointer)相关的东西，你可以考虑 Qt 智能指针学习 一文Qt半自动的内存管理在Qt中，以下情况下你new出的对象你可以不用亲自去delete (但你应该清楚delete在何处被Qt调用的，怎么被调用的)： QObject及其派生类的对象，如果其parent非0，那么其parent析构时会析构该对象(本文内容围绕这一点展开) 除此之外，有些类的对象可以接收设置一些特别的标记，比如：QWidget及其派生类的对象，可以设置 Qt::WA_DeleteOnClose 标志位(当close时会析构该对象)QAbstractAnimation派生类的对象，可以设置 QAbstractAnimation::DeleteWhenStoppedQRunnable::setAutoDelete()MediaSource::setAutoDelete()注意：这些用法会有些陷阱，请注意看本文最后的3个小例子。在Qt中，最基础和核心的类是：QObject 。它的魔力很大，本文只关注两点：父子关系deleteLater父子关系 在Qt中，每个 QObject 内部都有一个list，用来保存所有的 children，还有一个指针，保存自己的parent。当它自己析构时，它会将自己从parent的列表中删除，并且析构掉所有的children。注意：在 Qt 中，我们经常会遇到 基类、派生类，或父类、子类。这是对于派生体系来说的，和在C++相关书中看到的完全一样，与这的parent无关父对象、子对象、父子关系。这是Qt中所特有的，也就是这儿的parent所引入的，与类的继承关系无关建立与解除 Q_INVOKABLE QObject::QObject ( QObject parent = 0 ) 创建一个QObject对象时，如果指定了父对象，它就会将自己添加到父对象的 children 列表中 QObject::~QObject () [virtual] 当一个QObject对象析构时，它会将自己从父对象的 children 列表中移除(parent非0的话) void QObject::setParent ( QObject parent ) 通过该函数，将自己从原父对象的children中删除，添加到新parent的children列表中注：这三个函数都是通过一个内部私有函数来实现的，这就是 QObjectPrivate::setParent_helper(QObject o) 获取父、子对象每个QObject只有一个父对象： QObject QObject::parent () const 子对象可以有多个 const QObjectList & QObject::children () const 所以可以根据条件来查找喽： T QObject::findChild ( const QString & name = QString() ) const QList<T> QObject::findChildren ( const QString & name = QString() ) const deleteLaterdeleteLater 包含两层意思了deletelater呵呵，似乎这是废话哈。删除自己在去年春节前的时候吧，有人对 obj-> deleteLater() 会像下面一样调用delete： delete obj; 感到不解。然后我写了这样一个C++例子： class A { public: A(){} void deleteMe() { delete this; } }; int main() { A a = new A; a->deleteMe(); return 0; } 应该不需要解释吧laterQt 是事件驱动的，所以发送一个删除事件到事件系统就可以啦： void QObject::deleteLater() { QCoreApplication::postEvent(this, new QEvent(QEvent::DeferredDelete)); } 事件循环稍后看到该事件就会将其派发会这个widget： bool QObject::event(QEvent e) { switch (e->type()) { case QEvent::DeferredDelete: 一些例子无关痛痒？很简短、很熟悉的一个例子是不？但是 如果你发现对象的析构函数始终不被成功调用，会有什么感觉？ #include <QApplication> #include <QLabel> int main(int argc, char argv[]) { QApplication app(argc, argv); QLabel label = new QLabel("Hello Qt!"); label->show(); return appexec(); } 这是C++ GUI Programming with Qt 4 一书的第一个例子。我们注意到这儿的 label 既没有指定parent，也没有对其调用delete。所以，这儿会造成内存泄露。 书中解释说，对于这种小例子，这点内存泄露不算什么。不清楚官方这个例子的意图是什么，或许是一开始就让大家用指针吧。三种改进方式分配对象到stack而不是heap中 QLabel label("Hello Qt!"); labelshow(); 设置标志位，这样，当我们点击关闭按钮时，close()函数将会调用deleteLater label->setAttribute(Qt::WA_DeleteOnClose); 动手调用delete(不就是少了一个么，我们补上还不行么) int ret = appexec(); delete label; return ret; 单独列一个吧强化一下对前一个例子的了解 #include <QApplication> #include <QLabel> int main(int argc, char argv[]) { QApplication app(argc, argv); QLabel label("Hello Qt!"); labelshow(); labelsetAttribute(Qt::WA_DeleteOnClose); return appexec(); } 运行正常，退出时会崩溃，因为label被close时，将会 delete 这儿label对象，但label对象却不是通过new分配到heap中的。 为了使得用户减少自己显式使用delete，Qt将delete隐藏的比较深。这样一来，不使用new为对象分配空间时，反倒需要多多小心了。隐蔽很深？看个小例子：这个程序退出时会直接崩溃

pro文件里的相对路径不全都是相对于pro文件的,有的是,有的不是。

1、一种情况下/表示pro文件所在的目录；另一种情况下/表示构建生成目录；

11是的情况

SOURCE

FORMS

HEADERS

INCLUDEPATH

DEPENDPATH 等等

这些变量中使用的/指的是pro文件所在的目录

12不是的情况

DESTDIR

OBJECTS_DIR

MOC_DIR

RCC_DIR

UI_DIR

UI_HEADERS_DIR

UI_SOURCES_DIR

win32:CONFIG(debug)

win32:CONFIG(release) 等等

这些变量中使用的/指的是构建生成目录。

2、影子构造说明

如果没有选择影子构造（shadow build），构建生成目录和pro文件所在目录是同一个目录；

如果指定了shadow build，且指定了构建生成目录，那构建目录和pro文件所在目录就不是同一个。

我们默认是会选择shadow build的，所以构建目录≠pro目录。

3、subdirs：多工程多目录的情况

它们的相对路径都是针对你项目下的构建目录+子项目文件夹来的，例如

TEMPLATE = subdirs

SUBDIRS = \

muparser \

librecad

CONFIG += order

那么构建目录，BuildPath假如是F:\CADCAM\QCAD\src\build-LibreCAD-v104-qt4-Desktop_Qt_4_8_7_MSVC2010_32bit-Debug

于是，相对路径和绝对路径的对应关系，分别是：

---举例1---

相对，DESTDIR = bin

绝对，DESTDIR =$${BuildPath}/muparser/bin

绝对，DESTDIR =$${BuildPath}/librecad/bin

---举例2---

相对，DESTDIR = /bin

绝对，$${BuildPath}/bin

4、pro文件打印输出

在pro文件，添加message函数，保存，会在“编译输出”窗口，打印出结果。

message($$PROJECT_ROOT)

message($$PWD)

message($$DESTDIR)

message($$TARGET)

Project MESSAGE: F:/CADCAM/QCAD/src/LibreCAD-v104-qt4/muparser

Project MESSAGE: F:/CADCAM/QCAD/src/LibreCAD-v104-qt4/muparser

Project MESSAGE: /bin/lib

Project MESSAGE: muparserd

5、pro常用的宏定义

TEMPLATE = app

HEADERS：需要包含的头文件的列表。

SOURCES：需要的源文件的列表。

FORMS：需要的ui文件的列表。

LEXSOURCES：所有lex源文件的列表。

YACCSOURCES：所有yacc源文件的列表。

TARGET：可执行应用程序的名称。默认值为项目文件的名字。

DESTDIR：放置可执行程序目标的目录。

OBJECTS_DIR：放置obj中间文件的目录。

MOC_DIR: moc转换文件路径。

RCC_DIR: 资源文件路径。

UI_DIR：ui文件转换的路径。

RESOURCES：需要包含的资源文件。

LIBS：依赖库的路径和名称 -L{xxdirxx} -l{xxnamexx}。

LIBEXT: 产生lib的后缀。

DEFINES：应用程序所需的额外的宏定义列表。

INCLUDEPATH：应用程序所需的额外的包含路径列表。

DEPENDPATH：应用程序所依赖的搜索路径。

VPATH：寻找补充文件的搜索路径。

DEF_FILE：只有Windows需要：应用程序所要连接的def文件。

RC_FILE：只有Windows需要：应用程序的资源文件。

RES_FILE：只有Windows需要：应用程序所要连接的资源文件。

TRANSLATIONS: 多国语言支持文件。

INSTALLS: 要安装的文件。

targetpath: 安装的路径。

以上就是关于如何获得 Qt窗口部件在主窗口中的位置全部的内容，包括:如何获得 Qt窗口部件在主窗口中的位置、linuxqt获取applicationdirpath失败、qt为什么控件的parent已设置为this等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！