wpf triggers, first lesson

I believe
– property triggers — live inside a style including embedded control template
– data triggers — live inside 1) data templates 2) styles, or a 3) control template embedded in a Style.
( Note data template only accepts data triggers, not property triggers.  See http://stackoverflow.com/questions/17598200/datatrigger-binding-in-wpf-style )

Triggers are predominantly created in xaml. It’s possible to do it in c#, but rare.

Triggers are all about Visual-effects. All these triggers modify the properties of visuals.  PTriggers watch properties; DTriggers watch data; ETriggers watch …

Most common trigger is the property trigger. 2 other common types are Data trigger and Event trigger.

It’s best to internalize one simple property-trigger usage, before looking at advanced triggers. As seen below (example from [[wpf  succinctly]]), you can have 2 triggers on a visual. The 2 triggers can hit the same visual Property like the background color, but only one trigger will fire.

Different aspects (properties) of the visual can be managed through different setters within a Singel trigger. Each setter sets one (depedency) property to control one aspect.




Fwd: design a finite state machine for a FIX engine

We need a cache (OMS/EMS?) of all the pending orders we created. All from-exchange FIX messages must match one of the pending orders. Once matched, we examine its current state.

If the message is belated, then we must reject it (informing all parties involved).

If the message is delivered out of sequence and too early, then we must keep it on hand. (a 2nd cache)

If the message is for immediate consumption, then consume.


…the FSM (finite state machine) in FIX is about state transition and should be pertinent to all state machines. Basically, it goes from pending new to new to fill or canceled. From canceled, it cannot go back to new or fill etc.



treat IRS floating cashflow "stream" as a commodity

In FX, it’s extremely useful to think of first currency as some kind of commodity like silver… Similarly, in IRS, it’s useful to treat the floating Income stream as a commodity (like silver).

You as the IR “Swap buyer” agrees to pay a fixed price in fixed installments. In exchange you receive something of changing value — whose market value changes daily. Suppose we enter a vanilla IRS to receive floating. When we put down the phone with counter-party, we have agreed to pay a fixed (for eg.) 3.4% price for a “silver” in the form of a stream of floating coupons. This is a bit similar to buying an annuity.

The 3.4% fixed rate is like an execution price on the exchange. Next hour (day), the same silver could fetch more, so another buyer would execute the trade at a higher price, like 3.42%, so my existing position would have a positive PnL. This simplified view assumes a null discount rate of 0 (or equivalently, a discount factor of 1.0).

The changing market value of the “silver” we bought is tied to Libor. We “long” for Libor to rise –We are long Libor, as we are long silver.

On the other hand, if you are a dealer selling IRS, you are short Libor as you are short silver.

By comparison, if you write put/call contracts, you are short volatility. Intuitively, consider OTM — lower vol reduces the chance of option finishing ITM, so you are more likely to pocket the premium. As a fire insurer, lower vol means lower chance of fire disaster — good for you the insurer.

I hope this helps beginners get a “feel” of the terminology in IRS.

tibrv supports no rollback – non-transactional transport

Non-transactional “transports” such as TIBCO Rendezvous Certified and socket do not allow for message rollback so delivery is not guaranteed.  Non-transactional transports can be problematic because the operation is committed to the transport immediately after a get or put occurs, rather than after you finish further processing and issue a Commit command.

JMS does support transactional “transport”, so you can “peek” at a message before issuing a Commit command to physically remove it from the queue.


Fwd: jms connection sharing

Reading [[java message service]] I realized that if a topic has 1000 concurrent client connections (a few thousands achievable by 2000 technology), we could have several thousand concurrent applications receiving a new message. JMS Connection sharing dramatically increase throughput and bandwidth.

Many middleware products support jms connection sharing.