No not really you don't have to change anything in MainForm or FormB,
they are good. There is nothing wrong with FormB in my perspective
either.  I was referring to FormD which will be dependent if it
references anything in FormB (Refer to my example below for what I
mean)

I agree

It appears we both are on the same page here

I somewhat disagree

The following should explain what I visualize when I say FormB should
retrieve information from FormD

To simplify, let's consider a realistic example and for sake of
example assume the hierarchy is as follows. Please note that the code
below is not compiled and it is for illustration only (typewritten in
notepad)

UI Hierarchy
=========
MainForm

        |
       FormOrder (MdiChild)(FormB per our example) (Populates
IPoOrder)
                      |

                     FormOrderItems (Modal Form) (FormC per our
example) (Populates IPoItemCol)
                             |

                             FormOrderLineItem (Modal Form) (FormD per
our example)  (Populates IPoItem)

In the below code FormOrder creates an instance of the FormOrderItems
and ultimately gets an instance of order collection. In addition,
FormOrder of course will have reference to other controls may be to
Order Header related information (IPoOrder)

//Code Snippet in FormOrder
private void buttonEnterLineItems_Click(object sender, EventArgs e)
{
  EnterOrderLines();
}

private void EnterOrderLines()
{
   FormOrderItems objFormOrderItems      = new FormOrderItems();
   if (objFormOrderItems.ShowDialog(this) == DialogResult.OK)
   {
      //if all is *well* objFormOrderItems would retrieve an instance
of IPoItemCol
      this.PoOrder.PoItemCol = objFormOrderItems.GetOrderCollections;
      if ((this.PoOrder.PoItemCol == null) ||
(this.PoOrder.PoItemCol.Count <= 0))
         throw new EOrderException(....) //exception to business
rules...
   }
}

The FormOrderItems creates (or reuses) an instance of FormOrderLineItem
for every new item in the order. FormOrderItems is responsible for
populating the Orderlines Collection instance with instances of
orderline.

//Code in FormOrderItems
private void buttonNewItem_Click(object sender, EventArgs e)
{
  AddLineItem();
}

private void AddLineItem()
{
    FormOrderLineItem objFormOrderLineItem = new FormOrderLineItem();
    if objFormOrderLineItem.ShowDialog(this) == DialogResult.OK)
    {
     //if all is well objFormOrderLineItem would return a valid IPoItem
     IPoItem PoItem = objFormOrderLineItem.GetLineItem;
    If (PoItem == null)
       throw new EOrderLineException(...); //Exception
    this.PoItemCol.Add(POItem);

    }

}

Apparently notice that OrderLines collection is passed to the
FormOrders. This is what I originally meant when I said the FormB
should retrieve details from FormD.

Also, When I say FormB should retrieve details that also correlates to
this statement "Given its position (and logical functionality) in the
hierarchy FormD should have no idea who its users are and what there
business are. On the other end all that users (FormB or FormC) of FormD
know in a nut shell is given a set of inputs FormD throws a set of
predefined output or exception to business rules"

This is how I view it:

1.    FormOrderLine (FormD) Item should not know anything about
FormOrderLines (FormC) or FormOrder (FormB)

2.    If FormOrderLine has reference to any of the attributes or events in
the FormOrderLines or FormOrder they are interwoven. Then this isn't
reusable either, think of a generic lookup collection such as customer
lookup. If the Customerlookup subscribes to events or methods specific
to order form (Orders Module) then it is an initiation to coupling. The
customerLookup now is no more a blackbox component, nor can we reuse it
in other modules as efficiently. Given its functionality, let us say we
have to (or forced to) resuse the CustomerLookup in an Invoice Form
(Invoicing Module) we will be tempted to subscribe to events or
delegates in Invoice form aswell in the advert of *reusability*. The
Customerlookup would end up as an interconnected mass of spaghetti over
a couple of iterations.

I hope I have articulated my thoughts in line to your question.

Raaj.