I've just had reason to look at my event viewer (Windows 7). It is absolutely stuffed with Pronto errors, all identical:

"Input string was not in a correct format.
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)
at System.Single.Parse(String s, NumberStyles style, NumberFormatInfo info)
at Philips.Pronto.Editor.DatabaseAccess.InterpretDbStringPowerOnDelay(String str)
Original value:

I've no idea what, if any, the consequence are. But it actually makes reading the other events almost impossible (e.g. I have 10 of the above errors in the last two minutes).

Anyone else getting this?

Maybe errors of the simulator? But the last seems it has to do with the database, strange.

I'll look mine on monday, but I think it's better if you report it to the prontoteam, because it sounds strange, that javascript execution errors end up in the computer's system log.

These are not Javascript errors, they are exceptions from .NET.

Looks like they are trying to parse Duration or Delay on a PowerOn command for a particular device and it is a value which is not a floating point.

Have a look at your database and for each component, see if you have a valid PowerOn Delay specified. If so, you will likely need to zip up a backup of your database and send to Belgium.

FYI, this does not occur for me on XP so I suspect it may be something specific to a component in your database.

BluPhenix and Lyndel,

Thanks both. Per Lyndel's suggestion, I've now gone thru all my device and several had blank values for the duration and delays. So I've set them to valid values and we'll see what happens. If the errors continue, I'll report back here. So, if you don't hear from me here, assume that the problem is resolved.

Its not clear to me how the values became blank - when setting up a new device, I always leave them at their 0.1 defaults.

ps. No further errors reported during the time between re-setting the blanks and writing this message :)

Intrigued enough by this to have a look at my own Event Viewer (Win7) and lo and behold I had the same. I've found the single problem component and amended its delay and duration.

However I also have a different event logged;

The directory is not empty. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive) at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive) at Philips.Pronto.Editor.Project.DeleteDirectory(String path) at Philips.Pronto.Editor.Project.DeleteDirectory(String path) at Philips.Pronto.Editor.Project.Close()

Any thoughts on this one?

John

Guy,

Maybe they became blank when you opened a PEPv1 configuration such that the components were added to your PEPV2 database?

Honestly, no idea.

Yes, could be. A bit odd that they continued to work but reported errors in the event viewer.

ps. No errors since I corrected them :)

Lyndel

An interesting suggestion but I don't have PEPV1 on this PC.

As I only had a single component in error, I traced back to when I added it to my database and where from. It came from the latest O1R database and a quick check of a couple of other components show duration and delay as blank. I'll drop them a note to point out the problem.

Since I corrected the single component, I've not had either error. However I did also re-install PEPV2 to be on the safe side.

John 

I'll have to amend my last statement. The log shows the 'directory is not empty'  error once per day since Saturday. Looking at the time of the error and my use of PEP2 today I cannot tie it to a specific action. However as it doesn't seem to have affected my editing or downloading to my Pronto, I shall not look at Event Viewer ever again.

I've received a response from Dave Sereno at O1R as follows;

To all parties involved here,

I have emailed Prontoteam with a link to this thread. Maybe they can prevent the delay-based errors from from going to the event log in the future or at least provide a more meaningful message such as which component, etc...