Topic
  • 3 replies
  • Latest Post - ‏2014-06-06T17:26:02Z by gBright
gBright
gBright
7 Posts

Pinned topic Use filter to control the linked objects returned from source in loop (for incoming links to object)

‏2014-04-05T00:30:10Z |

Greetings.
Search of the forum doesn't turn up any answers for this.

I am inside a loop of incoming links from a sourceModule to an object.
I want to apply a filter to the view in the source Module and have the filter control the objects that get returned or used inside the loop.
I want to manipulate the filter in the source module on the fly to control which source objects (othero) get processed

This is the typical boilerplate generated by the traceability wizard ...

    for l in all(o<-linkModName) do {
        otherVersion = sourceVersion l
        otherMod = module(otherVersion)
        if (null otherMod || isDeleted otherMod) continue
        if (!equal(getItem otherMod, (itemFromID limitModules[depth-1]))) continue
        othero = source l
        if (null othero) {
            load(otherVersion,false)
        }
        othero = source l
        if (null othero) continue
        if (isDeleted othero) continue
        doneOne = true
        if (depth == 1) {

            my_stuff(othero)

        }
    }
 

So, is there a particular syntax for the "for" loop or other intervening code that respects the display set or active filter in the source module (otherMod)?
or
inside the loop in "my stuf()f" test each returned "othero" and determine if it was filtered or not?
 

Thanks for any insight.

geoff

  • Pekka_Makinen
    Pekka_Makinen
    26 Posts
    ACCEPTED ANSWER

    Re: Use filter to control the linked objects returned from source in loop (for incoming links to object)

    ‏2014-04-05T09:36:30Z  

    You could use the isVisible or isFiltered functions to check the object display status, see the DXL help for these

    isFiltered object o is accepted in the current filter
    isVisible object o is part of the current display set

  • Pekka_Makinen
    Pekka_Makinen
    26 Posts

    Re: Use filter to control the linked objects returned from source in loop (for incoming links to object)

    ‏2014-04-05T09:36:30Z  

    You could use the isVisible or isFiltered functions to check the object display status, see the DXL help for these

    isFiltered object o is accepted in the current filter
    isVisible object o is part of the current display set

  • llandale
    llandale
    3035 Posts

    Re: Use filter to control the linked objects returned from source in loop (for incoming links to object)

    ‏2014-04-05T20:42:15Z  

    I greatly dislike depending on filters when running DXL.  What I would do is given "othero", I'd check its characteristics to see if I care about it.  So while you can issue a filter:

    • set(attribute "Status" == "Verified")

    I would just check

    • if (othero."Status" != "Verified") then continue

    I notice, though, that your code wants to depend on the filter of the other module, yet you still check for "loading" it; which will load the default view and may not be what you want.

    -Louie

  • gBright
    gBright
    7 Posts

    Re: Use filter to control the linked objects returned from source in loop (for incoming links to object)

    ‏2014-06-06T17:26:02Z  

    Apologies - long time getting back with a response.

    Thanks to Pekka_Makinen.
    "IsFilered" and "isVisible"  are what I was looking for.
    (Sorry I didn't find it myself in the help)

    I do understand Louie's sensitivity to relying on something as whimsical and transitory as a filter to control the loop processing but the selection of objects needs to be, well ... um, filtered 'on the fly' on a dynamic set of conditions - not a static set of attributes and not a static set of attribute values.
    So using the built in filter feature at the source module was the low hanging fruit solution - and it allows me to procrastinate a little longer learning how to create a complicated dialog box.

    And thanks for mentioning that the standard boiler plate code (from the wizard) would load the default view. If the source module is not loaded then the user cannot have created the filter 'on the fly' so the routine should gracefully back out.

    thx