Skip to main content
A
Arthur1-Visitor
1-Visitor
December 13, 2017
Solved

Using mapkeys in VB api

  • December 13, 2017
  • 1 reply
  • 5095 views

Hi all,

 

Is it possible to control a mapkey (like modelcheck and checkin) by VB api. My idea is to make a buttom in excel that executes the mapkeys. In the VB user guide from PTC there is an example but I can't figure it out. If I follow the instructions I get an error. VB doesn't recognize the @ and ~

This is the part out of the VB user guide

 

Method Introduced:
IpfcBaseSession.RunMacro()
The method pfcSession.BaseSession.RunMacro runs a macro string. A VB API macro string is equivalent to a
Creo Parametric mapkey minus the key sequence and the mapkey name. To generate a macro string, create a
mapkey in Creo Parametric. Refer to the Creo Parametric online help for more information about creating a
mapkey.
Copy the Value of the generated mapkey Option from the Tools Options dialog box. An example Value is as
follows:
$F2 @MAPKEY_LABELtest;
~ Activate `main_dlg_cur` `ProCmdModelNew.file`;
~ Activate `new` `OK`;
The key sequence is $F2. The mapkey name is @MAPKEY_LABELtest. The remainder of the string following the
first semicolon is the macro string that should be passed to the method pfcSession.BaseSession.RunMacro.
In this case, it is as follows:
~ Activate `main_dlg_cur` `ProCmdModelNew.file`;
~ Activate `new` `OK`;
Note
Creating or editing the macro string manually is not supported as the mapkeys are not a supported scripting
language. The syntax is not defined for users and is not guaranteed to remain constant across different
datecodes of Creo Parametric.
Macros are executed from synchronous mode only when control returns to Creo Parametric from the VB API
program. Macros are stored in reverse order (last in, first out).
Macros are executed as soon as they are registered. Macros are run in the same order that they are saved.

 

Looking forward for a reply 🙂

Best answer by csabakovacs

Hi!

 

You are using the interface by itself if you do this:

IpfcBaseSession.RunMacro ("~Command 'ProCmdViewDefault';")

There is an interface called IpfcBaseSession.
Your session variable is using this interface. So you should call her/his/its appropriate function.

session.RunMacro ("~Command 'ProCmdViewDefault';")

This session was built in the background for you by asyncconnection, it is much more than IpfcBaseSession.

Why is this hassle necessary?

Because the interface is only a list of functions that the interface's implementor must provide.

 

Silly example:

We define an "Multi2Interface" for multiplying by two.

virtual double multi2(double var1) = 0;

 

Implementor1, says that he is capable of implementing it:

virtual double Implementor1::multi2(double var1) override{

return var1+var1;

}

 

Implementor2, says that Implementor1's solution is bad, and says that he can do a better job:

virtual double Implementor2::multi2(double var1) override{

return var1*2;

}

In this case there's no such thing as Mutli2Interface per se. You interact with objects who camouflage them as Mutli2Interface, but truly, they are much more than that and they have their own little ways of implementing the requested function.

 

Story-driven explanation:

Because most of the time frameworks and APIs hide the implementors completely from your eyes(wisely), this is why interfaces can seem strange at first.

I personally like to think of interfaces as "24/7 support hotlines".

The person who sits there implements the interface "support", he's doing it from Paris, and he is really nice with everyone, even though he lost his wife in a car accident two years ago.

If he goes away, or ends his workday, the next implementor will be a young lady from Hague, who is a bit harsh, but nobody knows that she reads stories for blind children on her weekends.

And so on, and so on.

So for us, it doesn't matter as long as they can answer the phone and help.

Also, because the customer only knows the "interface" he will dial the central number and the company will deal with directing his call to the next implementor.

Just imagine: You bought an HP notebook, and from then on, whenever they hire a customer support guy/girl on planet Earth, they will email you his/her contact number. This would quickly generate a new golden era of corporate spam and mail garbage.

 

If I misinterpreted your question, please feel free to clarify it, also Im not a big VB buff!

 

Cheers,

csaba

 

1 reply

D
dschenken1-Visitor
1-Visitor
December 13, 2017

The @ is the label introducer of the mapkey and won't be in the VB program; neither will anything else on the same line as the "@" character. Also - the mapkey components will be in a STRING variable in VB, so there isn't anything for VB to recognize. The STRING will be passed as an argument by VB to Creo.

    A
    Arthur1-VisitorAuthor
    1-Visitor
    January 19, 2018

    Im working on the mapkeys again, but i keep getting the error: object required (on the line of runmacro) This is what I did:

     

    Dim asyncConnection As IpfcAsyncConnection
    Dim cAC As CCpfcAsyncConnection
    Dim session As IpfcBaseSession
    Dim model1 As IpfcModel
    Dim RunMacro As String
    Dim Command As String
    Dim ProCmdViewDefault As String

    Set cAC = New CCpfcAsyncConnection
    Set asyncConnection = cAC.Connect(dbnull, dbnull, dbnull, dbnull)
    Set session = asyncConnection.session
    Set model1 = session.GetModel(Range("{namehere}"), EpfcMDL_ASSEMBLY)

    IpfcBaseSession.RunMacro ("~Command 'ProCmdViewDefault';")   <-here is the error Object Required

    End Sub

     

    Can you see what goes wrong?

    C
    csabakovacs1-VisitorAnswer
    1-Visitor
    January 20, 2018

    Hi!

     

    You are using the interface by itself if you do this:

    IpfcBaseSession.RunMacro ("~Command 'ProCmdViewDefault';")

    There is an interface called IpfcBaseSession.
    Your session variable is using this interface. So you should call her/his/its appropriate function.

    session.RunMacro ("~Command 'ProCmdViewDefault';")

    This session was built in the background for you by asyncconnection, it is much more than IpfcBaseSession.

    Why is this hassle necessary?

    Because the interface is only a list of functions that the interface's implementor must provide.

     

    Silly example:

    We define an "Multi2Interface" for multiplying by two.

    virtual double multi2(double var1) = 0;

     

    Implementor1, says that he is capable of implementing it:

    virtual double Implementor1::multi2(double var1) override{

    return var1+var1;

    }

     

    Implementor2, says that Implementor1's solution is bad, and says that he can do a better job:

    virtual double Implementor2::multi2(double var1) override{

    return var1*2;

    }

    In this case there's no such thing as Mutli2Interface per se. You interact with objects who camouflage them as Mutli2Interface, but truly, they are much more than that and they have their own little ways of implementing the requested function.

     

    Story-driven explanation:

    Because most of the time frameworks and APIs hide the implementors completely from your eyes(wisely), this is why interfaces can seem strange at first.

    I personally like to think of interfaces as "24/7 support hotlines".

    The person who sits there implements the interface "support", he's doing it from Paris, and he is really nice with everyone, even though he lost his wife in a car accident two years ago.

    If he goes away, or ends his workday, the next implementor will be a young lady from Hague, who is a bit harsh, but nobody knows that she reads stories for blind children on her weekends.

    And so on, and so on.

    So for us, it doesn't matter as long as they can answer the phone and help.

    Also, because the customer only knows the "interface" he will dial the central number and the company will deal with directing his call to the next implementor.

    Just imagine: You bought an HP notebook, and from then on, whenever they hire a customer support guy/girl on planet Earth, they will email you his/her contact number. This would quickly generate a new golden era of corporate spam and mail garbage.

     

    If I misinterpreted your question, please feel free to clarify it, also Im not a big VB buff!

     

    Cheers,

    csaba

     

      Terms & ConditionsCookie settingsAccessibility statement