JLink - ProE model automatically checked out

DavidRodriguez · ‎Feb 03, 2012

When using J-Link to modify a model in a ProE workspace connected to PDMLink, if the object is not checked then JLink automatically checks out the object without first prompting the me to checkout or download it. Is this the normal behaviour and is there any way to influence it? If I don't use J-Link and repeat the above then PDMLink displayed a checkout conflict dialog box. Below is the the message log info:

Checkout started: testdr_01a.prt.

   Checkout succeeded: testdr_01a.prt. See Event Manager for details.
   Resolution "Check out now" was automatically applied to conflict "The object is re 
 ad only as it is not checked out." for model "testdr_01a.prt".

The object is afterwards checked-out and modified (+ sign). Can anyone offer any insight or help? Would gladly appreciate any assistance.

Regards
David Rodriguez

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

mark_stallard · ‎Feb 03, 2012

Hi David -

I'm surprised to hear about JLink's automatic check-out behavior, but I
have
never actually used it to modify a model.

I do have some experience with verifying the check-out status of a model.
I
currently have code deployed which uses
pfcServer.Server.IsObjectCheckedOut.
Just this morning, I noted my doubts that this method actually works, at
least
on Wildfire 3. I don't know whether PTC has an open bug on
IsObjectCheckedOut.
I encourage you to try it just the same, since it's purpose is obvious and
it
should be useful to you.

If IsObjectCheckedOut doesn't work, I can recommend a hack that works on
WF3
that may also work on WF4 and WF5. The parameter PTC_WM_LOCATION contains
the PDM commonspace pathname for the object in your workspace, provided
that
it's actually in commonspace. Strangely, though, this parameter is defined
only when the model is checked in. If it's in a checked-out state, this
parameter is (I believe) not defined (it if is defined, it contains no
value).

Again, I suggest you try pfcServer.Server.IsObjectCheckedOut to check your
model status. If that doesn't work, write some code to read the parameter
PTC_WM_LOCATION.

|+| M a r k |+|

Mark Stallard
Rapid Response Development
information Solutions
Integrated Defense Systems
Raytheon Company

(business)
+1.978.436.6016
(cell)
+1.617.331.5443
(tie line)
239.6016

-

880 Technology Drive
Billerica, MA 01821
www.raytheon.com

Raytheon Sustainability

This message contains information that may be confidential and privileged.
Unless you are the addressee (or authorized to receive mail for the
addressee), you should not use, copy or disclose to anyone this message or
any information contained in this message. If you have received this message
in error, please so advise the sender by reply e-mail and delete this
message. Thank you for your cooperation.

Eike_Hauptmann · ‎Feb 06, 2012

Hi David,

my asynchronous J-Link application never check out a model automatically. I can't rework the model without a checkout because it is readonly. But it can be a behavior of a synchronous application.

Best regards,

Eike

bfrandsen · ‎Feb 06, 2012

Maybe J-Link in synchronous mode uses the value of config. pro option: dm_checkout_on_the_fly which defaults to CHECKOUT.
You can set it to CONTINUE before doing you modification by using the method SetConfigOption from the BaseSession class. And reset it afterwards.
This will leave the model locally modified, in the WS and no failure if it already has been checked out by another user.

Best Regards,
Bjarne Frandsen

DavidRodriguez · ‎Feb 06, 2012

Hi Mark

Thanks for your feedback. I opened a call with PTC, but no clarification yet. They told me to analyse exactly when the object gets checked (e.g. during RetreiveModel). It could be it is a bug. I will surely try out all the suggestion you made as they can surely help to check the status of the object before retrieving it. I was also thinking of trying to use pfc.Server.IsObjectModfied but your suggestion to usepfcServer.Server.IsObjectCheckedOut sounds better.

Regards

David

In Reply to Mark Stallard:

Hi David -

I'm surprised to hear about JLink's automatic check-out behavior, but I
have
never actually used it to modify a model.

I do have some experience with verifying the check-out status of a model.
I
currently have code deployed which uses
pfcServer.Server.IsObjectCheckedOut.
Just this morning, I noted my doubts that this method actually works, at
least
on Wildfire 3. I don't know whether PTC has an open bug on
IsObjectCheckedOut.
I encourage you to try it just the same, since it's purpose is obvious and
it
should be useful to you.

If IsObjectCheckedOut doesn't work, I can recommend a hack that works on
WF3
that may also work on WF4 and WF5. The parameter PTC_WM_LOCATION contains
the PDM commonspace pathname for the object in your workspace, provided
that
it's actually in commonspace. Strangely, though, this parameter is defined
only when the model is checked in. If it's in a checked-out state, this
parameter is (I believe) not defined (it if is defined, it contains no
value).

Again, I suggest you try pfcServer.Server.IsObjectCheckedOut to check your
model status. If that doesn't work, write some code to read the parameter
PTC_WM_LOCATION.

|+| M a r k |+|

Mark Stallard
Rapid Response Development
information Solutions
Integrated Defense Systems
Raytheon Company

(business)
+1.978.436.6016
(cell)
+1.617.331.5443
(tie line)
239.6016

-

880 Technology Drive
Billerica, MA 01821
www.raytheon.com

Raytheon Sustainability

This message contains information that may be confidential and privileged.
Unless you are the addressee (or authorized to receive mail for the
addressee), you should not use, copy or disclose to anyone this message or
any information contained in this message. If you have received this message
in error, please so advise the sender by reply e-mail and delete this
message. Thank you for your cooperation.

DavidRodriguez · ‎Feb 06, 2012

Hi Bjarne

When running my synchronous program I do not have theconfig.pro option "dm_checkout_on_the_fly" set or loaded. So it should default to the default value of "checkout". I could set it to "continue" butdoesn't this turn off the dialog that pops up for conflicts on read-only objects?I would like to see the conflicts' window and let the user make the decision or call on whether to preceed and how. To my understanding using thedefault value of "checkout" should display the conflicts' window, but it doesn't in my case. I'll surely play around with the values once again.

Regards

David

In Reply to Bjarne Frandsen:

Maybe J-Link in synchronous mode uses the value of config. pro option: dm_checkout_on_the_fly which defaults to CHECKOUT.
You can set it to CONTINUE before doing you modification by using the method SetConfigOption from the BaseSession class. And reset it afterwards.
This will leave the model locally modified, in the WS and no failure if it already has been checked out by another user.

Best Regards,
Bjarne Frandsen

bfrandsen · ‎Feb 06, 2012

David,
CONTINUE will not turn off the dialog for the interactive users. CONTINUE will just be the default options shown to them instead of CHECK OUT NOW.
You can toggle it from within your J-LINK utility, so you still can have the checkout as default.

Best Regards,
Bjarne Frandsen