When debugging with Xcode, is there way to see a value of property when mouse cursor on it in code? - xcode

I don't understand why, even on Xcode 6, I need to click on self, search the property, and only then see the value.
If the object have 100 properties it's very annoying.
I'm searching for simple solution that when I set my mouse cursor on self.someproperty,
above "someproperty" I will see the value of it, in any case, NSString, NSArray, Etc.
Thanks.

That's presumably because the "properties" you're hovering above are not really variables. They are syntactic sugar for accessor methods (that generally reference a backing instance variable, but not necessarily so). These accessor methods, the getter and setter, were either synthesized for you, or you may have manually implemented your own custom methods. For more information about declared properties, see Declared Properties discussion in Apple's Core Competencies document or Properties Encapsulate an Object's Value in the Programming with Objective-C document.
Consider the foo property below. You cannot hover over references to self.foo and see what you were expecting. But, if you hover over the instance variable (ivar) that backs the property, you may:
(As an aside, note that the reference to self.foo = ... above does not reference the foo getter method, but actually calls the setter method setFoo. So, it seems like a non-trivial exercise to have the IDE debugger recognize that by hovering over that "property" while execution is paused there, but realize you want to call the getter to see the value rather than calling the setter that line of code actually references.)
Anyway, back to the IDE, you can also twist open self, you'll see it there, too:
These techniques are imperfect (sometimes the debugger gets confused), but hopefully this illustrates the basic UI.
I gather you would like it to call the accessor method when you hover over the property name. Does that mean you also want it to call any random method that the mouse happens to hover over, too? In a purely functional language, this notion seems a little more plausible, but it seems dangerous in the procedural languages where any method could conceivably change a state variable and have some unintended consequence. I would have thought that if you contemplate a feature like this, it should require some something more affirmative action than merely hovering over it.
Anyway, if you really want this feature, file a "feature request" at http://bugreport.apple.com.

