why QProcess is not working in MAC os?
- 
@Yash001 is teensy_loader_cli it’s own appbundle, or did you extract the executable out of it? if it‘s an app bundle than your path is wrong. 
 From my experience QProcess doesn‘t execute the bundle, you have to go into the contentse.g 
 teensy_loader_cli.app/Contents/MacOS/teensy_loader_cli
- 
@J.Hilk 
 It is executable file. it is not bundle. I am not able to docd teensy_loader_cli.app/Contents/MacOS
- 
@J.Hilk As per my understanding you are talking about to verify the hexfileFile. Is it there or not. Right? In my case I am selecting the hexFileNamefile manually from GUI.// on click of HexFile button m_connections << QObject::connect(hexFilePbt, &QPushButton::clicked, [=]() { // open the file path which is strore into the SQUID_STAT_PARAMETERS_INI file QSettings settings(SQUID_STAT_PARAMETERS_INI, QSettings::IniFormat); QString dirName = settings.value(FW_HEX_OPEN_PATH, "").toString(); QString filePath = QFileDialog::getOpenFileName(frame, "Select firmware file", dirName, "Intel HEX (*.hex)"); if (filePath.isEmpty()) { return; } settings.setValue(FW_HEX_OPEN_PATH, QFileInfo(filePath).absolutePath()); hexFileLed->setText(filePath); });
- 
Is it any way to determine the what is input string to terminal while using QProcess. When I manually load firmware at that time my input is 
 ./teensy_loader_cli -mmcu=mk20dx256 -wv "/Users/Computer/Desktop/Frimware/3.Squidstat prime firmware Mar 06 2019 (copy) with autoreset.hex"
- 
Hi, Where is that executable located on your machine ? 
- 
@SGaist 
 I am compiling full code in Qt and after that I am adding all dependency ofSquidStat.appwith help of shell script.In shell script, I copy my teensy_loader_cliexecutable file from machine location toSquidStat.app/Contents/MacOS/.If I will call SquidStat.appfrom the Qt run button at that time it is work. But I will go at output dir, and click onSquidStat.app. It is open SquidStat.app software but Updating firmware functionality is not working.In general, executable file is located at location SquidStat.app/Contents/MacOS/
- 
Then you should use QCoreApplication::applicationDirPath to build the path to that executable. 
- 
Then you should use QCoreApplication::applicationDirPath to build the path to that executable. Thank you @SGaist for guidance. application is not able to find the correct location of teensy_loader_cli.Now, I am able get correct functionality with help QCoreApplication::applicationDirPath()Here modify code, and It is work. void UpdateFirmware::UpdateHardware(const QString hexFileName) { QProcess process; process.setReadChannel(QProcess::StandardOutput); process.setReadChannelMode(QProcess::MergedChannels); QStringList arguments; arguments << "-mmcu=mk20dx256" << "-wv" << hexFileName; auto program = QCoreApplication::applicationDirPath() +"/"+QString("teensy_loader_cli"); process.start(program, arguments); process.waitForStarted(1000); process.waitForFinished(); }I have one last question if I will add QThread thread; process.moveToThread(&thread)then Process will be start on separate thread. Right?
- 
If you want UpdateHardware to not block your GUI, then you should rather take advantage of QProcess's asynchronous nature rather than involving threads. What exactly do you want to achieve ? 
- 
If you want UpdateHardware to not block your GUI, then you should rather take advantage of QProcess's asynchronous nature rather than involving threads. What exactly do you want to achieve ? I am trying to update the firmware in hardware with help of teensy_loader_cli.teensy_loader_cliloader need reset signal before updating firmware.case 1: 
 If hardware received reset signal from softwarebeforeQProcess is start then QProcess will not block (teensy_loader_cli will not block the process). It is execute.case 2: 
 If hardware received reset signal from softwareafterQProcess is start then QProcess will block (teensy_loader_cli will block the process) until reset signal is received from software.Reset signal is always call before process is start, But Signal is not received immediately in hardware (code is little messy, I will make it clean) 
  In both case User will not access the other functionality of Software. For blocking functionality I am using one dialog box auto dialog = new QDialog(parent, Qt::SplashScreen). which is give update regrading firmware. Once firmware update is done after that User will get the OK button on dialog box. By click on OK button dialog box will be close and User will get all other access.So I am thinking about to start QProcesson separate thread and give update to GUI regrading firmware update through signals likeemit BootloaderStarted(); emit BootloaderFound();emit BootloaderSetProgress(100);emit BootloaderFinished(true);.
- 
I am trying to update the firmware in hardware with help of teensy_loader_cli.teensy_loader_cliloader need reset signal before updating firmware.case 1: 
 If hardware received reset signal from softwarebeforeQProcess is start then QProcess will not block (teensy_loader_cli will not block the process). It is execute.case 2: 
 If hardware received reset signal from softwareafterQProcess is start then QProcess will block (teensy_loader_cli will block the process) until reset signal is received from software.Reset signal is always call before process is start, But Signal is not received immediately in hardware (code is little messy, I will make it clean) 
  In both case User will not access the other functionality of Software. For blocking functionality I am using one dialog box auto dialog = new QDialog(parent, Qt::SplashScreen). which is give update regrading firmware. Once firmware update is done after that User will get the OK button on dialog box. By click on OK button dialog box will be close and User will get all other access.So I am thinking about to start QProcesson separate thread and give update to GUI regrading firmware update through signals likeemit BootloaderStarted(); emit BootloaderFound();emit BootloaderSetProgress(100);emit BootloaderFinished(true);.@Yash001 
 You should not need to run aQProcessin a separate thread. Instead, do not callwaitForStarted()/waitForFinished()as you show, rather use theQProcess::finishedetc. signals. That is what @SGaist was indicating when he said:take advantage of QProcess's asynchronous nature rather than involving threads 
- 
@Yash001 
 You should not need to run aQProcessin a separate thread. Instead, do not callwaitForStarted()/waitForFinished()as you show, rather use theQProcess::finishedetc. signals. That is what @SGaist was indicating when he said:take advantage of QProcess's asynchronous nature rather than involving threads 
 

