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.
Related
I am making a program that sweeps software parameters of a DUT and logs measurements from various instruments while doing so.
To make this program more flexible, I want the user to be able to configure an arbitrary set of instruments (including multiple of the same kind) to log measurements from. Each instrument has different configuration parameters.
What i need is a dynamic UI, where I can add (and remove) Instruments and have a different configuration UI for each instrument.
I made a little sketch of what I have in mind: UI proposal
What I tried so far is to have an Array of a Cluster with a Subpanel in it, but all the Subpanels in the Array show the same VI.
A simple way of doing this is 2 subpanels. One stays on the main screen with your current vi running. When you want to switch vis load the new vi into the off screen subpanel. Move the positions of the subpanels so that the new one is on screen. Unload the old one and allow the new one to start. The old one is now ready for the next vi to run
Instead of a cluster or an array, the basic idea for making something like this work is to have one subpanel which will contain multiple subpanels inside it and populate/position/resize/show/hide them, etc.
See this thread for a discussion and a basic example I posted there - http://forums.ni.com/t5/LabVIEW/Independent-cursors-on-array-of-cluster-of-graphs-or-work-around/m-p/2319700#M728304
(Note - that thread shows a discussion and expansion on the topic. The original simpler example is here - http://forums.ni.com/t5/LabVIEW/User-interface-problem-list-of-clusters/m-p/2311770#M726599 )
While I always liked the idea of this, I never actually needed it for an actual UI, so I don't think I have anything to add beyond this example. Also note that the example is very crude and only meant to demonstrate this concept.
Note that there are two ways of handling the number of panels - have enough to be displayed and control which VIs they show based on the scroll bar or create "enough" subpanels and control their visibility.
I use the MVC programming model. I am running into a problem using Unity's hierarchy inspector. Say I have a Controller script: C_CardDrag. Now, because this drags a UI item thats nested several layers deep, it won't be readily apparenty that this C_CardDrag script is attached to an icon within in the card, and NOT the root object. You see what I mean in the image below (the blue highlight is where the C_Drag needs to be attached, NOT the top level object, otherwise the whole thing gets dragged when I only want the icon in the middle dragged).
I feel that it can be VERY confusing to design and name classes when they need to appear on nested objects.
Do you have any design practices I can follow to make script names clearer to where they are attached?
For example say I have a Tree object, and it has several brances. And lets say I have a C_Tree script, and a C_Branch script. How would you handle making it clear that C_Tree goes on a Tree, a TOP level object, where as C_Branch goes on a nested UI object?
Update:
Found a good resource here: Component based game engine design
Like any software that is being developed, you should only apply the appropriate Architectural and Design patterns that fit that project.
For example:
I was building a game that would be used for different devices. Although Unity lets you switch from Android to iOS seemingly easy. This game could be played completely differently on different devices, so I wen't with MVC.
Another game was built around Peer to Peer.
So overall you have a lot of options.
The way you can organize your files is by folders in the Project section of the Editor. I like to use something like this:
You will notice the Model is not in the Hierarchy. I don't use MonoBehaviours for models. In some cases, even the Controller could be non-MonoBehaviour code. That is why I prefer to have all the organization happen in the Project not the Hierarchy.
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)
This is sort of a best practice question, since I can think of a few ways that would work.
I want to implement an outline view. Let's suppose I want to implement the one in OmniFocus (my aim is very similar):
(I refer to the outline view in the main pane of that screenshot, not to the sidebar.)
So my data type is a task. Any task can have subtasks. Each task has one or zero parent tasks. Classic data model for displaying in an outline view, right?
BUT! I would like to offer the user the ability to group these tasks visually by a property of their choice. They could group them by milestone, or by assigned user, or by component… there'll be a bunch of these. And this grouping should appear in the outline view, at the top level of the hierarchy, just like the "Inbox", "Home" and "Work" items in this OmniFocus screenshot.
So it's fairly obvious that to display the grouping, I should use the built in NSOutlineView methods for drawing a group cell: the outlineView:isGroupItem: delegate method. The problem is, this setup is assuming that each item in the outline view is represented by an item in whatever data model I've connected it to: so both my tasks and my group headers have to be represented in the data model.
Therefore, just binding to the Core Data table that represents my tasks is a no-no. I could forego bindings all together and just go back to the old style data source methods, but then I lose a bunch of useful stuff. So is there a middle ground?
I could, for example, create another class TaskTemporaryGroup. I give that class an ivar NSSet that is subtasks, the same key path as could be used on a task to get its children. Then I can bind my set of TaskTemporaryGroup objects to a tree controller, and it'll arrange the whole tree regardless of the fact that the top level items are a different class to those lower down. I'd have to take care when implementing drag and drop, to make sure that the grouping rows can't be arbitrarily dragged about, but it might work.
The other point of contention is that I would like clicking on the table headers to sort the rows within each group, but not to sort the top level groups. I assume NSTreeController applies the sort descriptors to each level of the hierarchy? I could have my TaskTemporaryGroup class return the same thing (i.e. its desired sorting order, that I've calculated separately) for any of the key paths that I want to be able to sort the rest of the cells on, so that to the framework it would look like they stayed in the same order no matter what property they were sorted by. Is this a good way to go or is it a hack?
So, to summarize:
How do people suggest I implement this kind of hierarchy, where the top level is a special case and all subsequent levels are the same kind of object?
Is the way I described, with a class to represent the top level objects that happens to respond to the same key paths as the child objects, a good way to go?
Does anyone have any tips about how to make sorting work well in this scenario?
Or will trying to use bindings for this task cause me a world of hurt?
Thanks,
Amy
I'm working on a project where they essentially used TPanel for the only purpose of displaying a bevel (And maybe the design time convenience Panel have over Bevels).
Ok, I know TPanel is heavier than TBevel. Amongs other things, each TPanel create a user objects, which is a limited resource.
What I would like to know, beyond user objects, what's the overhead of TPanel? Is it next to non-existent (Especially on modern day machines).
If you were working on such a system, would you suggest :
Going back and changing all TPanel to TBevel.
Say "Ok it was bad. Lets not do it again in the future"
or
it's too small a concern and the design time convenience is well
worth it.
I wouldn't know if this design is intentional but, there's a slight navigational behavior difference when controls are grouped together in a window. If the focus is changed by arrow keys, after the one having the last tab order the first control will be focused (down/right), or vice-versa (up/left). IOW the focus will be wrapped in the parent. That's of course if any of the controls do not need the arrow keys.
Regarding the question, as it is already stated in the comments, apart from using up a count in an object pool, there're other resources associated with a window. It will also waste a few CPU cycles. There'll be one more level in the clipping chain or the messaging or keeping one more z-order list etc.. MSDN puts it as (I guess navigational aspect is being referred rather than visual partitioning):
For best performance, an application that needs to logically divide its main window should do so in the window procedure of the main window rather than by using child windows.
Nevertheless, as again already stated in the comments, most probably, no one will be able to tell the performance or resource difference caused by a few panels..
The correct answer is choice #3, so if that's the project's design approach, don't change it.