I would like to avoid that the watch window collapse my list variable content on value change during the process of my application in debug mode. I don't know if i'm really clear, see pictures below:
Collapsed:
Expended:
I would like to see the content of my list and let the content of my list expanded even if a string of my list change. Is there a way to lock the watch window?
As #JasonH mentioned, list will stay expanded while variable references same object and watch will show modified element in red color. List will collapse when you assign new reference to a variable. I am not aware of any option to change this behavior.
As an alternative, you can pin items in a list you are interested in. Or you can pin all items. In this you will get list expanded event if reference changes. But It will be available only in this concrete tab. Here is an example and picture of each step:
var ints = new [] {"1", "2", "3", "4"};
ints[1] = "3";
ints = new[] { "1" };
The short answer to 'pinning a watch item open' is no, you cannot.
First, this option is just not available in VS but you can suggest it at Visual Studio User Voice if you feel that it would help you and others.
Second, and this gets a bit complicated but follow with me...
If the watch item goes out of scope, it will collapse. If the watch item is re-initialized (which in a way kind of takes it out of scope for a moment) it will also collapse. If you have a watch item (complex object) and you start changing its properties and/or fields, you will see that they (the properties and fields) will change but the watch item (object) does not collapse.
I hope this helps.
Related
I am new to UI test writing.
I wanted to know if it is possible to know what elements are/exists in view. I want to know how many and how they are called.
I tried something like this to loop through all elements, but it does not work.
for element in app.accessibilityElements! {
print(element)
}
You're looking for the debugDescription method of XCUIElement, in your case to get the entire hierarchy of the current visible window:
app.debugDescription
Quoting header comments:
Provides debugging information about the element. The data in the string will vary based on the
time at which it is captured, but it may include any of the following as well as additional data:
• Values for the elements attributes.
• The entire tree of descendants rooted at the element.
• The element's query.
This data should be used for debugging only - depending on any of the data as part of a test is unsupported.
You could always have a break point in the testcase and then make some print calls to the console.
po app.accessibilityElements
po app.accessibilityElements.elementBoundByIndex(0)
po app.buttons["Icon Menu Light"]
etc.
And see what comes back in the output view hierarchy to reference, or just a simple call to po app will print the hierarchy.
Once you know a particular view exists.. app.buttons["Icon Menu Light"].exists.. you can then try using something like this to confirm the button/element is visible within the current view by passing it to a helper function like:
func isElementInView(element: XCUIElement) -> Bool {
let window = XCUIApplication().windows.elementBoundByIndex(0)
return CGRectContainsRect(window.frame, element.frame) }
This will tell you whether the element is visible on the screen, because the element.exist call will return true, even if the element is off screen and hasnt been shown to the user (i.e. if something hides off screen and then transitions into the frame)
newbie question: can anyone tip me to how to understand/interpret what is displayed in the debugger var pane?
Ex: I am passing an NSDictionary as a method param. I set a breakpoint so I can examine the values in the dictionary. The image below (if it comes through..) shows the expanded view of this var in the debugger. It correctly reports that it contains 3 name/value pairs but as I expand all the sections, I simply can not find where these are stored.
Do I have to create local vars of these name/value pairs in order to view them when I want to check? I know I can use NSLog or printf but sometimes I just want a quick peek.
Right click the variable, click "Edit Summary Format" and type the following:
{(NSString*)[$VAR description]}:s
This replaces the GDB formatter for NSDictionary with a call to the more expensive description method.
That is, instead "x key/value pairs", you'll see the contents of the dictionary as produced by -[NSDictionary description].
This is the same as typing po dictionary in the console window. Or right clicking the variable and choosing "Print Description". Both of them call the description method of the object.
If you are curious, you can find this formatter at /Developer/Library/Xcode/CustomDataViews/Foundation.plist under the key NSDictionary. What you type as replacement is saved in /Users/USERNAME/Library/Developer/Xcode/UserData/Debugger/CustomDataFormatters and will persist across runs until you delete that file.
A NSDictionary is really a class cluster and few people know the inside structure. At this point you ain't going to find much use for that debugger tree.
This is what you are looking for :
Click on your dict, then click on the little "i" icon :-)
How can I change the order of the entries in the context menu?(e.g. for Directories) I need to know how Windows determines the order when showing that so I can control it. For example I want to place my custom action at the end of the context menu list
Thank in advance!
My Google-fu led me to this:
So the sorting is based on the following elements in decision order:
Key priority (eg, txtfile, *, AFSO)
Registry Enumeration order of shellex\contextmenuhandlers with a special case for static verbs always being first
IContextMenu Implementation order
So if there is any contention for position, there is no consistent way for an extension to guarantee their relative position within the menu.
Obviously you can't do anything about phase 1. Phase 3 only applies to the verbs implemented in your handler. That leaves phase 2. The only thing you can do is name your entry under ContextMenuHandlers such that it would be enumerated first, but nothing's stopping someone else from doing the same thing.
This is for Windows 7, maybe same for newer versions. It was inspired by the other answers, all is affecting the order.
I'm explaining entries for "*" (all files), but the same goes for special extensions.
I take no responsibility for any changes made in registry!
There are three sections in the context menu, as it says in How to Change the Order of Options in Context Menu (from answer by #Anonymouse)
They call them:
2 - Default menu position (at the top).
1 - Send to, copy to folder and move to folder menu part (in the middle).
0 - Rename menu part (at the bottom).
Within these sections the position is decided by the rules in answer by #Luke
The easiest way to change the order within the "section" is to change the name of the registry key under HKCR-*-shell or HKCR-*-shellex. All under subkey shell will be before them under shellex. Keys that have the CLSID as the key name will be as last entry since they are last in the used order.
As an example, I was following a sample from MSDN to build a Context Menu Handler
EDIT 2021-04-14:
The MSDN link is no longer valid, it redirects to a "Browse code samples" page. You can search there for Context menu sample, but the one I followed seems to have been removed.
The closest to the old one I followed is perhaps this
The one I followed is using the CLSID as the name for the key under shellex, and a "friendly name" as default value. It was placed at the bottom of "section" 2 (top section). I changed the key name to something like Asample and changed the default value to be the CLSID instead. Now it was directly after entries under shell.
There are some more ways of changing the order.
For keys under shell you can add the value Position with string data Top or Bottom. Not possible to decide in what "section".
For keys under shellex the value Position has no effect. Instead it's possible to decide in what "section" the entry will be using flags, described in the link above.
Use the CLSID for the shellext you want to move. It's like
{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}. Get it either from the key name or the default value, it depends on how the entry is done.
Find the entry under HKCR-CLSID, the key has the name of the CLSID.
Add a value with name flags and data DWORD with the "section" number described above under the found CLSID.
This did it for me... Steps 4 through 7 - setting the "flags"
http://techoqueries.blogspot.de/2012/08/how-to-change-order-of-options-in.html
This Q&A shows a simple way to CREATE (not move) an item within the context menu. I managed to duplicate an existing item. Then I moved my item to a higher and more accessible position within the context menu, by renaming the key to start with something "aMyItem" or "0MyItem".
I've been trying to find a way to re-order things, it irritates me that the daily use options are pushed to the end, when obscure utilities you might use once in a blue moon are filling up the top of the list.
I found a lazy way to do this, using a little utility package called "Windows 10 Manager" Windows 10 Manager - it's a few quid, but it's a lot easier than registry hacking. It can't do everything, but it does let you add items into the top section at least - and also to suppress cheeky ones that installed themselves in there without asking.
As you can see, it's actually duplicated some entries rather than moving them, but never mind.
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.
I am trying to see the properties of an object with over 300 properties in the Immediate Window of Visual Studio 2005. Only the first 100 items are displayed, followed by this caption:
< More... (The first 100 of 306 items were displayed.) >
I am trying to see the rest of the items, but can't figure it out.
I realize that I could see these in a Watch window, but that's not the same.
Sometimes its useful to see the list in the immediate window rather than looking in the watch window. You can easily see more results than the first 100 by using:
yourList.Skip(100).ToArray()
Which really doesn't take long to write and works well - was useful for me.
Update: As pointed out in the comments below, this answer is actually wrong and applicable ONLY to collections and NOT to objects with lots of properties. I'm leaving it here as lots of people seem to have found it useful.
If you add your object to the watch window, then expand the properties so that all are displayed. Then Ctrl+A and Copy. You can then paste in excel to get an organized list of properties and their values.
The immediate window was designed to be a quick view tool. If you want to see more detail, you will have to view it in either the Watch Window or the Quick Watch Window.
Another option is to write a Visual Studio AddIn that operates similarly to the Immediate Window, but has more options.
I always create an extension method to export objects to xml when debugging like this. It's very useful for troubleshooting object data. Here is what I use:
public static void SerializeToXML(this object entity)
{
System.Xml.Serialization.XmlSerializer writer = new System.Xml.Serialization.XmlSerializer(entity.GetType());
System.IO.StreamWriter file = new System.IO.StreamWriter(string.Format(#"{0}\{1}.xml", Directory.GetCurrentDirectory(), entity.GetType().Name));
writer.Serialize(file, entity);
file.Close();
}
It's not 100% full proof, but most of the time it is perfect. It will create an xml file in the application directory with the objects name as the file name. In the immediate window you can just type the object name then .SerializeToXML().
so: myList.SerializeToXML()
Its an old question but to get the properties and values of an object during runtime a more reasonable solution with Quickwatch window is here:
Open Quickwatch during Debug mode
Type in your Variablename and press Enter
Press CTRL + A and CTRL + C in order to select and copy all Properties. You need to expand those which contains values and are non primitive types.
Paste to your favorite editor.