RoutedEventArgs – basics

http://msdn.microsoft.com/en-us/library/system.windows.routedeventargs.aspx

The 4 properties of RoutedEventArgs are key. You may want to compare with the PropertyChangeEvent in swing…

– Halted property – writable
– OriginalSource is usually less useful than Source
– RoutedEvent … is the actual event?

In Silverlight, only OriginalSource is available 😦

Advertisements

dotnet unmanaged RESOURCES, learning notes

(Many open questions below are a bit arcane and may not be relevant to IV or projects.)

I feel “managed” means “automatically-released”. In that case, most dotnet Objects qualify as managed “Resources”. Any time you need Dispose() in your CLASS, that’s a telltale sign of unmanaged resources.

“Resource” is a rather abstract term, best understood by example[1]. In my mind, a resource is some runtime object(s) needed by our App, something constructed and configured. Like a natural resource it is scarce, shared and rationed. Like a library book, there’s usually an acquisition “protocol”, and a return protocol.

[1] As a crude example, what’s a city and what’s not a city? Best learn by example.

http://stackoverflow.com/questions/13786570/determine-managed-vs-unmanaged-resources has some interesting comments.

–Unmanaged resource and … IntPtr + handle ?
What’s an IntPtr? Basically a struct that represents a native void pointer (or a native handle) —
http://stackoverflow.com/questions/1148177/just-what-is-an-intptr-exactly Many unmanaged “resources” are accessed via IntPtr.

–Unmanaged resource and unsafe code?

–Unmanaged resoruce and p/invoke?

–Unmanaged resource and … win32 + COM?

–some managed resources
filestream is a MR. It contains a native file handle, which is UR. It’s IntPtr, but not a integer-based file descriptor as in C/python. See MSDN.

A socket object is a MR. It contains a socket handle, which is UR and IntPtr

A DB connection is probably UR.

who generates the local proxy for the remote

In any distributed-OO infrastructure (ejb, rmi, wcf, remoting…), someone needs to generate a proxy class based on the server-side
API. If you aren’t paying attention, you will not notice where, when and how exactly this is generated. But this is a crucial detail
not to be missed.

There’s a bit of ambiguity over 2 related concepts — Instantiating a proxy instance (at run-time) vs Generating a proxy class
source code before compiling.

(I like to say “client-side proxy” but the adjective is superfluous. )

— WCF —
Usually i generate the “service reference” from a wsdl or the service endpoint URL.

2 frontiers between swing/OS

Between the swing layer and OS layer, there are 2 interactions “channels”. In other words, swing relies on 2 services provided by
the “hotel service desk” that’s the OS.

A: upward -> screen update, targetting a particular screen object
B: downward -> keyboard/mouse events when user interacts with a screen object

In both domains, data/events are bound to individual screen/visual objects. Eech screen object maps to one (or more) swing object + one (or more) native object “protected” by the OS. Remember OS is the wrapper layer on top of hardware, and all access to hardware must go through the OS.

You encounter low-level details when digging into either of the 2 domains
A: painting, java 2D, UI delegates
B: event pumping, low-level vs semantic events.

suggest(hint) a GC run – CLR ^ JVM

Java’s gc() method is a suggestion/plea to JVM at run-time. (There’s no way to force an immediate GC cycle. I often call gc() some 4000 times in a few loops to coax the GC to start.)

CLR Collect() method with Optimized mode is exactly the same.

CLR Collect() method with Forced mode would force an immediate collection. No such feature in JVM.

All of these techniques are discouraged. When are they justified?

OneWayToSource, briefly

Logically, there are 2 sides to a (logical) binding — Source property and Target property. Both must be properties (not fields) of some class. Target must be a dependency property, not a plain property.

Behind the scene, there is a Binding object, with a Source field (not to be confused with the “source” property) and a Path field (Better rename to “PropertyNameInSourceObject”). You inject Binding object into the Target visual control. Once injected, the target visual is wired up to the source property, via the binding.

I feel target is usually a visual. Source property often isn’t a visual — it could be a plain property in a POCO object. When source property gets edited, WPF engine would somehow update the visual. That’s the plain vanilla OneWay update mode.

When used as a Target visual, some visuals default to 2-way update, like TextBox. Other visuals default to one-way update i.e. source to target.

OneWayToSource is a special mode. One reason you may need it — when exactly one of the 2 sides is a dependency property. By WPF policy that side must be the Target, whereas the non-dependency side will be Source. If you need to update the non-dependency side, you can use OneWayToSource. Imagine the non-dependency side could be a POCO object with a plain property, but you need to update it when the textbox gets edits. In summary, system automatically updates the non-dependency property from a visual control on screen.

When both source Obj and target Obj are visuals, we can often make do without data binding — use event instead.