good demo of my problem: http://fabricjs.com/hovering
If you select any item, it is displayed on top.
In earlier versions (1.5.0 - 1.6.2) this problem does not exist.
Sorry for bad English.
If you dont want thie behaviour, you can set the preserveObjectStacking to true. Check the docs here: http://fabricjs.com/docs/fabric.Canvas.html
However, there is this one issue with background objects, so beware https://github.com/kangax/fabric.js/issues/3095
Hopefully, they'll push a fix soon otherwise your last resort would be going back to 1.6.2.
I believe that is meant as a convenience for the user. Although the object moves to the front while selected, as soon as it is deselected, it falls back to its original z-order.
You can test this out at the hovering demo you linked. Superimpose two objects and determine which is front of the other then select and deselect the object in the back. When you hover over them, the order should still be observed to be the same.
Related
So I just discovered you can enable the grid footer. And in theory you can show whatever you want in there e.g. display text or sum etc.
The Text property seems to work. The SummaryType doesn't. I feel like there's a missing step or something.
Has anyone managed to make the Footer work ? Just so you know, StatusField is not going to cut it here as it won't fit.
TIA
If you look in the source code for the Sales Order Screen functionality, there is a constant called 'Availability_AllocatedInfo' which is used to construct the 'On-hand...' message in the summary above. If you search for that, you'll see that there is a 'Availability_FieldSelecting' function that sets that information. The field called 'Availability' that is updated is what is used to show the status. Look in the aspx for SO301000, to see all the elements you'll need to replicate the behavior.
Hope that helps
I have 2 Objects that I have combined with the union/fusion control
The result is as expected, but now I would like to remove the remaining lines of the separate objects (at least in my view).
I understand the underlying principle of the stacking object tree and its good to have them still all available as single entities, but I would like to hide what would not be seen in reality also in my view.
Any takers?
Thanks
For anyone who's interested I found the solution. The view property dialog allows you to change the document window setting to "shaded" which hides the lines.
I am currently calculating xFov, yFov for my SCNCamera when creating a SCNView. This worked find up to now, since the scene has always occupied the entire screen.
I now need to support a scenario where this is no longer the case, i.e. the cameras field of view (xFov, yFov) should be recalculated whenever the SCNView changes its size.
Where is the best place to insert the code that does the recalculation? If possible, I would prefer not to subclass SCNView.
Since Yosemite NSViewController exposes viewWillLayout and viewDidLayout. It might be the right place recalculate your fields of view.
I have a ribbon button on the case entity that updates a single two-option field on the form via javascript. When this is used on a case that has been resolved/closed it returns an error as the form is now read only.
Is there a way in javascript that I could get it to re-activate the form, change the field and then put it back to the way it was before? I have tried to force the change on the form but even if i manage to make it appear that you can save it, it will return the error as the form record is still counted as de-activated, even though you can change the fields
Thanks
You should be able to use a SOAP call for this, its a little involved, I would suggest starting here. You have to generate XML that represents the request, the link provides some tools to do this.
I believe you will need to issue JavaScript versions of SetStateRequest (to open) and CloseIncidentRequest (to close).
On the other hand, which is a different approach entirely, is to disable the button when the record is deactivated, then users have to manually renable the record make the change and close again. This is closer to 'working with the system' which I have touched upon here, its a different situation but the principle still applies.
I know i can use
<mt:EntryAssets lastn="1">
<img src="<$mt:AssetThumbnailURL width="100"$>" />
</mt:EntryAssets>
to show the 'last' asset...how do I show the 'first' or 'oldest' assest?
[I'll point out here that "first" and "oldest" are not necessarily the same question.
You'll see why this is important below. Given the snippet you used, I'm going to assume what you're asking for is first as in position within the entry content. Sorry for length, but this is one of my pet bugs.]
Technically, you can't. That bug(summarized further down if you don't have an Fbz account) has finally been attached to a milestone, so hopefully this won't always be the case.
Practically, reversing the sort order will usually probably output what you expect:
<mt:entryassets limit="1" sort_order="ascend">
...as long as you compose your entries top-to-bottom, and don't later mess with the assets much
The underlying problem is that the current EntryAssets implementation doesn't actually take your content into account. It just loads a list of associated assets and then sorts them by the created_on dates of the assets themselves, not what physical order they appear in or even when they were attached to that particular entry. So as an extreme example, if you insert five images into a post, my snippet above will return the first image, as expected. If you later reverse their order and save, it'll still output that same image, which is now the (ordinal) last one. So, back to what I said at top, you're thinking "first" and MT is always giving you "oldest." And this requires an even further assumption that you're always uploading the assets at time of composition. If one of them was already in the system from say, two years ago, it's going to get returned because it's just older than everything else.
If you're using MT4.3x with the Entry Asset Manager in the sidebar of the composition screen and use it to attach(rather than insert) assets, this is going to get even more complicated, because there's no way to distinguish between assets that were associated with the entry via each manner.
So.
If you absolutely need the returned asset to be predictable, you'll need to actually distinguish it from the group in some way. There's this suggestion to tag the asset with "#first" or something similar. It's not great, but you'll at least know what you're getting(assuming you only tag one asset per entry as such). If you've got custom fields available, you might see if it makes more sense to create a separate "featured/thumbnail image" asset field that it would go into so that you could explicitly test for it. It'll ultimately depend some upon why you're wanting to extract this particular asset.