Update – this is the pre-Commanding perspective. In the Commanding paradigm, everything changes.
Event handling logic should ideally be in VM, but VM source code should not mention view objects. See post on model depending on view.
Many xaml developers put event handlers in the code behind the xaml. This is the “lazy” alternative. The code behind is an integral part of the view layer IMO. Its source code mentions numerous view objects.
Code behind also makes liberal use of vm objects (V is over VM). Therefore this class is the perfect melting pot of V and VM. Event handlers and other glue logic can be implemented more easily in code behind than elsewhere.
However, what is too easy is often too easy to be good. Throwing every bit of glue logic into one big class is poor modularization, poor separation of concern, poor layering. As an alternative, it’s probably wise to
move as many event handlers as possible out of code behind into the VM, esp if the handler action affects only the VM.
(Consider also RequerySuggested)
Q: what is a command in wpf?
Best answer is found in the ICommand interface — a command Instance must offer
1) an Execute() method,
2) a capability-query method CanExecute(). It’s also a status-query method.
3) an event notification scheme, in the form of an event-pseudo-field CanExecuteChanged.
Today let’s focus on 3). I believe this event enables the infrastructure to adjust the appearance of the buttons/menus linked to the command
3 describes 2; 2 describes 1.
I say CanExecuteChanged is a “scheme” because the underlying plumbing is non-trivial to a java/c++ guy, but plain vanilla to a c# guy. To understand this scheme, we must first get a good grip on event-pseudo-field — a bunch of callback functors. See http://bigblog.tanbin.com/2011/09/an-event-pseudo-field-wrapper-over.html.
In the CanExecuteChanged context, when the command’s status switches between Enabled/Disabled or between CanExecute and CannotExecute, this event is raised. An (ordered) list of callbacks get invoked.
Each callback holds 2 pointers, one referencing a callback method, the other referencing its host object. Some people say …
Each callback holds 2 pointers, one referencing a Receiver object, the other referencing a method therein.
One of the things each callback does is to query the command instance via CanExecute(). Therefore, the CanExecuteChanged event is an invitation to “call me for my current status”. Command is a young princess with an army of suitors. They want to know when she’s available for dating. Once a while she sends an open invitation to “call my hotline to ask for my availability” — the princess has a dedicated hotline (CanExecute) to answer that query.
Let me rephrase my last question at Newark. Say our IBM position has current market value of $1m. We want to know the likelihood of losing more than 100k in the next 2 weeks. We can use IBM stock volatility stats to compute the likelihood to be… say 5.5%. Meaning we have a 5.5% chance of losing $100k or more in 2 weeks.
Now the portfolio holds SUN stocks too. Current MV = 1m of IBM + 2m of SUN = 3m. What's the likelihood of losing $300k+?
First assume SUN and IBM are unrelated. The volatility of the portfolio can be computed based on the 2 volatility stats. We can then derive the likelihood of losing $300k+ as … say, 6%. We have a 6% chance of losing 300k ore more in the next 10 days.
In reality IBM and SUN stocks are correlated. I guess portfolio volatility can be adjusted based on the covariance.
Option valuation volatility is very similar to stocks, i guess? Reason — Probability distribution curve is very similar?
A real, practical challenge in a low-latency, market-data system is to quickly find out “What’s the system doing”. Log files usually have a lot of details, but we also want to know what files/sockets our process is accessing, what kind of data it is reading and writing.
truss -s or -r can reveal actual data transferred(??)
if write() syscall is stuck, then perhaps disk is full.
lsof reads /proc to get open sockets/files
— based on http://www.ikriv.com/en/prog/info/dotnet/Delegates.html —
All events (Field-like or not) always support 2 operations += and -=. You can call them sub/unsub or add/remove.
An event is always a non-static Member of a class. IF compiler accepts your event as a field-like event, then it will accept 2 other operations on it
a) MyEvent != null or == null
Internally, these were translated to refer to the hidden private Dlg field generated for every event.
Now, a couple of implications
! subclass can’t use (a) or (b) since the hidden field is private
! You may see (a/b) quite often, but if your event is not field-like, they won’t compile.
* annotations? I don’t know why so often asked
* concurrent data structures
* thread pool
* deadlock prevention
* deadlock investigation
* wait-notify, synchronized
* dependency injection. I don’t know why so often asked
* garbage collection
* serialization, externalization(??), probably needed for stream messaging
* deep copy — needed for serialization and cloning
timeframe: age 36-38
reference group: not locals, but overseas J developers, mostly from India…
Context: prod support on a trading system; When CV is on job sites, when assessed in an interview…
–perceived weakness? 3pr?
understanding complex legacy code