Attention: Mapkey Syntax changed between DateCodes

[ptc-4392950]

I was upgrading from Creo 2.0 M090 to M110 and apparently the Syntax for some mapkeys has changed, Meaning they just stopped working.

Now for some mapkeys it's obvious when they do not work, but for others (like setting a parameter for example) these things can be easily overlooked.

I think it is very unprofessional to have such changes and not warn the users about this. Even worse, apparently there is not even a list with these changes...

I just have to find out for myself which mapkeys stopped working and then PTC will tell me what the difference is.

Which company makes design changes in its product without listing them, leaving the users without info and then tells them to test it themselves..

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.

[JordyvanderVeld]

That sounds very troublesome indeed! Could you re-record the mapkey and post the new and old config.pro so the two could be compared?

[ptc-4392950]

That is indeed what i did to figure out why a mapkey stopped working. But when having over 50 mapkeys it's quite a job do check them all. Especially when paying that much Support

for example look at this command

~ Select `pagesetup` `TblFormats` 2 `1` `fmt`;

it has changed to

~ Select `pagesetup` `TblFormats` 2 `0` `fmt`;

It's not up to the user to spot this, but up to PTC to have a list of these changes.

[JordyvanderVeld]

I get what you're saying. I spent the last 15 minutes googling for differences between builds and I haven't found anything so far.

On the other hand, M110 has been released exactly one month ago. I wonder why no-one else hasn't noticed this yet...

But I agree, it's a must to notify gamebreaking changes.

[Mahesh_Sharma]

Arno,

This change in mapkey is due to a fix submitted for a serious bug for format replacement in multi-sheet drawings. Earlier mapkeys were not affecting the users for single sheet drawings, but for multisheet drawing users it was a serious bug as it was recording the sheet number. In earlier datecodes if you are working with multisheet drawing, mapkey will record the sheet number, hence when user will try to run mapkey on other sheet, format on that sheet will not update and instead of that it will again update the format for which it was recorded.

To correct this behaviour, fix was submitted and that to not to record the sheet number.

As you mentioned:

Earlier mapkey was

~ Select `pagesetup` `TblFormats` 2 `1` `fmt`;

it has changed to

~ Select `pagesetup` `TblFormats` 2 `0` `fmt`;

here 1 was the sheet number and now it is 0 which is not for any specific sheet.

Hence, new mapkeys will work with multisheet drawings and will not change the format only in a specific sheet.

I hope this will clarify the issue in detail.

[JordyvanderVeld]

Is there a list of bug fixes per build the community could examine? Or at least for build M110? Thanks in advance!

[Inoram]

https://www.ptc.com/appserver/cs/update_advisor/update_advisor.jsp

[ptc-4392950]

First of all it doesn't mention this specific Fix about the Formats in Creo.

Second, it tells not at all something about the influence these fixes might have on some mapkeys.

Plus, it doesn't seem so hard for PTC to create some basic program that can go through your mapkey text and see if anything is outdated concerning the syntax. Should be standard procedure when installing a new datecode. (It's not like it's freeware!)

[Inoram]

That is the list they provide.

[Dale_Rosema]

But the main thing is that when something like this was implimented, it wasn't known so that people could update their mapkeys when they migrated to the new build versus finding out later that some of the mapkeys aren't working due to a "fix" that caused some of them to stop working. We appreciate that bug fix, it is just being left in the dark to find out something you planned on working is not and you know not why?

Thanks, Dale

[dschenken]

What's missing, and has been missing, is a definitive guide to trail file and mapkey contents. Without a guide there is no way for anyone to track deltas between revisions or create mapkeys and training files without manually stepping through the process on a trial-and-error basis.

It's not even possible to create an external program to generate mapkeys using a program like AutoIT because not only does the mapkey language change, so do the positions and operations of interface elements.

Even more complicating is that the interface elements are not (on Windows) Windows elements, but custom requesters and menus, so that tools that work with Windows interface elements can't be used to detect items in the interface.

[LawrenceS]

Mahesh,

That is interesting what you say, but I guess it doesn't make a lot of sense to me because we saw the opposite results to this. The mapkey used to work for replacing the format on both single and multi sheet dwgs, but once going to M110, it would only work for the context it was created. In addition, recreating the mapkey in M110 produced the same results.

So for example, now, when I create a mapkey to replace the format for a multisheet dwg it would not fully work for a single sheet, and if I created it for a single sheet (still using multisheet commands such as select all), it would not fully work for a multi sheet dwg. So for us it seems they broke what they were trying to fix for others.

After a few hours of working on this I was able to frankenstein together the 2 separate mapkeys into one that worked because it would not work by simply creating a mapkey by using the commands. Similar to what was already written but I had to add the ones with the zeros before the ones with the 1s as shown in the screenshote below. The 0 is if there is only one sheet but the multisheet dwgs start with 1. (Before M110, both single and mult sheet dwgs started with 1!)

[Mahesh_Sharma]

Lawrence,

Details of issue in earlier datecodes was as:

1. Drawing was a multisheet drawing.

2. Mapkey was created when sheet one was current active sheet, mapkey will create as

Select `pagesetup` `TblFormats` 2 `1` `fmt`;\

3. Mapkey was created when sheet three was current active sheet, mapkey will create as

Select `pagesetup` `TblFormats` 2 `3` `fmt`;\

4. Now if mapkey (cretaed with sheet 3) will run when sheet two is current active in drawing, format will not replace on sheet two, it will apply on sheet 3.

In M110,

Mapkey was created when sheet one or three was current active sheet, mapkey will create as

Select `pagesetup` `TblFormats` 2 `0` `fmt`;\

When executing mapkey on multisheet drawing, where sheet 2 is current active sheet, format on sheet 2 will replace.

You may open a case with Tech. Support if in case with some specific workflow, this is not working for you.

There is an artice (CS39189) available for this on PTC Web.

[LawrenceS]

Hi Mahesh, How can we view the article CS39489? I searched PTCs main website as well as this community one and no results were found.

Lawrence

[Mahesh_Sharma]

here is the URL https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS39189

[dschenken]

Larry, thanks for taking the time to investigate this. Since TS is now aware of the issue, they should open an internal case to fix it, though, since there's a workaround by Frankenstein merging of separately recorded mapkeys, they don't need to.