I am working on automating a silverlight application and executing it from jenkins.
Problem:
I am trying to access the folder "SandboxRefresh" present at the bottom of the page in the silverlight application that I am working on.
please find the code below:
SilverlightElement jobfolder2 = extab.GetFirstOrDefaultUIElement(criteria.ByName("SandboxRefresh").AndByClassName("TextBlock"));
Issue Observed:
Executing the above java code in Eclipse resulted in Arithmetic overflow exception as it could not find the element at the bottom of the page.
Please note:
I tried many approaches that worked for me in my machine but it did not work from Jenkins.
ex:
Button bt= new Button();
Screen scr= new Screen();
scr.wheel(bt.WHEEL_DOWN, 2);
The above code worked well to scroll to the bottom of the page but it is not sucessful always. Sometimes the code gets executed by scroll does not happen.
Can anyone help me with an approach to scroll to the desired element in silverlight application when launched the code from jenkins ?
Two quick things, are you waiting for previous code to finish and is the window still in focus?
The problem
I'm not sure how to prevent the debugger bar from appearing/disappearing for certain files. This is an issue that has occurred ever since I started using Xcode 7.
Why it is a problem
Two to three lines are selected in the editor after I tap in it, to switch from/to the assistant editor, as show in the attached image below.
Here is what I know about the issue so far:
I've looked online, and found no information on the issue.
The issue still occurs if I elect to show the Assistant Editor on the right.
Some files do not cause the debugger to show.
Even if I choose to hide the debugger in Behaviors, the issue still occurs.
If I use the activation button to show the debugger, and then try to drag it down, the bar sticks at the bottom, and does not disappear.
For files that don't show the debugger bar, I'm able to drag the debugger down and it hides completely.
This does not happen on Xcode 6.4.
This occurs on both OSX and iOS projects.
Ideal Solution
I'm looking for a way to hide the debugger completely, so that the editor doesn't freak out and select lines when I tap inside it. Any help is greatly appreciated!
After more experimenting in Xcode, I found a fix.
Here are the steps for anyone else who is having the same issue:
Delete the UI Testing target
If you are using UI Testing in the project, then re-create the UI Test target, and files will no longer show the debugger bar.
I went through a lot of permutations before finding this, and nothing else had any effect. However, I'm not sure how long this fix will last, since whatever bug in Xcode caused it to occur in the first place could cause it to surface again. This is especially true for projects that have a large amount of UI Testing.
Edit
The debugger bar does reappear for a new file, even after adding the UI Testing target had been removed and re-created for the project. This happens even if the new file isn't a view object.
The Xcode debugging tools are integrated throughout the Xcode main window but are primarily located in the Debug area, the debug navigator, the breakpoint navigator, and the source editor. The debugging UI is dynamic; it reconfigures as you build and run your app. To customize how Xcode displays portions of the UI, choose Xcode Preferences > Behaviors.
I'm working on an Xcode 7 Playground that has many things running at once. Whenever I make an edit, it refreshes, restarts what was running and runs through the entire code again. That crashes my playground around every 15 minutes. Is there a way to prevent playgrounds from automatically running whenever I make an edit?
In the lower-left part of the Playground there's a right-facing blue arrow, looking like a "play" button.
Do a long click on this button and you will get two options: "Automatically Run" and "Manually Run".
Choose the latter to put the Playground is manual mode and start/stop its execution yourself by clicking on this button.
You can also trigger the code execution by making a custom shortcut to the "Execute Playground" Editor menu command.
Go to Xcode > Preferences... then go to Key Bindings, scroll down to Editor Menu for Playground and add a new shortcut of your choice by double-clicking in the right column in front of the Execute Playground command.
Actually, you CAN map a shortcut for "Execute Playground" to Cmd+R.
Use macOS keyboard shortcuts, instead of Xcode's keybindings.
Go to System Preferences > Keyboard > Shortcuts,
and in App shortcuts, click on +.
Choose Xcode.app, and add a new shortcut for "Execute Playground" (you have to type precisely this!).
Then click on Add.
Now you can use this shortcut in Xcode.
And don't worry for conflicts (at least up to Xcode 9): Execute Playground is not available for standard Xcode projects, and Run is not active for Playgrounds.
With captureScreenWithName I can take a screenshot of the current screen. But are they saved in a directory on the mac somewhere ? Or are they only in the log messages?
If not, is there a way to export them to a directory ?
Use the red button on the top left corner, or run Instruments from command line. You can set the log directory in the bottom left part (when it is set to visible by the corresponding view button right from the timer). If the script is run with the play button at the bottom, the log appears in the Instruments only. (No copy and hard to save screenshots.)
This is more of a general annoyance. Every time after stopping the simulator, Xcode jumps to main.m for some reason. On the left nav, it jumps to the Debug Navigator.
Is there a way to fix this?
It's annoying because I might be testing a certain line of code, and now each time, I need to make a couple of clicks just to go back to that code.
This problem is not new, seems to get worse though. At the time of writing this, I was on the GM seed, but this problem persists in XCode 4.2 final. This was not a problem in previous versions of XCode.
When we start debug from xcode, the debugger sets itself up to monitor signals from OS. When we press stop button in XCode (or hit cmd + R - which first stops existing instance running and then try to start new one, somewhat equalant to we press manually stop first and then run) SIGKILL is sent to the debugger.
Whenever the cause of interruption is from outside the app (in other words all cases where SIGKILL is sent, like stop button press) , debugger jumps to main, since main is the root of the app and the place where your app meets the OS. Debugger has no way to identify why this SIGKILL is issued (pressing stop button in xcode/ press cmd + R/ delete app from multitasking bar etc), but it treats SIGKILL as outside interrupt, and nothing related with your code. So it jumps to main.
If the cause of interruption is from inside the app (like app crash/SIGABRT) debugger handles it and jumps to the place of crash, which we normally see.
I do not consider this as an xcode bug, rather a normal way of handling SIGKILL. But if you want to stay at your code and do not want to jump to main you can do two things
You can do as Gabe suggested. As BBonified said, it is like a band-aide,
but I think it should work (personally I never tried that)
Report a bug/request for a feature here. Let me tell you you
are not the first one to do so. Already a bug has been reported. See
this and this. But I don't have much hope of a positive action from Apple
And I agree with you, it is sometimes annoying. Especially if you have experienced differently in previous XCode versions. But we can only take what they give here.
I guess it's fair to call it a bug, Xcode 3 specifically suppressed this useless artefact.
I've had success (four times and counting) with this one-liner in ~/.gdbinit:
handle SIGKILL nostop noprint nopass
Taken from this gdb manual:
http://www.delorie.com/gnu/docs/gdb/gdb_39.html
Not sure if it applies to lldb as well.
I tried what David suggested but that didn't work for me, so I tried something similar:
Open Preferences, select Behaviors tab.
Select "Run exits unexpectedly" from left column.
Select "Show debugger with current views".
I'm using Xcode version 4.2 build 4D199.
EDIT: That worked for about 15 minutes. Then it reverted to bringing up main.m in the editor again.
I had the same problem and it WAS really annoying, especially when you were in the middle of debugging, stopping/launching the app several times in a row after small modifications.
Everything is solvable through settings in Xcode user preferences:
Just go to "run completes"
There find the "Show" line and click the checkbox
On the same line modify target to go to "Current" in the dropdown menu.
There you go. Xcode will not move your editing view from now on. Enjoy.
PS: Xcode version 4.2 Build 4C199
Go to Preferences -> Behaviors. Choose "Run Completes" in the left hand side. Check the box next to "Show Tab" and enter a tab name. I use "Edit". This way whenever you stop, you will always be back at a tab called Edit.
None of the other solutions listed were suitable for me, so I made a macro (using an external hotkey utility).
(wait 0.1 second after each step)
command-period
command-1
down arrow
up arrow
command-j
enter
Use this key instead of the normal stop, and you end up with your cursor positioned where you left it. Very nice.
Xcode -> Preferences
Under Behaviors
Click on Run Starts
Checkbox for [Show] debugger with [Current Views]
...worked for me.
None of the preference adjustments seem to work for me.
I have been able to track the offending sequence of events. The SIGKILL error message will occur when you run your app and use multiple threads. For instance, when using UIWebView in my app it will abort to main.m. I verified that when UIWebView is not called, XCode can be stopped without the SIGKILL error message returning the user to main.m
It looks like there are at least two threads that get started when initializing a UIWebView.
However, any threads created by you during the running of your app will cause the SIGKILL to improperly notify XCODE to return to the main.
You can see this in the GDB that there is a switch just before SIGKILL:
[Switching to process 24957 thread 0x2103]
[Switching to process 24957 thread 0x7403]
[Switching to process 24957 thread 0x207]
Program ended with exit code: 0
It is definitely still a bug with XCODE that will hopefully be fixed.
For now, if you avoid executing code that launches a separate thread, it will not change the view back to main.m For code that does launch additional threads, I would recommend quitting the simulator to return to edit mode in XCODE.
None of these solutions worked for me and I find the behavior too intrusive to put up with.
I get round it by using the 'Assistant Editor' instead of the editor as my main editing window. You access the Assistant Editor using the tiny little bow tie button at the top right of the single window.
You can set then it to 'Manual'. Click on the button that is the far left crumb of the breadcrumb trail at the top of the Assistant Editor frame and select Manual from the pop-up menu that appears. The Manual setting allows you to select the file you're editing by clicking on the second to last crumb of the breadcrumb trail and selecting the file from the pop-up that appears.
I then just minimize the size of the main editor - or use it as a secondary editing window, useful given that you can't split the editors into multiple frames any more. Far from ideal - but that's XCode 4 for you.
This might not be much. I was able to avoid this problem 99% of the time by waiting for 2 seconds or so after stopping the app, before relaunching it.
UPDATE: After upgrading to the latest Xcode, I am prompted to use LLDB instead of GDB. The problem seems to be gone now.
I was trying to find the offending line when my code was breaking, so what I did was:
Go to where you define your breakpoints (breakpoint navigator, according to the documentation)
Click in the "+" sign in the left bottom corner of the navigation area
Click on Add Exception breakpoint
You click Done
Run your app
Xcode shows you the offending line.