Our treelist lookup displays a three-tiered hierarchy. The first two tiers, as shown by the indentation level, are merely navigational/organizational (categories) and are not valid EditValue choices. They should simply expand as nodes.
For example:
Clothing
Mens
Shoes
Shirts
Trousers
Womens
Toys
Baby
Rattle
Bird Mobile
Toddlers
Push Cart
The node's keyValue is valid as an EditValue only if the node does not have children.
Is it possible to set as "unselectable" all nodes in the first tier (Clothing, Toys, etc) and all nodes in the second tier (Mens, Womens, Baby,Toddlers, etc) while still giving these nodes the ability to expand/collapse in response to clicks?
I would like to make it impossible for the user to choose those nodes, rather than display an error after the control loses focus.
At the moment, my code is examining the FocusedNode in the QueryCloseUp event, and preventing the close-up if the node has children. But that approach has a major drawback: the user cannot close the dropdown without making a valid choice.
This must be a common requirement for the TreeListLookUpEdit. What is the standard way of handling this situation?
I found a simple way:
Cancel = True in the EditValueChanging event if the focused node has children.
Related
I'm returning to Visio after being a power user in the 2000's. A lot of what I'd do back in the day was create custom masters and associate data with the shape with individual labels etc. on those masters. Sort of a multi-part shape bound to the shape data on a given master, with fine-tuned arrangement.
The shapesheet seems entirely gone in 2016 Pro and now we have the data graphic features, which are nice and interesting, but they don't give you the same degree of fine-tuning and baked-in support that my old approach of building custom masters did.
How would I go about taking a text block on a master and binding it inside that master to the master's shape data for a given property? I'm betting it's a custom expression, but I'm not sure what the syntax would be.
Oh, my overall use case here: I want to have a shape with fine-tuned fields that are always visible, but appear in different compartments on the shape. I want to link external data into the shape and have the text blocks pull the value out of the shape data and render it for the area in question. I may use Data Graphics for ancillary things on a case by case basis, but at a core, I know I want certain features to always be present in a master and styled in certain ways.
to display the property of another shape you need to reference it in the form:
sheet!N.prop.X
N being the ID of the other shape, in your case the parent.
Store this value in a intermediate field, the use insert/field.
Here's a tool to do this automatically: http://visguy.com/vgforum/index.php?topic=6318.0
To handle input options to custom properties I recommend the following
1) set up a custom property of the page as semi-colon separated list for holding the desired values. eg: prop.myOption = "A;B;C"
2) in the shape needing this option, set up am according field as fixed list. In the format cell write: thePage!prop.options.
That's it. This way you can edit the list in one central place and have all the shapes updated.
I have one Restaurant to many Menu, one Menu to many Category, one Category to many Item. I'm stuck trying to find the best way to lay out the routes for these models. Here are the options I see:
I can flatten the routes and simply require the id of the parent model.
this makes the routes simple, but requires an extra input/parameter every time I want to do anything with the model.
GET /menus?restaurant_id=X
POST /menus?restaurant_id=X&name=foo&description=bar
I can nest all the routes within their given parent models.
this makes the routes long, but doesn't require any extra inputs/parameters
this adds unnecessary information to certain lower-level models (don't need to know restaurant directly when accessing categories/items)
GET /restaurant/:restaurant_id/menus
POST /restaurant/:restaurant_id/menus?name=foo&description=bar
GET /restaurant/:restaurant_id/menus/:menu_id/categories/:category_id/items
Is there a good standard for which to choose?
I would go with your very last example - I try to keep URL params to a minimum for readability and cache/proxy concerns.
I would design it as such:
menus
POST /menus?restaurant_id=123&name=foo&description=bar
GET /menus?id=890 // specific menu
GET /menus?/restaurant_id=123 // many menus
Items
POST /items?category_id=594&name=milkshake&description=vanilla
more generically
POST /<model_of_interest>?<parent_of_model_of_interest>&<other>&<parameters>
GET /<model_of_interest>?<model_of_interest_id>
As you can see this would work for your top most and bottom most model without any additional cruft. Then validate the request and enforce access with your models which should be easily abstracted given the "only one parent" scheme you are going for (i.e. by passing &category_id=345 to create item route, you can easily construct the rest of your object and know for certain that 345 can only ever belong to menu_id=123 which can only even belong to restaurant_id=...).
This has the benefits of :
not providing information the parent models already have
allowing specific selection of a singular object "downwards" (e.g. give me item where id=338)
allowing universal selection downwards (e.g. give me all items where category_id=123)
I have a simple SceneKit view that displays antenna designs, like a TV antenna, or this less common example, a biquad.
These designs consist of a number of SKCylinders that are rotated and positioned.
Connected with that view is a NSTableView that lists the endpoints of the cylinders and lets the user edit them. When they exit an editor, the 3D view updates.
The problem is that my code current always adds new SKCylinders to the view with every redraw. So as they make edits, multiple copies of the SKCylinders end up in the view. I'm looking at the docs trying to figure out the best way to fix this.
1) should I simply remove all the geometry nodes before every draw and then make it fresh? Is there an easy way to find all the nodes that are geometry, rather than cameras or lights (or whatever)?
2) is there some way I can identify nodes within the collection so I could say that since line 5 of the geometry changed, I need to adjust node-with-something=5? I though about using name but I don't see a way to find a node by name
3) (2) is not a complete solution because I allow inserts and deletes in the list, so it might be "everything after this changes". Does that bring me to (1) or is there a better solution here?
Thanks for any advice!
I haven't used SceneKit yet but, from the documentation, it would seem that you can find nodes by name by calling:
SCNScene.rootNode.childNodeWithName( name, recursively: true)
or just iterate through childNodes recursively yourself.
Depending on the complexity of the nodes hierarchy, it may be tricky to implement insertions and deletions but, once you found the nodes you're looking for, that's just plumbing (prune and graft tree manipulations and such).
In REST - revertable DELETE a nice introduction on howto model state changes in REST was given. Basically, if you have a resource with a field status, you just put a new version of that resource with an update status field.
In this topic, I would like to extend this model. Say you have a resource which can be in two states: 1 and 2. In contrast with the simple model as described in the cited post, there are three transitions to traverse from state 1 to state 2, instead of just one.
My question is: how would you model state transitions in REST?
I myself cannot come up with an RPC-like POST, which isn't very RESTian probably:
POST http://server/api/x
target_state=2&transition=3
This changes resource x from state 1 to state 2 by using transition 3.
This isn't really limited to REST; it's more a basic question about state machines. The state machine should encapsulate all of the state, so that if you find yourself creating multiple transitions from one state to another, and the difference is significant, then that difference must also be captured in the state.
For example, say I have no home. I can move from the "homeless" state to the "home" state in three ways: I can rent one, I can buy one, I can steal one. Three transitions from "homeless" to "home"? Not in the world of machines. Either the differences are significant, or they're not. If they're not, then to the machine there's no point in making a distinction at all. Merely PUT the new status of "home". If they are, then we need to expand our concept of state to encompass the differences. For example:
homeless
A A A
/ | \
V | V
possessor <--|--- renter
A | /
\ | /
V V V
owner
I can move from homeless to possessor by stealing a house. If I squat on it long enough, I might become the owner. Or I could be homeless and rent a house, or even rent-to-own. Or I could buy one outright. All three paths get me to the "owner" state, but they use intermediate states to represent the significantly different transitions.
If you then want to represent "homeless" vs. "in a home" (possessor|renter|owner), there's no problem exposing that as a read-only, calculated resource in its own right. Just don't let anyone PUT/POST to it, since the transition is ambiguous. There's also no problem keeping the history of state transitions as an additional set of resources, if that state is significant.
I've gone through a lot of intro-level tutorials on MVVM and can certainly see its merits but I'm having a hard time applying it to my LOB application. I plan on using MVVM Light, though I don't think that's going to impact the overall design structure of my VMs.
Suppose I want to write a TaxiDispatcher application where I have a service that goes out every minute and fetches the latest status of each of my taxis. I also have a list of fixed locations that people can call from and request a taxi. The dispatcher would then assign an available taxi to that location. At any given time, each taxi would either be available to the dispatcher or assigned to one of the particular locations in order to pick up a customer.
My main screen (let's call it DispatcherView) would consist of a list of available taxis on the left-side of the screen and then two additional pieces of visual content: a list of my locations (whether or not a person is there requesting service, which taxi has been assigned to that location, etc..) and a list of taxi assignments (elapsed time since they've been assigned, location, etc..).
All 3 of those views work off the same 2 sources: the taxi data service and the list of my locations that I can dispatch a taxi to. Right now, I've got separate views and view models for each of the 3 views (UnassignedTaxisVM, DispatchLocationsVM and AssignedTaxisVM), each being injected with one, or both, of the data sources. When the dispatcher assigns a taxi from the unassigned list, I use a Messenger to communicate with the other VMs to let them know that the taxi has been assigned to a location (the DispatchLocationsView and AssignedTaxisView are both updated with this new information as a result). But when I'm wiring up each VM, I'm having to inject the same datasource(s) to each of my VMs and thus having to write similar code in each VM to respond to the command when the dispatcher assigns a taxi to a location. It may just be my lack of experience with the framework but it just smells bad to me.
Does it make more sense to simply have one VM (DispatcherVM), and have the DispatcherView be responsible for rendering all 3 pieces of visual content? I envision this would involve having 3 ObservableCollections (UnassignedTaxis, Locations, AssignedTaxis) in my DispatcherVM and binding the datasource of each of the sub-views. As new data comes in from my taxi data service, I'd parse/update to the appropriate ObservableCollection and have my views respond that way.
What's the best practice here? I've got 3 distinct, but similar, "views" of the same underlying data. Should I create seperate VMs for each of the views or have one VM expose a view that essnentially consists of 3 separate lists/datagrids, etc..?
It sounds like you have reusable plumbing across ViewModels. Have you considered using inheritance (i.g. a ViewModelBase class) to reuse that plumbing? If inheritance isn't right for your solution, you could go the route of one main VM that is composed of child ViewModels that the main ViewModel coordinates.
Both patterns are equally good solutions at a high level in my opinion. It's hard to know which is more appropriate without a lot of context.