What if you only gave the end user the .EXE output from the PENG compiler and then you encapsulated the .EXE in an .EXE wraper that is time controled. Atleast the end user would not be able to reload his data if it the unit goes brain dead.

Yea, the end user could be smart enough to download from the pronto before it looses its mind but if they think they have a forever working .exe they may not try. Maybe even throw in a little encrytion.

Source file given at payment time. Hey its better than nothing.

I also ?think? in the current PENG items are lost possibly including discrete codes if you try to download everthing from the pronto. If this is true you might have a solution. You just have to wait for the pronto to loose its mind once. Or figure out how to get it to loose its mind on Q.

I'm betting you don't own the remote so causing it to damage itself or disconnecting the usb port makes you libal. Your best bet is to protect your work.

Other than that, if you want a long shot reverse engineer prontos firware image and modify it yourself. Maybe count button pushes and write FF FF FF to the data area in ram when you hit 5000. Personally I think Philips would have a bigger market if they provided source code for their devices.

solve it all with Pay Up Front.........if i had a hammer, i'd hammer in mornin'.....i'd hammer in the evenin'.....all over this laaaaand!

I have never used timers at all, so bear with me.

Could you set up a timer that would turn on the TV, set it to a channel, and send out about thirty or forty repeated VOLUME UP commands? Scheduled once a day starting at some date? At 3:00 a.m.? Or maybe 4:30, or both?

This will only disable the client's sleep and his following work day, not his remote, so it ought to be legal.

The Pronto only knows the time and day-of-week, not the actual date.

The Pronto NG knows the actual date (including year), but doesn't yet have timers - and when it does get timers such an event would be one-time only unless somebody loaded up a file with dozens of them (not sure how many concurrent timers it would support, either).

Hmmm, so it's back to the C4 bomberjim suggested!

Daniel, have you seen the timers?

The whole idea is still a mute point because the user could simply delete the timers. Without protecting the code there is nothing to prevent the end user from removing the timers.

Just get mad, take them to small claims court, win a judgement and put a lean on their house. :-) It may cost you $100 and some of your time but my motto is always get even. :-) They have to pay the lean before they can sell their house.

yeah!.....make their pictures go all catty-wampus. if they don't pay-up, the only place they could sell it would be to some amusement park to use as one of those "anti-gravity" houses. you don't see those too often anymore though.......kids today are just too sophisticated and all, i guess.

We got one of those in Rapid City, called the Cosmos. After you spend a day walking around the rock (Mt Rushmore) whatcha' do with the rest of your vacation?

I keep telling you Star, South Dakota is just full of fun and sophistication....


Jim L

1) it is moot, not mute

2) you can make a CCF that has "configuration is write protected", that will mean he cannot get into edit mode and change/disable timers.

but like Daniel said, timers are on the day of the week, so the most you can give him is one week to pay

GO TO DISNEYWORLD!!!

you know you could send these guys

Wife gets alot of non paying clients as well cant understand WHY.

I beg to differ, in this forum its mute not moot. LOL



Again I disagree. Acording to the Help file, turning on protection only prevents the user from changing the config using the pronto keys. It says nothing about stopping the user from uploading the pronto to PENG and deleteing the timers.

Its possible that protection will prevent an upload from the pronto but I seriously doubt thats the case. Im not in reach of my pronto to test the theroy.

It's write protection, not read protection. :-)