What is good GUI pattern for showing that a child is inheriting a value from its parent. In other words, if the user sets some value in the Parent, how would we indicate in the child that the value was set from the parent?
Parent
| Value : Foo
|
|----Child
Value : Foo => inheriting value from parent.
A lot depends on how interactive you'd like the different levels to be. More interactive (ability to change/override/etc), means making them stronger - less interactive (just for research purposes) - make them weaker.
If you're talking about displaying them all in a tree, then I'd actually leave the child with the same value and a label indicating "parent":
parent_div : width = 250
|
|-- child_div : Width = 250 ('parent_div')
If you're not showing them in a tree, then I'd display the value in some non-interactive way (I'm a fan of using a light grey, indented and italicized (i know that seems like overkill, but it's worth it)) - and then have a tooltip or mouseover that indicates where the original came from.
In either case, let me stress, it's INCREDIBLY valuable to have a direct link somewhere that gets you to the point where the value was set to begin with. It's so annoying to have to try to manually navigate there.
For an example I quite like, let me point at the Trace Styles tool in IE8 - tells me EXACTLY where the style came from (and lets me edit all the way up the chain) - Convenient!
IE 8 SS http://img101.imageshack.us/img101/3172/captureri.png
Leave it at book or regular weight, and make values modified in the child bold weight.
Related
We have a script that export our Indesign documents to HTML and one of the routine is to export tables. In this script we go throught each Tables->Rows->Cells and evaluate some of the properties (i.e. bottomEdgeStrokeType, topEdgeStrokeType, etc...) and transport them to HTML.
Now yesterday we had problem converting one particular document because some cells were missing the "bottomEdgeStrokeType" property entirely. I've discovered this by outputting the properties of each cells and compare the faulty ones with the others.
This line bellow was trowing the error: "Invalid object for this request.".
var cellType = cell["bottomEdgeStrokeType"];
Now, to fix this I've wrapped this around a try catch block to handle the case when it's not there, but now what is puzzling me is how on earth can Extendscript instantiate an object with missing properties?
Indesign version: CS5.5
A property is not only 'undefined' if it cannot exist at all (such as asking for the parent text frame for a character in overset text), but InDesign's Javascript engine also fails to return a reasonably accurate result for multiple values.
If you ask for "the" point size of a paragraph, where this paragraph contains multiple sizes, poor ID does not consider to return something like CONSTANT.Mixed, or the first value only, or (what I might have preferred) an array of the values; it returns undefined instead.
So how can a single table cell have multiple bottom strokes? If the cell underneath it is split into multiple cells, and one has a "top" stroke but the other has not.
It's difficult to recommend an adequate solution. You could first test if the current cell is "merged" (as far as InDesign's internal table model is concerned) with columnSpan; and if so, iterate over the number of columns spanned and test the next row's cells for their top stroke, which in theory should match the bottom stroke of the cell above. (I find myself wondering if this is always true. ID's table model is ... weird. It's not entirely like a HTML table, despite the functional overlaps.)
If columnSpan is greater than 1 and equal to the number of cells immediately below the current one, you could test if all of their "top" values are the same and if so use that value. (I never tested this so ID's table model may simply fail because a cell is merged, regardless of same-values or not.)
One could attempt to flag this cell's next row to output "top" strokes as well -- but alternating top and bottom strokes may not align nicely in CSS, side to side. Perhaps it's best to translate only the first top stroke value to "the" bottom stroke property for your current cell, and fix up manually where needed (how?) or, a reasonable action, hope that no-one will ever notice it.
How is it possible to get, directly from the Matlab command window, the position (i.e. the coordinates) of an object (e.g. an arrow, a rectangle or sim.) that I have drawn on a plot?
You can usually do this using the handle graphics properties. For example:
Make a plot
h = plot(1:10, rand(10,1));
Then get the actual values of the points
x = get(h,'xdata')
y = get(h,'ydata')
Different types of objects have different properties, sometimes you have to explore. In that case this syntax is useful.
get(h) %This displays all available properties on `h` to the command window
A final useful tidbit is the gco ("get current object") function, which provides the handle of the last item that you plotted or manually clicked on. This can help if you're not sure where the plotted item came from.
Edit:
To find all of the properties which are descendents of an object, use either findobj, or findall. For example:
findobj(gcf); %Returns all non-hidden, typical objects. This should be your first attempt.
findall(gcf); %Returns all children, even hidden object, such as titles, manually added annotations, and UI menus
This call removes some common UI annotations
get(findall(gcf,'-not','type','uimenu','-not','type','uitoggletool','-not','type','uipushtool','-not','type','uitogglesplittool'),'type')
(Presumably the last example could be improved with a properly designed regexp, but I can't seem to get that working right now.)
I don't do much programming in applescript but I have a personal app which is mostly python but generates simple applescripts and calls them via a system call. Applescript is so different from the languages I usually program in that I can't figure out how I...
get the window order of a document within an application?
For making calls like:
set bounds of **first** window to %s
in other words, how can I get the document's "window order" for an application?
Is it possible to interact with a window through accessing the document like this:
to get bounds of first window whose document is "%s"
(which doesn't work) or do I have to get the document's window order first and then interact with that window (via its order) in a second line?
Any insight would be great. Thanks.
You can do both of these things just fine. The first line is just set bounds of window 1 to ..., or, if you prefer, set bounds of the first window to ... The second one depends on what, exactly, you want to do. If you want to access the first window whose name is something in particular, you can just do get the bounds of window "NAME"; if you really want the name of the document, though, you'll need to do something like
set d to the document "NAME"
repeat with w in windows
if w's document is d then return bounds of w
end repeat
You should be able to do the first window whose document is d, but this fails; as far as I can tell, it's because document is also a type name. Also, if window "NAME"/document "NAME" fails—it's the sort of thing that I remember sometimes not working, even though it should—you can instead use the first window whose name is "NAME" (or the first document ...). But the simple form will almost certainly work.
Also, if you're just generating these AppleScripts, calling them, and deleting them—in other words, if you're pretending they're Python functions, rather than generating them for later use—I'd highly recommend using appscript instead,. I've never used in in Python, but I have in Ruby, and it's a really great way to deal with everything AppleScript does while still using your language of choice. For instance, I think your first example would become app('Whatever').windows[1].bounds.set((0,0,0,0)), (or ...windows.first.... if you prefer) and your second would become either app('Whatever').windows['NAME'].bounds.get() or app('Whatever').windows[its.document.name == 'NAME'].get(), depending on if you need the window's name or the window's document's name. This is all untested, but certainly captures the flavor of what appscript tends to look like (nice and concise).
I'm designing a simple GUI. I have Widgets, which have children and one parent. Each Widget is a Composite object, with a vector of WidgetComposite objects. One of those WidgetComposites is a PaintingBehaviour, but the Widget doesn't know it as such.
To display my window, I use a Visitor, called the ScreenVisitor. When the Visitor is called, this is what happens :
The first widget, the WidgetScene, iterates on each of its Widgets and calls the "accept(Visitor* v)" method. Then, each widget accepts the visitor, then iterates on its children.
For instance, this is a list of the objects (in the order it's going to happen) the visitor will have to accept.
root
child1
child2
child3
child4
child5
child6
child7
Now, my problem is simple : I want each Widget to be painted on its parent. How would you proceed ? I've tried with a tree, but I always have the same problem : when I have to go up in the hierarchy (for instance, after having displayed child3, when I have to display child4) I don't know how to get the right parent.
I'm coding in C++ but this problem is not language specific.
Do you have any ideas ? Thanks in advance !
The question is not very clear to me. If you just need to get them to be painted in the correct order. Parent before children, that would be quite easy:
accept(Visitor v)
paint() //paint parent first
v.visit()
foreach child
child.accept(v) //then paint children
If you need the parent (why?), you could change the accept method to (optionally) take a parent node.
accept(Visitor v,Element parent = null)
paint()
v.visit()
parent.foo()
foreach child
child.accept(v,this)
All right, since I could not find anything else, I tried this solution :
The visitor create a tree of "DisplayNodes" objects, who are basically a class made essentially of pointers. Here are the attributes of the class :
class DisplayNode
{
private:
Widget* myWidget;
PaintingBehaviour* myPB;
DisplayNode* myParent;
vector <DisplayNode*>myChildren;
};
Every DisplayNode is stocked in a vector in my visitor.
Then, for each PaintingBehaviour, I test the parent of the Widget connected, and check if one of my Node's "myWidget" is this parent. So I can find back where is everything. After that, it's quite easy, a simple paint method in DisplayNode with recursive calls to the children, called with the first DisplayNode of the scene...
Since it's a bit heavy, I create the tree of DisplayNode only once (though I do it again if PaintingBehaviour or widgets are added / removed). If the tree already exists, I go directly to the recursive painting.
It's a bit twisted (and probably not quite optimized), I'll admit, but it works ! But if anybody has a better solution, I'll be more than happy to hear it.
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.