Unity 2 - Why has the BuildUp method changed? - unity-container

I am starting to use Unity 2 , having happily used earlier versions. I notice that the IUnityContainer.BuildUP(object obj) method has been removed. Why has this happened?

It's here, that's for shure. It's just moved to extension methods.
http://msdn.microsoft.com/en-us/library/microsoft.practices.unity.unitycontainerextensions_members(v=PandP.20).aspx
Perhaps you don't have
using Microsoft.Practices.Unity
In some cases you'll have to add it when migrating from unity 1.2
The following overload is replacement for IUnityContainer.BuildUp(object obj)(actualy BuildUp(T obj)) becouse params ResolverOverride[] resolverOverrides are optional
http://msdn.microsoft.com/en-us/library/ff662062(v=PandP.20).aspx, so your code should compile without any changes

Related

FormRun.wait(): method is deprecated, what to use instead?

I am currently working on fixing some BestPractice-Warnings on a bigger project. There i have a few instances where forms are called and are awaited before doing more stuff, this is mostly some dialogs. To await form the following code is used very often:
Object formRun;
//declare args and stuf...
formRun = classfactory.formRunClass(args);
formRun.init();
//call methods on formRun (display,run,etc...)
formRun.wait();
The problem i am facing now is that 'wait()' seems to be deprecated and i don't get how to replace or fix this. I have seen that some devs declared the form as 'Object' to get rid of this warning (didn't work by the way, this will still be detected), but this is a late-bound-call which should also be avoided...
Has anyone else had this issue ? i tried calling this method using the system.reflection namespace but this doesn't look right and is also much more code in x++ than should be needed for such a simple task.
TLDR
I think this is a false positive from the best practice checks. To get rid of the best practice warnings, you can add them to the list of suppressed best practices or add a best practice suppression in code.
Details
In Deprecated APIs (June 2017) it says for the wait method of Object:
Overview
Used to block and wait for an interaction/operation and notify to
unblock.
Reason for deprecation
These calls are deprecated for all objects except formRun and it’s
derivatives.
Migration notes
Calls to these APIs from formRun or it’s derivatives are allowed.
Calls to these APIs from any other object should be removed.
When you do a metadata search for code:"formRun.wait()", you will also get a lot of results (more than 1000 on version 8.0). This is further indication that the method is not deprecated for FormRun.
That said, you may want to take a look at the following link which mentions a formRun.lifecycleHelper() to which event handlers can be added. I haven't personally tried this so far, but it may be applicable to your case.
FormRun.wait, Box and ChangeCompany - a poor cocktail

Kotlin: How are a Delegate's get- and setValue Methods accessed?

