I'm using MPLABX IPE 1.95 on linux. For some reason the programmers decided to make the main window non-resizeable.
So it's impossible to see the memory view properly. If the memory view isn't open, I can't even see the bottom of the output window.
Is there any trick to make the window the right size?
Otherwise, can someone perhaps give the developers monitors that are larger than 640x480?
I hope the status isn't important
I experienced the same problem. A workaround is to right-click in the Output or Memory View window and select Undock from the context menu. From my experience, the Status is not important. It shows the progress of the configuration changes when in Advanced Mode.
Related
When an app is running in a third of an iPad screen, there is a small drag handle at the top of its window. In iOS 10, dragging on that handle lets you switch what app is open there. In iOS 11, you can use it to change the app from taking up a third of the screen to floating over the rest of the screen.
My question: how do I know when this handle is present, or at least know that there's something taking up that space? I need to lay out my UI content around it without conflicting with it. It doesn't appear to work with iOS 11's Safe Area APIs.
See here for a sample project trying to put a label at the top of a window without overlaying the drag handle. Run it in a third of an iPad screen.
Start by duplicating the radar. This is definitely something that should be handled by the safe area magic.
The issue here is that the handle is rendered by SpringBoard, so you can only apply tricks to guess whether it is currently visible. You can determine whether the window is at the right size and whether it is at the correct location on screen, and then add some extra safe area insets. This is normally ill-advised for several reasons, such as not knowing all cases where the handle appears, having to take into account left-to-right systems, etc., but in this case, the problem seems so egregious, I'm not sure I'd recommend leaving as is.
Edit
One more option is to see if UIWindow.safeAreaInsets returns a correct value. UINavigationController is able to deduce the safe area correctly, so it is hiding there somewhere.
I want to be explicit that I am not referring to the quick look feature built into XCode:
My issue with this approach is that I need to review about 50 images per run, and the action of clicking through each time is going to give me carpal tunnel at this point.
I do not think there is something officially baked into XCode that will provide what I want, so my hope is that there is a third party tool that can handle this. Preferably, something that may place it in the variable in the debug console so that I may view the image.
Not exactly what I was looking for, but something that XCode does provide is fairly close to what I want.
When a breakpoint is hit, select the variable in the console
Click on the eye icon seen below
The image window seen here will appear with an anchor to the variable
This is with XCode 8.
The benefit of this approach is that it saves me from having to track to the variable in code, hover over it, and then move the cursor just so such that the window does not close before I can click on the inspection icon.
So, I haven't been able to figure this out yet, because when I pause execution... Xcode doesn't really show what's going on:
This freeze happens when I scroll a very long UITableView around in the center of its scrollable area constantly, so that it's constantly reusing cells. I think that perhaps there is something not being retained for a dispatch block that might happen there, but I'm not yet sure since no data is displayed using the standard debugger and its a fairly complex view. (reference: https://stackoverflow.com/a/23501382/963901 )
I'm going to attempt some manual diagnosis here, but is there any other way of approaching this with Instruments or something, perhaps?
To investigate this sort of problem I'd suggest the following:
Disable the setting in Xcode's debug navigator pane that hides intermediate stack frames from you. It's one of the buttons at the bottom right of the pane that shows the stack trace.
Look at the newly-revealed portion of the backtrace to see what code is blocking on the semaphore.
Look at the other threads in your program to see which appear to be doing work related to the code discovered in step 2.
The current version of my app, running on Android 4.0.4 on an ancient Galaxy Tab has an odd issue when it's running in landscape orientation. I have the CPU usage developer option turned on, and I can see that a single core is being fully utilised when the app is sitting idle, even at it's login screen.
I'm using jQM 1.4.4, WL 6.2.0.01-20141027-1531.
When it's clear that CPU usage idling high for my app, I change to portrait and the CPU usage completely goes away, and the app is responsive again.
Step (CPU usage after a few seconds)
Login Screen (high)
Tap in text field, keyboard appears (none)
Hide keyboard (none)
Switch to portrait (none)
Switch to landscape (high)
On top of that, when I switch from Portrait to Landscape, the view doesn't redraw under the new aspect. The view is constrained to an area (square-ish) as wide as the screen is tall (or wide in portrait). The fixed header disappears but the view is interactive. To fix this, you can tap into a text field which brings up a keyboard. The view updates to fill the screen, and CPU usage is down again.
Other thing to note is that this issue did not exist in the previous version of the app. I've reviewed all changes between the versions and nothing stands out to me that should cause an issue like this.
Suspects:
the page or pagecontainer, popup or fixed header is doing a lot of work that usually should only occur on window resize (no direct changes to the logic here);
the CSS, in particular some responsive queries (there's a breakpoint between landscape and portrait) (no responsive CSS changes)
Other info:
Not a single problem was reported with Samsung Tab 3 running 4.2.2 or a Nexus 7 on 4.4.4 with this version
Tried using weinre to profile this issue except it loses connection soon after opening the app (again, previous version it was fine)
Minor differences between two identical target devices (Samsung Galaxy Tab 10.1): one tablet always performs fares better
I'm about to roll back to the older codebase and iteratively add code back in to see where the issue comes in.
Thanks for reading. Any pointers or suggestions are obviously greatly appreciated.
Update 1
I profiled from within Eclipse (turns out the Timeline inspector tab is pretty useless in weinre).
https://www.dropbox.com/s/ke0a9c2z9krhucu/highThreadUsage.PNG
Doesn't mean much to me. I suspect all that profile really says is 'the webview is doing all the work'.
I've created a new Hybrid app in the same project, and copied everything into it. I'm going to start stripping out chunks of code/functionality to see resolves the issues first.
This is a preliminary answer. I'm still doing the legwork and trying to see what exactly is happening in this situation.
The culprit appears to be a specific panel. A panel I haven't even touched in weeks. The only thing that I can even think of is that I changed the padding-top on .ui-tabs-panel from 1em to 0.5em...
There are two panels that are immediately init'd on app load. The one that slides from the right is the culprit: if I remove the init call and the HTML for it, the app is fine. Putting it all back, and prematurely opening the panel via weinre resolves the issue. Next step, is changing that padding-top back to 1em.
Problem doesn't show up. I repeat this several times over: make a build with 0.5em padding, and another with 1em. Repeat. The 0.5em build always has the issue, the other does not.
I'm going to chalk this up to the most coincidental (read: unlucky) bug, ever.
I'm planning on hardcoding the panel contents to display:none and showing them when the panel is opened. See if that works.
I just started working on a relatively complex project, and have discovered a bug. When the user logs out, the view controllers are still allocated behind the login view controller. They continue responding to rotation events, etc. I have set the controller to nil upon logout, but it's still responding, which indicates that some other object still has a pointer to it. (This project has ARC enabled.)
Pre-ARC I could likely solve this by overriding retain:
- (id) retain
{
// Break here to see who is retaining me.
return [super retain];
}
How can I use the Xcode debugging tools to select an object and list all the other objects that point to it? Is there a better approach than simply hunting through all the code?
As of Xcode 8 you can use the Debug Memory Graph:
Run your app and look at the navigator at the bottom of the screen. You should see a set of three connected circles:
Navigate to wherever so that your object is allocated in memory and then tap on this icon. It should pause your app and a graph should pop up on your Xcode screen. Now, on the left side of the screen you can see a list of objects. Find the object you want to see all the pointers to and click on it. Now they should be visible in the graph. You can expand these branches by tapping on the two arrows on the nodes at the left end of the branch. The graph should look something like this:
This saved me literally days of work. It's an extremely useful tool. I hope it helps someone else too.
The Instruments Heapshot Analysis tool was the best thing I could find for this purpose. This article provides a more complete tutorial, but the basic steps are:
Select Product -> Profile. Choose the Allocations Instrument.
On the left, press the Mark Heap button before/after significant events. In my case, this was before login, after login, and after logout.
Search through the Heapshot for the class you're looking for.
Press the disclosure triangle to see its memory address(es).
Press the arrow to the right of a memory address to see its responsible caller (it appears in the rightmost column.)
If someone else writes up a more thorough explanation, or can offer any related lldb commands, I'm happy to mark your answer as correct.