Increase The Potential of GenerativeComponents with Key-ins

In MicroStation or in any other PowerPlatform tools(OpenBuildings, OpenRoads, OpenBridge) almost all functionalities has a Key-in. Key-ins allows us to use lots of functionalities with simple commands.  In GenerativeComponents, there is an in-built function KeyIn() that allows us to execute any Key-ins.  Key-ins could be especially helpful to use any functionalities that are not available in GC.  Sometimes this approach requires less effort than taking the programmatic approach.

Find out more at https://www.virtuosity.com/increase-the-potential-of-generativecomponents-with-key-ins/

transaction 8 script 'Run Key-in script'
{
    KeyIn('macro play Fill Region_OP_K'); // Runs a macro for initial dialog settings
    for (int i = 0; i < RandomPoints.Count; ++i)
    {
        KeyIn('CO='+ Random(255));  // set active colors to a random color
        KeyIn('create region flood;T, point absolute ' + RandomPoints[i].X + ',' + RandomPoints[i].Y + ',' + RandomPoints[i].Z + '|2'); // create region based on GC points
    }
}

Let us know if you find out new Keyins that can be implemented in GenerativeComponent.

Thanks,

Anik

  • Nice one, Anik!

    "The biggest drawback of this approach is that we cannot go back to the previous state once the key-ins are executed. If any geometries are created they need to be deleted manually."

    Not sure, but have you tried using Mstn's Set Mark tool? This is normally used to set the Undo Buffer, before a large 'transaction' in Mstn. I wonder if the tool could be used to generate a list of ElementIDs that can then be used by GC to find the raw elements generated by the key-ins for deletion. This would be good as you will want the option to automatically replace the elements associated with a particular GC transaction, the next time the GC script is run. I understand that Mstn's Design History tools are quite sophisticated and it might be the better tool to link GC transactions to Mstn transactions (which normally lacks any 'history').

    In fact, the DH tool already has HISTORY COMMIT, HISTORY RESTORE and HISTORY MANAGE DELETE  key-ins. So, it should be possible for the GC script to include some text to help link the Mstn elements to GC at the transaction level.

    I think that users will also want to attach info like Item Types and Named Group info so that the generated elements can be intelligently collated for further processing. In the case of Item Types, I think that there is a GC node for this, so this would be a key-in? AFAIK, there is no GC node for attaching Named Group info, so this would be reliant on Mstn key-in availability. How macro recording friendly is GC? Even Mstn isn't very good here, where a lot of Mstn interaction is not recordable by either BMR or the VBA recorder. Apparently the code has to written specifically to allow this.

    What would be good is a means to enumerate / extract an ElementID list of elements from Mstn's Design History or the Set Mark tool as a Selection Set to feed GC transactions, that may include Mstn commands via key-ins.

    I think that GC can help raise productivity for a lot of use cases. It's not all gimmickery, and project managers hate to see their CAD jockeys tinkering on tools instead of doing fee-paying work (even if it takes longer without the (promised, which may never come in time) automation tool), So, having a fast visual programming tool like GC on Mstn etc will open a lot of doors... after the initial form-finding stage where GC is traditionally used.

    For example, it is good to see that GC's replication type functionality can already be brought to bear...

    "KeyIn('create region flood;T, point absolute ' + RandomPoints[i].X + ',' + RandomPoints[i].Y + ',' + RandomPoints[i].Z + '|2'); // create region based on GC points"

    A lot more compact than the equivalent VBA code.

    Having said that, VBA is used on a lot of Bentley apps, so interacting with them will be key. Hopefully, the low-level plumbing is already in place thanks to GC's dotNET roots? Some VBA/COM libraries have been around for awhile and quite impressive. OpenSTAAD, Prostructures, OBD's old TFCOM, Maxsurf etc etc. Some of these verticals might end up with GC nodes in the future, but key-in access to the VBA functionality looks like a good way to bridge the gap and maximise return on sunk investment costs across 'open' disciplines.

    What would also be good is a review of what Mstn/GC tools can be used to 'listen' to or extract info from the Mstn elements being processed. As you can see from the AskInga blog, leveraging scripting has long highlighted the need to be able to extract quite a lot of info. Being able to extract info from the message line, debugger, the old tcb using Calculat.ma; setting item toolsettingsexpand keyin etc will be a key building / stumbling block for any script. It would be good to understand how to do this in new gen CE.

  • I haven't tried this, but Mstn's Advanced Search tool should be amenable to keyins.

    I can see this kind of heavy lifting being faster in Mstn, using the native code. rather than in GC, with its managed code and graph IDE overheads..?

    1. User uses Advanced Search to gather elements per criteria.

    2. Export to separate 'GC working model' (not sure what the key-ins here would be. It might be buried in the PokeIt VBA somewhere)

    2. Records keyins and saves as VBA

    3. User runs GC script that calls VBA.

    4. There will need to be some way notifiying GC that the VBA is done.

    5. GC starts processing the elements exported in the 'GC working model'.

    6. ...

  • Hi Dominic,

    These are really good suggestions and resources. I will carry out some more investigation.