I've been wondering how delegated properties ("by"-Keyword) work under-the-hood. I get that by contract the delegate (right side of "by") has to implement a get and setValue(...) method, but how can that be ensured by the compiler and how can those methods be accessed at runtime? My initial thought was that obviously the delegates must me implementing some sort of "SuperDelegate"-Interface, but it appears that is not the case. So the only option left (that I am aware of) would be to use Reflection to access those methods, possibly implemented at a low level inside the language itself. I find that to be somewhat weird, since by my understanding that would be rather inefficient. Also the Reflection API is not even part of the stdlib, which makes it even weirder.
I am assuming that the latter is already (part of) the answer. So let me furthermore ask you the following: Why is there no SuperDelegate-Interface that declare the getter and setter methods that we are forced to use anyway? Wouldn't that be much cleaner?
The following is not essential to the question
The described Interface(s) are even already defined in ReadOnlyProperty and ReadWriteProperty. To decide which one to use could then be made dependable on whether we have a val/var. Or even omit that since calling the setValue Method on val's is being prevented by the compiler and only use the ReadWriteProperty-Interface as the SuperDelegate.
Arguably when requiring a delegate to implement a certain interface the construct would be less flexible. Though that would be assuming that the Class used as a Delegate is possibly unaware of being used as such, which I find to be unlikely given the specific requirements for the necessary methods. And if you still insist, here's a crazy thought: Why not even go as far as to make that class implement the required interface via Extension (I'm aware that's not possible as of now, but heck, why not? Probably there's a good 'why not', please let me know as a side-note).
The delegates convention (getValue + setValue) is implemented at the compiler side and basically none of its resolution logic is executed at runtime: the calls to the corresponding methods of a delegate object are placed directly in the generated bytecode.
Let's take a look at the bytecode generated for a class with a delegated property (you can do that with the bytecode viewing tool built into IntelliJ IDEA):
class C {
val x by lazy { 123 }
}
We can find the following in the generated bytecode:
This is the field of the class C that stores the reference to the delegate object:
// access flags 0x12
private final Lkotlin/Lazy; x$delegate
This is the part of the constructor (<init>) that initialized the delegate field, passing the function to the Lazy constructor:
ALOAD 0
GETSTATIC C$x$2.INSTANCE : LC$x$2;
CHECKCAST kotlin/jvm/functions/Function0
INVOKESTATIC kotlin/LazyKt.lazy (Lkotlin/jvm/functions/Function0;)Lkotlin/Lazy;
PUTFIELD C.x$delegate : Lkotlin/Lazy;
And this is the code of getX():
L0
ALOAD 0
GETFIELD C.x$delegate : Lkotlin/Lazy;
ASTORE 1
ALOAD 0
ASTORE 2
GETSTATIC C.$$delegatedProperties : [Lkotlin/reflect/KProperty;
ICONST_0
AALOAD
ASTORE 3
L1
ALOAD 1
INVOKEINTERFACE kotlin/Lazy.getValue ()Ljava/lang/Object;
L2
CHECKCAST java/lang/Number
INVOKEVIRTUAL java/lang/Number.intValue ()I
IRETURN
You can see the call to the getValue method of Lazy that is placed directly in the bytecode. In fact, the compiler resolves the method with the correct signature for the delegate convention and generates the getter that calls that method.
This convention is not the only one implemented at the compiler side: there are also iterator, compareTo, invoke and the other operators that can be overloaded -- all of them are similar, but the code generation logic for them is simpler than that of delegates.
Note, however, that none of them requires an interface to be implemented: the compareTo operator can be defined for a type not implementing Comparable<T>, and iterator() does not require the type to be an implementation of Iterable<T>, they are anyway resolved at compile-time.
While the interfaces approach could be cleaner than the operators convention, it would allow less flexibility: for example, extension functions could not be used because they cannot be compiled into methods overriding those of an interface.
If you look at the generated Kotlin bytecode, you'll see that a private field is created in the class holding the delegate you're using, and the get and set method for the property just call the corresponding method on that delegate field.
As the class of the delegate is known at compile time, no reflection has to happen, just simple method calls.

"Cannot access a property or method of a null object reference." without any meaningfull stack trace

Regularly during my application run, I get
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at mx.managers::SystemManager/stageEventHandler()[C:\autobuild\3.4.0\frameworks\projects\framework\src\mx\managers\SystemManager.as:5649]
This is the full stack trace. Obviously, I guess there is something wrong, but I can't understand what.
Is there any way for me to find the origin of that bad behaviour ?
EDIT
Having added my SDK sources to my debugger, I can now say precisely which line it is :
private function stageEventHandler(event:Event):void
{
if (event.target is Stage)
mouseCatcher.dispatchEvent(event); // This is line 5649
}
mouseCatcher is indeed null. The current event target is indeed a Stage object, and event type contains the "deactivate" String. As event occurs at application startup (before I try to do any kind of user interaction), I guess it's a kind of initialization bug, but where ? and why ?
Look at the source code, this is always your best option. The 3.4 SDK is open source (datavisualization and the flash player itself aside) and you probably already have the source for it in your FlashBuilder/FlexBuilder install/sdks folder. Use grep or windows grep to find the file in question (or find, whatever floats your boat). Open the SystemManager file and check what's happening at that line, check for calls to the method (if it's public use grep again, if it's private you just need to look within the SystemManager). Try to understand why it gets to this point, as pointed out by some others it's likely a timing related issue where you're trying to access something before it has been assigned, in this case the SystemManager, you probably need to defer whatever action you're taking that is causing the error to a later part of the life-cycle (if you're using initialize event or pre-initialize try on creationComplete instead since that will be dispatched after the createChildren method is called).
Note: Mine is located here
C:\CleanFS\SDKs\flex\3.4.0.9271\frameworks\projects\framework\src\mx\managers
In my copy of SystemManager with the version of the SDK I have that line number doesn't make any sense since it's a block closure not an executable line so you'll have to look at your specific version.
It looks like you are using the Flex 3.4 SDK. Are you listening for the ADDED_TO_STAGE event when the application loads? Or doing anything with the Stage object on load? If so, you might be hitting a bug specific to the 3.4 SDK:
http://bugs.adobe.com/jira/browse/SDK-23332
The most obvious solution is to swap out the 3.4 SDK for a later version (3.4A, 3.5 or 3.6). You can do that here: http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3
All of your code should be backwards compatable with the newer Flex 3 SDKs.

Why did getSite() return a FormlibValidation object

I've installed collective.quickupload on a blank Plone 4.1 site,
and noticed that when you add a quickupload portlet, kss calls for field validation (plone.app.form.kss), getSite function will return a FormlibValidation object, which cause the quickupload vocabularies crash.
The traceback is here: http://pastebin.com/nvwChpZd
My question is:
Is that (getSite function returns a FormlibValidation object) a bug or intended behaviour ?
Solution to fix/work around/make collective.quickupload work ?
getSite() returns the nearest component site (where local utilities can be stored), which really just means whatever was last set with setSite(), which usually happens on traversal.
Most of the time, the only traversal hook that calls setSite() is the one that's triggered when you traverse over the Plone site. But I think the old KSS inline form validation machinery used (uses?) a hack that creates a local component site on the fly (in a view) and sets that as the local site during the remainder of the request so that it can override certain things.
You can disable validation (e.g. disable the relevant KSS file in portal_kss) or fix c.quickupload to check whether the result of getSite() is an ISiteRoot. If it isn't, it should be acquisition-wrapped, so you can do aq_parent(site) (or maybe site.parent) to get the parent in a loop until you find an ISiteRoot.

Flex Compile Time Constants - Timestamp

I'm trying to use Flex Compile Time Constants to include the date and time the SWF was built (source control revision/timestamp such as SVN:Keywords is not sufficient for our needs, we need to know the actual build time, not the commit time).
I've tried using actionscript (like the documentation suggests you should be able to):
-define+=COMPILE::Timestamp,"new Date()"
But this gives "The initializer for a configuration value must be a compile time constant"
I've tried getting it to drop to shell and use the date command (using various single and double quote configurations), for example:
-define+=COMPILE::Timestamp,`date +%Y%m%d%H%M%S`
I can only get it to work with simple strings and simple constant expressions (eg, I can do 4-2 and it'll be 2 at runtime. But I can't get it to do anything whose value wouldn't be explicitly known at the time I declare the define.
Has anyone had any luck with something like this?
I had the same problem and ended up using this blog post as a starting point. Worked really well for me. Just had to update a few bits of the class to flex 4. Pulled the date right out of the complied swf.
The key to your problem is most likely in the following statement by Adobe referring to Compile Time Constants:
The constant can be a Boolean, String, or Number, or an expression that can be evaluated in ActionScript at compile time.
I would assume that the Timestamp is not available at compile time.
However, you may try using a string instead (something like this)
public function GetUnixTime():String{
var myDate:Date = new Date();
var unixTime:Number = Math.round(myDate.getTime()/1000);
return unixTime.toString();
}
Another thought is that you could get the information from the compiled file.
Hope this helps.
After extensive research, I've concluded that this simply isn't doable.
If you don't use FlexBuilder to do your builds you can do it quite easily.
I do something like this with FlexMojos in Maven.
In the relevant config section:
<definesDeclaration>
<property><name>BUILD::buildVersion</name><value>"${project.version}"</value></property>
<property><name>BUILD::buildRevision</name><value>"${buildNumber}"</value></property>
<property><name>BUILD::buildTimestamp</name><value>"${timestamp}"</value></property>
</definesDeclaration>
FlexBuilder pretty much sucks as a build environment for reasons like the one you mention

Resources