Hi hetshjd,

I got to messing around with this and I'm just as confused as you are. The FirstCell property appears to return a cell object, but it doesn't seem to be a valid object. None of the properties seem to work, including CellColNum. If you try the NextCell property to step across the columns, it continues to return additional cell objects that behave the same.

For example, here's some code I ran, where InTextObj is a subcolumn:

cell = tl.obj.InTextObj.FirstCell;

i = 0;

while(typeof(cell)!= "undefined" && i < 1000)

{

    i++;

    cell = cell.NextCellInRow;

}

alert(i);

...that loop runs straight to 1000

It is interesting that this property appears valid with FrameScript. If I insert a table on the first page of a blank FrameMaker 10 document, and click in the paragraph containing the table anchor, I can run this:

Set oPgf = TextSelection.Begin.Object;

Set oSubCol = oPgf.InTextObj;

Set oCell = oSubCol.FirstCell;

oCell is a valid object; I can query its properties, display its text, etc. However, if the table has a title, the oCell object will actually be the "cell" containing the table title (which is strange).

I don't think the FirstCell property of the SubCol is what you want to use any way. Why not just start with the table object itself and navigate through the cells? Here is how it would be in FrameScript with the selected table, but you can adapt this to ExtendScript:

Set oDoc = ActiveDoc;

Set oTbl = oDoc.SelectedTbl;

Set oCell = oTbl.FirstRowInTbl.FirstCellInRow;

Loop While(oCell)

  // See if the cell contains an anchored frame.

  Get TextList InObject(oCell.FirstPgf) FrameAnchor NewVar(tTextList);

  If tTextList.Count > 0

    // Do something here.

  EndIf

  Set oCell = oCell.NextCellInTbl;

EndLoop

Or, if you want to start with a graphic object, do something like this.

// Get the anchored frame containing the graphic.

Set oAFrame = oGraphic.FrameParent;

// See if the anchored frame is in table cell.

If oAFrame.TextLoc.InTextObj.ObjectName = 'Cell'

  Set oCell = oAFrame.TextLoc.InTextObj;

  // Do something here.

EndIf

Rick Quatro

Hi bjoern,

If you want to iterate based on graphics, perhaps you might consider a different approach that doesn't involve the FirstCell property. I think that the CellColNum property is OK... it's the FirstCell property that isn't working or we just don't understand how it works.

Here is a little function I ran to verify that CellColNum does work OK, as long as the cell object is valid. I don't know if this methodology will work in your case, but perhaps it will give you some ideas.

function graphicTableTest()

{

    var doc = app.ActiveDoc;

    var graphic = doc.FirstGraphicInDoc;

    //iterate through all the graphics in the doc

    while(typeof(graphic)!="undefined")

    {

        //for this test, we only care about imported files

        if(graphic.type == Constants.FO_Inset)

        {

            //get the frame parent. If it's an anchored frame, then we want to

            //find out if it's in a table cell or not.

            var aframe = graphic.FrameParent;

            if(aframe.type == Constants.FO_AFrame)

            {

                //get the InTextObj of the paragraph that contains the frame anchor

                var subcol = aframe.TextLoc.obj.InTextObj;

                //if it is a table cell, report the column

                if(subcol.type == Constants.FO_Cell)

                {

                    alert("Graphic '" + graphic.InsetFile + "' is in a table, column " + subcol.CellColNum);

                }

                //otherwise, just report

                else

                {

                    alert("Graphic '" + graphic.InsetFile + "' is not in a table");

                }

            }

        }

        graphic = graphic.NextGraphicInDoc;

    }

}

Russ

Hi bjoern,

For future reference, table cells seem to be some kind of individual text frames within FM, at least as far as internal processing. They behave like text frames, in that movement between them is clunky, they cannot break across pages, etc. So, from a scripting perspective, I think it's common for a property to return a cell object even when you are expecting a text frame, because that's apparently how the table model behaves. Note that much of this is speculation... I didn't write the FM code

Russ