QString replace %U

[eyllanesc]

@sonichy Read the official docs: https://en.cppreference.com/w/cpp/language/lambda, in special Lambda capture section.

In simple words: with = you are passing values by copy, instead with & you are passing it as a reference. In your initial case "sExec" inside the lambda is a copy of the original. On the other hand, it is not advisable to use & or = (its can cause bugs), it is better to indicate the variables explicitly: [&sExec]

[eyllanesc]

@sonichy I recommend you not to abuse lambdas, a better option is to save the variables in a property to be able to execute it in a slot:

QString sExec= ....
QString sPath = ....

QAction *action = new QAction(...);
action->setProperty("sExec", sExec);
action->setProperty("sPath", sPath);
// TODO

connect(action, &QAction::triggered, this, &Foo::handle_triggered);

void Foo::handle_triggered(){
    if(QAction *action = qobject_cast<QAction *>(sender())){
        QString sExec= action->property("sExec").toString();
        QString sPath = action->property("sPath").toString();
        qDebug() << sExec  << sPath;
    }
}

[sonichy]

@eyllanesc Move replace out of lambda work fine.

QString sExec = readSettings(desktop, "Desktop Entry", "Exec");
sExec.replace(QString("%U"), filepath, Qt::CaseInsensitive);
sExec.replace(QString("%F"), filepath, Qt::CaseInsensitive);
connect(action, &QAction::triggered, [=](){
    QProcess *process = new QProcess;
    process->setWorkingDirectory(sPath);
    qDebug() << sExec;
    process->startDetached(sExec, QStringList());
});

[eyllanesc]

@sonichy Change [=] to [sPath, sExec]

[JonB]

@sonichy
Also you leak the QProcess *process = new QProcess;. Assuming once startDetached() has been called Qt no longer needs the QProcess, try making it a stack instance, you'll have to make sure that works without issue.

[sonichy]

@JonB Yes , the process do not start !
deepin-draw "/home/sonichy/Desktop/KuGou.png"

[JonB]

@sonichy said in QString replace %U:

Yes , the process do not start !

Under what circumstances? The way your code above is/was? After you have changed to make QProcess a stack variable? Both?

Please try to give some clear detail with your posts. You give so little information, we have to keep asking you for more....

[sonichy]

@JonB This is new problem after modify the code, QProcess do not start in lambda !

[jsulm]

@sonichy Would you mind to post the current code, or should we guess what is wrong?

[JonB]

@sonichy said in QString replace %U:

This is new problem after modify the code

Fair enough, I did say you would have see whether it causes problems. This raises a nasty question of what Qt requires the scope/lifetime of the process used in QProcess::startDetached() to be: it cannot be "forever", because we know detached processes survive even exiting the parent program. Maybe it requires it to exist till at least started() signal has been received, I don't know.

Actually, hang on! The overload of startDetached you are using is bool QProcess::startDetached(const QString &program, const QStringList &arguments, const QString &workingDirectory = QString(), qint64 *pid = nullptr). That is static!

Soooo:

• process->setWorkingDirectory(sPath); has no effect (the method signature above takes an optional parameter for the working directory instead).

• Your QProcess *process = new QProcess; is not used.

• You can write QProcess::startDetached(sExec, QStringList()); instead, no QProcess instance needed, and no leaking.

• Given this I find it hard to believe that changing QProcess *process to QProcess process can have any effect....

[sonichy]

@jsulm Click QAction QProcess do not start, copy qDebug() content to terminal can run.

QString sExec = readSettings(desktop, "Desktop Entry", "Exec");
sExec.replace(QString("%U"), filepath, Qt::CaseInsensitive);
sExec.replace(QString("%F"), filepath, Qt::CaseInsensitive);
connect(action, &QAction::triggered, [=](){
       QProcess *process = new QProcess;
       process->setWorkingDirectory(path);
       qDebug() << sExec;
       //process->start(sExec);
       process->setProgram(sExec);
       process->startDetached();
});

[JonB]

@sonichy
Is sExec set to the correct full path to the executable? What do you think your process->setWorkingDirectory(path); achieves? Because if you think it is used to locate the executable to run, it is not.

The bool QProcess::startDetached(qint64 *pid = nullptr) overload you are now using has a return value. Do you think you ought look at that if you are having a problem?

[sonichy]

@JonB Two method:
bool QProcess::startDetached(qint64 *pid = nullptr)

[static] bool QProcess::startDetached(const QString &program, const QStringList &arguments, const QString &workingDirectory = QString(), qint64 *pid = nullptr)

And static do not start either.

QProcess::startDetached(sExec, QStringList(), path);

[jsulm]

@sonichy Please add error handling - QProcess has functionality for that...

[JonB]

@sonichy
Then I do not see that anything you have had so far can have succeeded, but it's most unclear from your comments what that case is.

As per my previous, could you please show what your qDebug() << sExec; is outputting, instead of making us guess?

[sonichy]

@JonB deepin-draw "/home/sonichy/Desktop/KuGou.png"

[jsulm]

@sonichy said in QString replace %U:

deepin-draw

This is a relative path. Pass whole path, so it can actually be found...
And please add error handling...

[JonB]

@sonichy said in QString replace %U:

@JonB deepin-draw "/home/sonichy/Desktop/KuGou.png"

I previously wrote:

Is sExec set to the correct full path to the executable? What do you think your process->setWorkingDirectory(path); achieves? Because if you think it is used to locate the executable to run, it is not.

[jsulm]

@JonB Yes, it is said that people often do not read carefully...

[JonB]

@jsulm
It would be nice if questioners answered questions and acted on recommendations before just reposting that something does not work. Makes we wonder sometimes why we bother. If I ask a question and somebody gives some suggestions I act on those carefully before asking again. But that's another topic... :)