In an IPhone app, I put a breakpoint in appDidFinishLaunching, and when I invoked the program from the compiler using command-Return, the code stopped at my breakpoint.
Then I shut down the program, but not the simulator. When I then invoked the program from the program icon, the code did not stop at my breakpoint. The breakpoint was not within any conditional scope.
Any ideas as to what's going on here?
Thanks,
John Doner
The breakpoint is something that only the debugger is aware of, and only launching your program from Xcode invokes the debugger. "Run and Debug" launches both your application and gdb (the debugger that Xcode uses) and connects them together. When the debugger sees that you have reached the execution point referenced by your breakpoint, it stops execution of the application. The application itself has no idea about the breakpoint.
If you launch your app from the Simulator (or a device) directly, the debugger isn't running, and so your breakpoint has no effect. It isn't part of the compiled app in any way.
Educated guess: breakpoint wasn't active when you invoked your application from the program icon. In order to hit a breakpoint, your app has to be started from Xcode.
Related
Our test automation sometimes makes the simulator crash. In these cases, we often see the dialog below throw on the simulator's next launch. This modal UI dialog breaks automation by preventing application execution until the user chooses an action.
When the iOS Simulator crashes, the application state may be saved in ~/Library/Saved Application State/com.apple.iphonesimulator.savedState. The presence of this folder or values in the data within triggers the modal dialog.
Removing this folder (rm -rf "~/Library/Saved Application State/com.apple.iphonesimulator.savedState") before restarting iOS Simulator will prevent the dialog from appearing. This has been tested with iOS Simulator shipped in Xcode 9.4.1.
If I run a Qt application directly from the Windows command-line (cmd), it immediately returns back to the shell even as the GUI continues running; I assume it creates a second process before the parent exits.
If I run the Qt application indirectly though, from a batch file or Python script, it doesn't behave the same way; it blocks until the application actually exits:
Is this standard Qt behavior? I can't find any mention of it in the documentation or anywhere else. Can it be customized? I would prefer that the application always block when run from the command-line.
This is NORMAL Windows behavior.
In a console console programs are waited on. GUI programs are not. The rules are specified in start /?(mention of new behavior is NT4 to Windows 2000).
So Start /w c:\windows\notepad.
I have configured the WatchKit App to run in my project (WatchOS2).
When I try to run it into the simulator the WatchKit App start perfectly, but each times I'm trying to start the iOS app, this one crash.
The simulator's log show me that :
com.apple.CoreSimulator.SimDevice.5F243C10-E98D-4A20-8950-2742FE6CABD5.launchd_sim[13288] (UIKitApplication:com.MyCompany.MyProject[0x847][13496]): Service exited due to signal: Trace/BPT trap: 5
All of my code in the application delegate is in comment. just enough to start
If I build and use my main app target with the same simulator setting, that works nicely. it just when I build and run the watchkit extension target.
I tried to clean everything (derived data, simulator setting and contents).
I know, it is not the simulator, because with a new project, the issue is not here. it might be something set somewhere ??
but nothing works, any idea ?.
Your application aborted, likely due to a failed assertion. You should look at the crash log (in ~/Library/Logs/DiagnosticReports) for more details.
I have my web app hosted on my local machine, and I try to debug it. I always use Attach to process to do this. BUT. Sometimes when I reach breakpoint and press F10 debugger just continue to run app as I press F5, so I can't go to next step. And sometimes I reattach to process and it runs ok, but not too long, some time pass it again do such strange things.
Can you explain why does it happens?
Regards, Dmitry.
I have a Qt application, running under Xfce and other Linux desktops, which works well, except that the circulating "startup notification" icon is not dismissed when the app starts up, so that it persists for some time after the app main window is showing and complete.
I would assume that either the QApplication would by default dismiss the notification when the main window event loop starts, or I would call some method to do so. I can't find anything relevant in the Qt API documentation, or with google searches on Qt startup notification.
How can one dismiss the startup notification, in a Qt application.
Doesn't adding of
StartupNotify=false
to the .desktop file of your app solve the problem?.In KDE,
X-KDE-StartupNotify=false
works; perhaps XFCE has a similar variable.
The startup notification is sent automatically inside Qt when the first window is first shown (see src/plugins/platforms/xcb/qxcbscreen.cpp), but obviously, due to a bug, it does not work if there are quotes or the escape character (\) in the .desktop file in the path to the program.
In addition, if Terminal=true is presented, the environment variable DESKTOP_STARTUP_ID is deleted by xterm and does not reach your application, so it is better not to enable both Terminal and StartupNotify flags at the same time.
Was tested on MATE.