QString path = QDir::homePath(); // <-- "path" is always ""
Is this a new bug in 4.7.4? use to work well in 4.7.3
I’m on OSX Lion (4.7.3 worked on Lion well).
The “Clear System Environment” probably cleared the HOME environment variable too.
Basically, QDir::homePath() returns QFile::decodeName(QByteArray(::getenv("HOME"))) almost unchecked. And that's an empty string, if there is no HOME variable.
Hmmm It seems the problem is resolved if I don’t use the “Clear System Environment”. I unchecked it, then re-built and it worked fine. could it be the “SHELL” definitions? I can’t think of anything other than that that’s remotely related to this. I guess something caused Qt to have QT_NO_FSFILEENGINE defined and thus to return an empty string:
// from Qt source file: QDir.cpp
QString QDirPrivate()
{
#ifdef QT_NO_FSFILEENGINE
return QString();
#else
return cleanPath(QFSFileEngine::homePath());
#endif
}
Related
We have a bpl that has some resource (.rc) files which has strings in it. It is defined via STRINGTABLE and loaded via a LoadStr() call. The project was in version 10.1 Berlin. We upgraded to the latest 11.1 Alexandria and now the call returns NULL. So to test I added the line at the main
extern "C" int _libmain(unsigned long reason)
{
String str = LoadStr(231); **// Works**
return 1;
}
but the existing code below does not work.
**.h**
PACKAGE String __fastcall GetValueSetDesc(int ACount);
**.cpp**
String __fastcall GetValueSetDesc(int ACount)
{
String ValueDesc = LoadStr(ACount); **// Does not work, retuns NULL**
return ValueDesc;
}
I tried creating the project from scratch (and adding files to it). Any one has experienced this issue or know what to try?
The problem was with DevExpress components. The call was from a DevExpress change event. A call from a non DevExpress component worked fine. The way I solved this is to re-create the cbproj from scratch and add the files, settings etc (in the exe, the bpl seems fine). Man, DevExpress gave me a lot of grief this time around when we upgraded!
This is really stumping me, it was working before hand but now it always returns null (therefore not populating).
The code at question is:
imgObjPth = QFileDialog::getOpenFileName(this, tr("Select Image"), PATH);
imgObjPth is a QString variable, and QFileDialog returns QString. So how come it's returning null? As I said, this line of code has worked in the past, so I just don't know why today it decides not to work.
Edit:
Cancel is not being pressed.
I've moved my development from Mac to Ubuntu, but the same issue occurs on my Mac too.
QT 5.4.2 is used
I am building up a QListWidget, browsing through a directory so that every ".png" gets listed with a preview icon.
The core of my populating loop looks like this:
new QListWidgetItem( QIcon(act_fullname), act_filename);
Right after the whole list is ready, the app crashes.
The error is many times repeated and says this:
On Mac OS X, you might be loading two sets of Qt binaries into the
same process. Check that all plugins are compiled against the right Qt
binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of
binaries are being loaded. QObject::moveToThread: Current thread
(0x103339cb0) is not the object's thread (0x10a848670). Cannot move to
target thread (0x103339cb0)
On Mac OS X, you might be loading two sets of Qt binaries into the
same process. Check that all plugins are compiled against the right Qt
binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of
binaries are being loaded.
Do you have any ideas?
Thanks for your help!
EDIT:
If I skip the icons there is no problem. I have also tried going
QListWidgetItem *item = new QListWidgetItem(act_filename);
ui->listWidget->addItem(item);
item->setIcon(QIcon(act_fullname));
and got no difference.
EDIT 2:
I do not call QObject::moveToThread(QThread*) I don't even use threads (deliberately at least).
Also, the errors appear to come after the loop. I have cout-ed every iteration and the end of the loop and right after my "end loop cout msg" I see that
objc[56963]: Class QCocoaColorPanelDelegate is implemented in both
/Users/Barnabas/QtSDK/Desktop/Qt/4.8.1/gcc/lib/QtGui.framework/Versions/4/QtGui
and
/Users/Barnabas/Programming/Qt/demo_OpenCV-build-desktop-Desktop_Qt_4_8_1_for_GCC__Qt_SDK__Release/demo_OpenCV.app/Contents/MacOS/../Frameworks/QtGui.framework/Versions/4/QtGui.
One of the two will be used. Which one is undefined.
Here, too, I do not use QCocoaColorPanelDelegate. I don't even know what it is ... :(
But here is my more detailed code:
boost::filesystem::path p("/path/to/dir");
if(boost::filesystem::is_directory(p))
{
for(boost::filesystem::directory_iterator it(p); it!=boost::filesystem::directory_iterator(); ++it)
{
if(it->path().extension().string()==".png")
{
std::cout<< it->path() <<std::endl;
QString item_name( it->path.stem().c_str() );
QString screen_file( it->path.c_str() );
QListWidgetItem *item = new QListWidgetItem(item_name);
QIcon *icon = new QIcon(screen_file);
item->setIcon(*icon); // if I comment this one out, everything is fine.
ui->imageList->addItem(item);
}
}
}
I have also tested it with a single .png and the image was displayed properly in the list but crash followed with the very same messages.
I have finally found the solution: manually removed the Debug and the Release directories.
For those whose similar problem is not solved by this see: this link.
I have the following issue: I create a QFileSystemWatcher and it runs and works nicely on Linux, but no way on Windows 7. Can you spot anything in the code that might make it not to work?
Thx.
Here is the code to initialize it:
mConfigChangeWatcher = new QFileSystemWatcher();
mConfigChangeWatcher->addPath(config_file_name);
QObject::connect(mConfigChangeWatcher,
SIGNAL(fileChanged(QString)),
this,
SLOT(configFileChanged(QString)));
and this is supposed to be the slot getting the work done:
void MyClass::configFileChanged(const QString &file)
{
qDebug() << "Changed: " << file ;
}
When you check if the file is added to the watcher using QFileSystemWatcher::files() method after the first modification in the file do you get the correct list?
I was with the issue that some applications, when modifing a file, delete the old file from the system and write it again.
Note that QFileSystemWatcher stops monitoring files once they have been renamed or removed from disk, and directories once they have been removed from disk.
I was using QFileSystemWatcher to watch an image file edited by Photoshop. Somehow the file gets removed from the list of files being watched.
I had the same problem and solved it very fast.
Within the slot that manages the fileChanged signal I noted the path disappears from files(). I simply make a check and re-add it if necessary
if (! watcher_.files().contains(path))
{
watcher_.addPath(path);
}
I hope this helps
Fabio
In AS3 you can pass a constant to the compiler
-define+=CONFIG::DEBUG,true
And use it for conditional compilation like so:
CONFIG::DEBUG {
trace("This only gets compiled when debug is true.");
}
I'm looking for something like #ifndef so I can negate the value of debug and use it to conditionally add release code. The only solution I've found so far was in the conditional compilation documentation at adobe and since my debug and release configurations are mutually exclusive I don't like the idea of having both DEBUG and RELEASE constants.
Also, this format works, but I'm assuming that it's running the check at runtime which is not what I want:
if (CONFIG::DEBUG) {
//debug stuff
}
else {
//release stuff
}
I also considered doing something like this but it's still not the elegant solution I was hoping for:
-define+=CONFIG::DEBUG,true -define+=CONFIG::RELEASE,!CONFIG::DEBUG
Thanks in advance :)
This works fine and will strip out code that won't run:
if (CONFIG::DEBUG) {
//debug stuff
}
else {
//release stuff
}
BUT this will be evaluated at runtime:
if (!CONFIG::DEBUG) {
//release stuff
}
else {
//debug stuff
}
mxmlc apparently can only evaluate a literal Boolean, and not any kind of expression, including a simple not.
Use the if / else construct : the dead code will be removed by the compiler and it will not be tested at runtime. You will have only one version of your code in your swf.
If you are not sure use a decompiler or a dump tool to see what really happens.
http://apparat.googlecode.com/files/dump.zip
http://www.swftools.org/
...
While Patrick's answer fulfills the question's criteria, it does not cover all use cases. If you are in an area of code that allows you to use an if/else statement then this is a good answer. But if you are in a place where you cannot then you will need a better solution. For example, you may want to do something like this to declare a constant in a class:
private var server:String = "http://localhost/mystagingenvironment";
or for a live release:
private var server:String = "http://productionserver.com";
(this is an example and I'm not advocating this as production code).
I use xml configs and use the loadConfig+="myconfig.xml" to do my configuration instead of passing large numbers of command line params. So in the <compiler> section of your xml config:
<define>
<name>CONFIG::debug</name>
<value>false</value>
</define>
<define>
<name>CONFIG::release</name>
<value>!CONFIG::debug</value>
</define>
This works well for all use cases:
CONFIG::debug
{
private var server:String = "http://localhost/mystagingenvironment";
}
CONFIG::release
{
private var server:String = "http://productionserver.com";
}
This has the additional benefit of working consistently across applications. It also does not rely on the 'optimize' flag being true, like Patrick's answer (although I think we can assume that 99.999999% of all swfs have optimize=true, I only set it to false when the optimizer breaks my AS3).
It does have the drawback that it doesn't compile all code paths, just the ones that are included. So if you're not using a build server to create release builds and tell you when things break, be prepared for surprise errors when you do your release build ("But it compiled in debug! Crap, I need this to launch now!").
Just my two cents about Chris Hill's answer (which is the solution I also use regularly): it seems that using the loadConfig+="myconfig.xml" option makes the compiler searching for the myconfig.xml file in the Flex SDK directory whereas the -load-config+=myconfig.xml option makes it searching for the myconfig.xml file in the project's directory, which is the behavior I strongly prefer as you can then easily distribute this file with your project sources...