With the new 3.0.0 version of Fabric JS we have to apply requestRenderAll() in order to see the handles when one objects is active.
My question is:
does requestRenderAll() replace some kind renderAll() method. Are there any important differences between both methods. When we have to use each of them and do we have to use them together?
I now that Canvas.renderall is a sync operation and requestRenderAll() method is regarded as improvemnt. But do we still need renderAll() and if "yes", when. And also - is renderAll() going to be deprecated in near future?
Related
I'm currently implementing a way to manage execution of a test in robot framework using using tkinter and the builtin listeners.
I was able to make a Pause/Resume system relatively easily but I'm unable to make a Stop system.
In the RobotFramework UserGuide there is an example to insert keywords in test cases like this:
ROBOT_LISTENER_API_VERSION = 3
def start_test(test, result):
test.keywords.create(name='Log', args=['Keyword added by listener!'])
The issue is, that this is deprecated and doesn't work. I have the following error when trying to use this :
UserWarning: 'keywords' attribute is read-only and deprecated since Robot Framework 4.0. Use 'body', 'setup' or 'teardown' instead.
I don't know how to use Body setup or teardown to do what I want and I was unable to found any example similar to the deprecated one
Apparently I needed to ask the solution to find one by myself
So I just needed to make something like this :
test.setup.config(name="Fatal Error", args=["Force Quit"])
or
test.teardown.config(name="Fatal Error", args=["Force Quit"])
I'm using MOQ to mock a durable entity, but seeing this error:
Extension methods (here: DurableContextExtensions.CallEntityAsync) may
not be used in setup / verification expressions.
Here's how I'm doing it:
mockContext.Setup(e => e.CallEntityAsync<List<string>>(It.IsAny<EntityId>(), "EntityFunctionName"))
.ReturnsAsync(new List<string>() {"one", "two", "three" });
Is there any way I can mock calls to my durable entity?
As of Durable Functions 2.3.0, all of our extension methods are now baked directly into the interface, so it should be substantially easier to use Moq with all of these methods and their overloads.
Edit: The previous answer below covers why the previous extension method approach made this dificult.
So this is an inherent limitation of how Moq works with extension methods.
Unfortunately, in the meantime, you will need to find out the core method on IDurableOrchestrationContext that is called by the extension method that provides the overload you are using.
For instance, in this case, DurableContextExtension.CallEntityAsync(EntityId entityId, string operationName) is calling IDurableOrchestrationContext.CallEntityAsync(EntityId entityId, string operationName, object operationInput), with a value of null for operationInput. You can find this by looking at the source code.
This is obviously not an ideal way for mocking, as without looking at our source code, it is difficult to tell if you are attempting to mock an extension method or not at the time of writing your tests. You can use a Moq analyzer to at least catch these errors at compile time, but it still won't tell you which method signature to mock to get rid of the error.
We are proposing getting rid of extension methods altogether for this reason, and just putting all of these signature overloads as interface methods directly, so you can mock any of them safely. This is a breaking change for customers who write their tests by directly implementing the interface, so we are trying to keep this change out of a patch release, and only in a minor release with clear guidance of how to fix those broken by these changes. Look for this to be fixed in version 2.3.0 of the extension.
We have a type named OldThing which we want to deprecate over time.
We need an NDepend query/rule that says from this point on, don't add any more calls to 'OldThing'.
We currently use NDepend and have a baseline build for checking things like don't make large methods even larger.
So, we'd like to use NDepend to track any additional calls made to OldThing. I have the following CQL query:
// <Name>Don't use OldThing going forwards</Name>
warnif count > 0
let containsMethods = Methods.WithFullNameIn(
"MyNamespace.OldType.get_Foo()",
"MyNamespace.OldType.get_Bar()")
from m in Application.Methods.UsingAny(containsMethods)
where m.IsUsedRecently()
select m
... the trouble is, it doesn't seem to work; it doesn't find any new calls.
Is there a better way of doing this in NDepend (perhaps by utilising trend metrics)?
You don't need where m.IsUsedRecently(), this is only for third-party method calls.
Then you need to double check that the let expression is matching the proper deprecated methods (you could also match them all at once by using the ObsoleteAttribute).
Finally you should make this rule critical and it should work :)
When using semantic versioning, can a function be removed from a project without a major version bump if that function isn't intended to be part of the public API?
Ref: http://semver.org/
Major version increment comes when you make incompatible API changes. If your function do not affect the API, then you shouldn't go for it.
If the function was ever a part of the public API, intentionally or not, then removing it is a breaking change and thus a major version increment.
The method CGWaitForScreenRefreshRects is deprecated in Mac OS X v10.8.
The alternative method mentioned in class reference(CGRegisterScreenRefreshCallback) is also deprecated.
What should I use to get the screen updates in 10.8?
Look at CGDisplayStream.h. It is new set of APIs added to 10.8. Their is rare documentation on it though.