you could always keep using PEP1.1.... ;_)

But for how long ?

Absolutley. But no doubt in the future there will be firmware updates and that may cause problems with PEP1.1. Or new capabilities that will only be available through PEP2. It becomes an issue if we wish to sell any TSU9800 we obviously need to use PEP2. We have found a bit of a work around at this stage. We can alter the template through PEP1.1 and then upgrade to PEP2. However if you are taking advantage of the routing built into the Pronto system then the inability to use links mean that customer has to change to a different device and page just to change the volume. I just cant get over the fact that a feature that has been available since they started remotes is now just ripped out so that "You no longer need to use hidden code page". What a load of crap. From the templates that I have seen on the Remote Central website, and templates from programmers I know, all use links to make programming easier to build and later alter. I also know that the Australian Distributor has been arguing with them about this and other matters since the beta release. Obviously they don't listen to the poeple who actually use the software the most. Or they couldn't work out how to do it with this new software. I must also say it looks a lot like the Nuvo software.

The elimination of the link function is a mistake! I also can´t see why!

I did not fully understand what avci was saying. It does not help when it is all in one big paragraph.

With links gone, you have to copy each macro which means that if you want to change it, you have to go and change each copy of the macro.

However, there is a "workaround" for creating a single macro that you want to use in multiple places.

Create a new device (now called activity). At the activity level there is a macro that gets executed when you go to the activity (it is in the Actions tab). Put your shared macro here, and REMOVE the jump to the device that was automatically generated. Now just jump to the device to execute your macro. Because you removed the Jump, it executes the code but does not go to the activity.

I know its a real fudge, but it works.

Peter,

When you say copy a macro you mean manually, because it's now possible to copy and paste the steps of a macro in another button, this is not possible in the previous PEPs. At least they improved that.

Still can't see why pronto team purged the links. Why take out a function that was already there? To force evebody to work at the same way?

Depending on what you are doing, it is usually "copy the button that has the macro", then add other bits. But it could manually entering each of the actions.

The original intention was to force people to use My Database - which is good. This is the practice we have all been recommending for years - have one copy of each of your codes in a separate area.

However, they took it a bit further than that. I don't think the architects fully understood the power of shared macros.

They really don't. If they want to force the codes in another area (My Database), all they need is to eliminate the IR Code function of the buttons and move than to the Database, like they did, no need to remove the link function.

And Peter now in PEP2 you can crtl+c and them crtl+p a macro list.

I'd also like to here an official response to this, as I too cannot understand the logic!?

I'm currently using a simplified XCF as my Denon 4308 is being repaired. I've ported this across into PEP2 with relative ease and are now quite comfortable with the changes.

At least I was until I came to do my main XCF. It is full of scheduleafter and executeaction. These are effectively links to a widget. The only way that I can think of retaining these is by keeping my hidden device pages. This doesn't seem right and goes against the move to forcing us to use My Database.

What am I missing here?

John

Hello,

Like many of you, I started using PEP V2 and I think it's really a great improvement. I agree with the fact that it takes some time to get used to it, but ones you understand the logic, it's easy to work with.

I appreciate a lot the "replace component" button cause I just changed my SONY DVD Recorder for one of Pioneer, and instead of taking hours to change the IR codes, I did it in 5 minutes, just a couple of codes to rename and there it goes. I know it was also possible in PEP V1 with the reassign button in the properties of a device, but if you used the device in different pages, you had to do it everywhere. Now, just 3 clicks and it's done for the hole config.

And now, here comes what I dislike or what improvements I'd like to see :

1. Multiple pages display.
I undestand why it's not possible anymore to have mutiple pages side by side so you can easily compare the layout, but a good thing in the WYSIWYG would be a vertical scrollbar. Not to go through all the pages of the config, but through the pages of an activity. Mostly, when you do a copy/paste of the hole page, it's to have the same layout in the following one BUT still in the same activity ( you won't use the same buttons for a DVR than for a radio ). In fact, it would be good to be able to open all the pages of an activity in the WYSIWYG, and scroll from one to the other.

2. Database.
I know, there's already been a lot of posts about it. I think it would be highly appreciated to have a database on model numbers and not on codesets. You always loose lot of time to go through trial and error to find the right code. I know lot of companies have the same IR code for a hole range of machines ( for example nearly all SONY LCD screens use the same IR codes ), so it could make a "thinner" database. Why not publish a list saying that this machine from this company uses this codeset ??? I don't ask a database like the one of Logitech that, I think, would weight much more than PEP V2, but just a list as I mentionned before.

3. More regular updates of the database.
It has always been said by Philips that there would be an up-to-date database, and a lot of updates for it on their website. These updates came only with the update of PEP V1. Let's hope they will release updates of the Database only, and not wait till an update of the program itself. Future will tell on this point.

Regarding Prontoscript, I don't have any particular remark. I don't have so many scripts running ( +/- 20, and all quite simple ) and they all work fine. For that particular point, I leave the remarks to the the persons that trully know something about it.

Best regards everybody

Christophe

Well I think..... we will hear nothing form them.

I don't buy it. PEPv2 is not a bad job; actually it's quite good--if we ignore the link issue. And we can see PEPv2 has been written in an object oriented language by watching what flashes up during the install (C# wasn't it?) so the developers MUST know all about encapsulation, reuse and the danger and pain caused by using cut 'n paste code, not to mention the maintenance issues this causes and the consequent inevitability of bugs. I'll bet they have not duplicated blocks of code internally, so why are they forcing it on us? Something does not add up here...

All of you are welcome to have your voices heard via email. Send to prontoteam at philips dot com.

Instead of links, is it not possible to give a button (or other item) a prontoscript name and then call it from somewhere else? This, of course, does not help anyone trying to import links.

A gripe I have with PEP2 is that the dialogs are fixed in size. That is completely stupid, IMHO.