WinEphem version 1.09: Known Problems -------------------------------------- (None known yet.) WinEphem version 1.08: Known Problems -------------------------------------- (None reported.) WinEphem version 1.07: Known Problems (probably now fixed) ------------------------------------------------------------ 1. GEOCENTRIC SEPARATIONS The new screen (since version 1.06) displaying geocentric, as opposed to topocentric, separations between objects has a calculation error that can result in the separations being inaccurate by up to several degrees. WinEphem version 1.06: Known Problems (probably now fixed) ------------------------------------------------------------ 1. FRACTIONAL TIMEZONES In central Australia, Iran, India, Afghanistan, Newfoundland, and anywhere else where the local time offset from GMT is not an integer number of hours, the local time display is wrong. ================================= Problems from WinEphem version 1.05 (probably now fixed) --------------------------------------------------------- 1. WEST LONGITUDE/SOUTH LATITUDE BUG The dialog box for setting longitude and latitude does not accept values of south latitude and west longitude. (All other combinations seem to be OK). This was not a problem with previous versions of WinEphem. ================================= Problems from WinEphem version 1.04 (probably now fixed) --------------------------------------------------------- 1. DISPLAY ISSUES The dialog box for new X/Y objects is still too large for VGA screens. 2. CREATING A NEW FIXED OBJECT The dialog box for new X/Y objects does not allow the entry of new fixed objects with declinations of between -0:01 and -0:59. ================================= Problems from WinEphem version 1.03 (probably now fixed) --------------------------------------------------------- 1. ENTERING LONGITUDE AND LATITUDE FOR THE FIRST TIME When you first run WinEphem, it will ask for your longitude and latitude. When you exit WinEphem, it will ask you if you want to save this information in the Registry. If you answer "No", you will get an unfriendly error message whenever you start WinEphem again. The program should always save your longitude and latitude (without asking) the first time you run it, and it should handle missing information more gracefully. ================================= Problems from WinEphem version 1.02 (probably now fixed) --------------------------------------------------------- 1. FIXED-OBJECT CALCULATIONS The program incorrectly reads the right ascension of fixed objects from files (specifically, Ephem.db). Everything after hours is ignored. A similar problem occurs with declination. ================================= Problems from WinEphem version 1.01 (probably now fixed) --------------------------------------------------------- 1. INABILITY TO SET LONGITUDE Registry values (especially for longitude) are sometimes not read in correctly. This seems to occur only on Windows 95 or Windows 98 machines, not on Windows NT. The error message is "RegQuery failed, error 234" -- which means a Registry value was too large for the buffer that I had prepared for it. But the message continues: "size=8 instead of 8" -- which suggests that the error message is bogus, and my buffer was the correct size after all. I suspect a bug in Microsoft's Registry library, but I cannot prove it. WinEphem cannot run without knowing the longitude and latitude, so it asks the user for them. This is a pain, because it has to ask each time that it starts up. It tries to store these values in the Registry for the next time it starts, but it then fails to read the Registry, and has to ask the user for the longitude again. 2. DISPLAY OF NUMBERS IS NOT ALIGNED On machines with the same video settings as mine, the table of calculated values is displayed in neat rows and columns. On some other machines, however, the numbers seem to be randomly splashed onto the screen, sometimes overwriting each other. Column labels also show this problem. Part of the problem is that I have hard-coded the positions of the cells on the screen, assuming that the positions will be compatible, or at least proportional, under all video settings. This was probably a bad assumption on my part. In future versions, I shall allow MFC to position the cells, even though I'll lose some control in doing so. On Windows 95 machines, the numeric values are not right-justified, as they should be. I don't know why this is the case; I've seen numeric cells in Excel under Windows 95, and they can right-justify correctly. There may be some edit control setting of which I am unaware. Finally, on screens with simple VGA capabilities, the WinEphem window overflows the screen. In future versions, I'll try to redesign the window so as not to occupy more than 640 by 480 pixels. 3. MEMORY PROTECTION ERROR When run with DLLs from Visual Studio version 6, or with Windows NT and Service Pack 4, WinEphem generates a memory access violation error. I have not experienced this problem myself, but it seems to be related to changes that Microsoft has made to the debug DLLs. In my next version, I'll compile a release version, which will use simpler DLLs, and perhaps the problem will go away. ================================= I welcome all feedback about WinEphem. Please E-mail me at: tmark@geocities.com