You can use the the logging functionality of lldb right in the console, it's a huge help:
In the right part of your Debug area you have the Console (that's also where all NSLog output goes to).
In the Console you can just use the command po (print object) and print to print the value of a variable.

Related

IDWriteInlineObject::GetOverhangMetrics method is never called

I have implemented IDWriteInlineObject interface to draw ID2D1Bitmap as inline object inside a text. Everything works fine except one: my implementation's GetOverhangMetrics method never get called.
I've also tried a sample from DirectWrite SDK samples (PadWrite Layout Sample, https://msdn.microsoft.com/en-us/library/windows/desktop/dd941792%28v=vs.85%29.aspx). And got the same result ('InlineImage::GetOverhangMetrics' in InlineImage.cpp is never called).
Therefore my question is why one's implementation of GetOverhangMetrics method never get called?
I admit I haven't tested this, so just a thought - I think it's possible it's called when you ask for overhang metrics of layout itself, so when layout method GetOverhangMetrics() is called it feels like it would accumulate not only regular text overhang boxes, but inline object boxes too.
GetOverhangMetrics is called for an inline object when the same method is called explicitly on the text layout object containing this inline object.

How can I know who calls the method in Xcode?

Does Xcode have a way to show the caller function of a method? I want to know all of the calling functions of a method in a class. A solution would be to find the method in the project, but sometimes different classes have methods with the same name - That could find us a method we're not looking for..
Many other IDEs have this capability, such as Visual C++ 2003/2005/2008,Eclipse ...
Can you do this in XCode?
Xcode 4.4 intrudced this functionality:
New Features in Xcode 4.4 (Scroll down to 'Find and Search Additions')
Move your cursor on top of the function you are interested in
Open the Assistant editor(⌃ +⌘+Enter)
On the top of the assistant editor, Select 'Callers'
You will see a list of all the function that's calling your function
Not the as effective as other IDEs, but does the job.
Yes. Set a breakpoint inside your method, then when it breaks, there are two spots to see a stack. First is in Xcode's "console" area (usually the bottom middle), there is a top-bar which may not immediately appear to be navigable, but it is a select-style UI control which has the entire stack in it. Selecting a different level shows you that scope's variables, etc. and pops your editor to that exact file (where you can mouse-over variables to see their in-memory real-time values). Second is in the left-hand area (where you normally browse files). There is another tab there (besides the file browser) for exactly this purpose. There is a slider at the bottom which controls how many "steps" in the stack you see; clicking on one has a similar affect.
For simple refactoring such as method re-naming, you can use the contextual-menu when you right-click a selected method-name, and Xcode will replace all identical selectors in your project. However, this does not address what you mentioned about different classes having methods with the same signature. It does, however, give you a very nice interface for reviewing the changes in-context and easily accepting or rejecting them one at a time.
It might be noted, however, that changing method signatures often may be a sign of poor design, and particularly if you have to do it with methods which have the same signature on different classes (which are not "siblings" and therefore should both get the rename)

Duplicate of first entry in navigation bar in custom Visual Studio Language Service

I'm implementing a Visual Studio Language Service for a custom scripting language used internally at my company, and I've run into an issue with the navigation bar implemented as a subclass of TypeAndMemberDropdownBars. The subclass is created by my LanguageService subclass' LanguageService.CreateDropDownHelper method.
In the OnSynchronizeDropdowns method I'm iterating through the types defined in the file and adding DropDownMembers to the passed-in array to fill out the navigation bar. The issue I'm seeing is that the first item in the array is being duplicated and placed at the end of the listing by code that I don't have access to. This extra item does not behave correctly when selected (nothing happens), but doesn't seem to cause any other issues; the rest of the items in the list work fine. Additionally, this only seems to happen for the type dropdown box - the members dropdown box does not display this behavior.
I'm hoping someone else has seen and resolved this issue and could provide some assistance. Thanks!
Turns out this was caused by me calling LanguageService.SynchronizeDropdowns from my LanguageService.ParseSource method, which was being called on a background thread. I've fixed the problem by setting a flag when ParseSource does a Check parse, and then implementing a check for that flag in my LanguageService.OnIdle function that will call SynchronizeDropdowns. It's now working as expected!
A better solution is to implement the LanguageService.OnParseComplete callback, and call SynchronizeDropdowns from there. OnParseComplete is always called from the main thread, so this prevents any synchronization issues from coming up, and also keeps you from having to keep track of whether or not you need to call SynchronizeDropdowns().

Flatten inherited members in Visual Studio's Watch window?

Is there some way to make the Watch window display all inherited properties and fields in one long flat list, rather than hidden behind a nested "base" node?
I'm debugging some C# code that makes massive use of inheritance - some of the properties I want to watch are behind three levels of "base" in the Watch window. This would be more or less bearable if I just wanted to examine a single such object, but I'm actually looking at a tree of them...
see http://blogs.msdn.com/b/jaredpar/archive/2010/02/19/flattening-class-hierarchies-when-debugging-c.aspx
UPDATE: I wrote a commercial tool called OzCode that solves this problem. The idea is that if you're interested in a property of the base class, you can "Star" that property, which causes the property to appear at the top of members list, and also in the text of its parent.
So for example, in the following scenario, I had to expand two base nodes to get to see the properties I wanted, "Important" and "Interesting":
But once I star these properties, they will always appear at the top, even when viewing variables of the Derived type, so I'll see:
These stars are persisted and will be shown whenever you view a an object of that type in the DataTip or QuickWatch window from that moment on, so the next time you a variable of that type, you won't need to expand those "base" nodes. And because starred values appear as the parent node's text, if you're looking at a tree datastructure of these heavily nested objects (as you stated you were), you will be able to see these properties without even expanding the nodes at all.
FULL DISCLOSURE: I'm the co-author of the tool I've described here.
Not as such. You see, it is a feature! The ability to see where a property comes from is important most of the time.
I understand your pain though. There are some work arounds. First, you can just put the object.property in the watch window. This will just display the property you are looking for. It is great for digging into a specific property but not so much for getting all the others.
You can also try (BaseClass)object. This will cast it to the base object that contains the property (properties?) you are looking for. Again it is great for looking a a specific subset of properties but completly hides all the others.
Good luck and good hunting.

How can I trace what happens during XAML loading?

I would like to find a way to see what happens while my XAML is being loaded. What classes are being instantiated, and in what order? Which properties are being set, to what values, and in what order? Which methods are being called (e.g. BeginInit, EndInit, etc.), in what order, and with what parameters? That sort of thing.
(If anyone's curious as to why, it's because the XAML loader is doing something magic that I can't duplicate in code, and I'm trying to figure out what it is.)
My first idea: Configure VS to debug into the .NET source code, and single-step through the XAML-loading code to see what happens. Unfortunately, source stepping has been busted for months, and there's no sign of that changing.
My second idea: Make my own classes that descend from WPF classes, override OnPropertyChanged, and do a Debug.WriteLine. Unfortunately, one of the classes I want to know about (BitmapImage) is sealed, so I can't descend from it.
Anyone have other ideas on how I could get some visibility into what the XAML loader is doing? Are there any tools (profiler, maybe?) that could give me a call graph? Is there a way to turn on some kind of logging in the XAML loader? Thoughts / suggestions?
Edit: The article Steve linked to does have the answer, though their sample code makes every event get displayed twice. For reference, here's how to make this work in code (no app.config changes required). Add these lines before the InitializeComponent() call (or type both lines into the Immediate window in the debugger):
PresentationTraceSources.Refresh();
PresentationTraceSources.MarkupSource.Switch.Level = SourceLevels.All;
This will cause detailed output to show up in VS's Output window, including the properties that get set magically behind the scenes.
You can trace a lot of the binding and loading with system.diagnostics. I've found a number of problems using this namespace. Its unwieldy like everything else in WPF, but it works. You can see what's getting set and where.

Resources