Personnaly I can live with making a code database and have already merged my learned codes on given advice.

However, I use links extensively in a DVD library to operate a 400 DVD changer. My library pages contain thumbnails that link to 400 macros each containing the number for each slot and further links to common start and end macros.

I also use modular sub-macros in main activity macros. For instance, when I want to watch a DVD the main macro turns on DVD, AMP, TV, etc. but also calls another macro that pre-sets the Amp volume by lowering volume for a long time and then raising a pre-determined time. I use the same volume setting sub-macro in main macros for watching DVD-R or Satellite.

PEP 2 will need to be pretty dang good for me to change. Will there be eventual compatibility issues if I stick to PEP 1?

Herb,

The Channel Macro Wizard will NOT help you here. What you would end up having to do is to code macros such as this into separate activities (Yes, the Activity Action List from NG and Classic Days is returning) and use the new Activity Jump to execute the Macro.

I know what you are thinking but don't have anything positive to say. :)

Personally, My recommendation was to retain support of links but Philips has something else in mind. Just don't know what it is as of yet.

OK folks, can anybody explain what will be the real benefits of PEPV2 over PEPV1 ?

A decent database!

But couldn't that have been done (long ago) without the removal of some of the features we've been using for some time? Hopefully it will add something in the feature area. Javascript in the simulator will be nice, although a large chunk of my xcf is dependent on TCP. I'm going to have to invest time in figuring out how to run simulated TCP in the simulator.

The proof is in the pudding. Roll the dang thing out.

The one thing I wanted in PEP2 and Philips would not discuss, was an infinite canvas.

Both the 9600 and 9400 as physical devices inherently have an infinite canvas. Load a 9400 xcf into the 9600 editor and you can add all sorts of panels, buttons into the 640x480 display area and they will be there if loaded into the 9400 or 9600 and can be moved into the 9400 visible area at will. Very nice for dialog boxes, etc.

Now if the editor allowed for an infinite canvas and positionig of the "Screen" at any coordinate (allways loading the screen at 0,0 with all other coordinates adjusted relative to that point), I would never need more than one page for a display and I could see all the germane widgets while working on the page. Adjusting the left and top coordinates of a widget at run time is trivial.

In practice I never use the 9400 editor except to load the 9400. I do all my editing in the 9600 editor.

What is your reason for only using the 9600 editor? Does it offer more advantageous features? How do you account for the difference in resolution and screen size of the two remotes?

Thanks in advance.

Using 9600 editor for 9400 configs does have benefits.

You can put widgets such as menus or things that will be show with Prontoscript outside of the visible area (240x320 top-left region) such that you can do page layout with extra widgets without so much clutter (don't have to keep moving things around).

Also, if you are building a resource page, you can use the extra space to house panel widgets (with image resources). You can usually layout more widgets on a 640x480 page than you can on a 240x320 page.

It is obvious Lyndel and I talk a lot!.

You can just load a 9400 xcf that has never seen the 9600 editor into the 9600 editor and the system page will be set. All the system widget names are the same.

You must first open the 9600 editor and then within the editor, open the desired 9400 xcf. I have been doing just that with slimPronto-94 for the past year

One note of observation, when either editor saves the file it marks it so that windows knows which editor to load if you double click the xcf. You can always load the xcf into the editor of your choice using the method described above.

I also do all my 9400 debugging (except for visual image approval and color rendition) on the 9600. This is because I can use the PC based Debug system instead of trying to stare all day at the very limited _PS_Debug_ panel of the 9400. TCPIP work is much easier when you have a scrolling window on the PC holding all System.Print data in 12 point type, well at least for my 68 year old eyes it is.

Really. What's the holdup? Are they waiting for the official launch of the TSU9800 to release the new editor?

Jeff

I don't think we'll have to wait too much longer ;-)...

.

I believe that is the case. There have also been some last minute glitches.

there are some of us using beta copies for testing, ive been told its due out very soon... :-)

But i have to say there are some feature's im not that keen on.. :-(

Well, it's not the first. The Philips Trainers have one. There's also another one in the states as well.

[Link: onlyoneremote.com]

And... You do not need PEPV2 to program it. PEPV1 already supports Hard Key Links to 'Back' and 'Exit' which are made available on the 9800 as rollover from the 9400.