Brian, I completely trust what ever your decision will be.
Ron On May 20, 2008, at 12:56 AM, bhays wrote: > I know people hate it when I write long msgs, but this is very > important so please everyone wade through it to find the pieces > that apply to you. I can also use some guidance on handling > cvs and the changelog. When pulling whole files over, should > I attempt to gather the myriad changelogs from the Harbour > project? I'm leaning toward a simple entry to see Readme.txt > for a list of changes in this re-write. Also, the diff for > these files is useless; a zillion lines have changed and > code has been moved. Does that affect how we want it posted? > - Brian Hays > > Viktor did a lot of great work on rddads. > But some of the choices made in that project would create some > updating > issues for users. Generally I think they're worth the pain as he > addressed many long-standing inconsistencies in the code, > but obviously we want to reduce the number of required changes > as much as possible. The required changes seem minor to me. > Before I post the code we should agree on > some things. We should start a separate thread on the > ADS_REQUIRE_VERSION issue; Viktor has replaced it with a better > #define as part of his "auto-detecting" the installed version > of ACE--his proposal is that developers always have a real > installation of the aceapi, and the (x)Harbour build will look > there for headers and to determine dll versions and even create > ace32.lib for Borland users. > There are a few functions whose return values are different > upon errors, so anyone using them would need to review/alter > those values. For example, some management funcs that returned > arrays on success returned, on error, a number (the ads error code). > Others returned an empty array and expected the caller to use > adsGetLastError for error details. Viktor standardized on this. > > I recommend going with the changes and loudly advertising the need > to read the review notes. Here are some hilites of possible > compatibility issues: > > * contrib/rddads/ads1.c > ! Two occurences of AdsShowError() calls guarded with > DEBUG. This call pops up a visual dialog box on screen > and halts execution until this is confirmed by the user. > Not very desirable inside RDD code in real life > environments. Proper error code were and are still > returned in these cases. > > The calls to AdsShowError() have been a problem for a few users, > so fixing this is great. > > * contrib/rddads/adsfunc.c > * Final reformat and optimization. > ! Fixed to not call AdsShowError() by default, only when > DEBUG is #define-d. For about the same reason as above. > Caller should use AdsGetLastError() to get the error > code and string and present it to the user as required. > + QUESTIONs added. > > * contrib/rddads/adsmgmnt.c > * ADSMGGETOPENTABLES() changed to return empty array > instead of error code in case of error. This way it > now behaves consistently with the rest of the mgmnt > functions. Error code and string can be get by > the caller using ADSGETLASTERROR(). > + ADSMGGETOPENTABLES2() added, which is similar to > ADSMGGETOPENTABLES(), but will also return lock type > for all tables, this way clearing a long standing > TODO in the source. > > This is the list of incompatible changes: > - ADSCOPYTABLECONTENTS() now throws RTE if dest area is non-ADS. > - ADSCOPYTABLECONTENTS() will not change the current workarea > to the destination area anymore. > (Some users may have planned on the old behavior: please review). > > - ADSMGGETINSTALLINFO(), ADSMGGETACTIVITYINFO(), > ADSGETCOMMSTATS(), ADSMGGETCONFIGINFO() will now return > an empty array on error instead of NIL. > - ADS_REQUIRE_VERSION one digit -> ADS_LIB_VERSION three digits > (or four when 10.0 ACE comes out), with the note that > ADS_LIB_VERSION is not obligatory. > - ADS_DIR/ADS_INC envvar requirement, pointing to .h/.lib/.dll > dir (f.e. C:\ads\acesdk). > - ADSSTMTSETTABLEPASSWORD() now needs pArea->hStatement, > rather than an active connection. > > - C level public vars and three functions changed names. NOTICE: > hb_ads_iFileType > hb_ads_iLockType > hb_ads_iCheckRights > hb_ads_iCharType > hb_ads_bTestRecLocks > hb_ads_hConnect > These should only affect anyone who wrote external C sources > that accessed these vars, which should be extremely rare but we > do need to warn people just in case. > > - ADSTESTLOGIN() now requires param 7 to be passed by ref > and param 8 is now ignored. > - ADSMGGETUSERNAMES() will return an array where all items > will always have 6 elements regardless of the ACE version. > > New/fixed stuff (no incompatibility issues here): > - ADSVERSION() memory corruption with wrong parameter. > - ADSBLOB2FILE(), ADSFILE2BLOB() GPF when current wa is not ADS. > - ADSDDSETDATABASEPROPERTY() able to clear values. > - ADSDDSETDATABASEPROPERTY(), ADSDDGETDATABASEPROPERTY() > extended with new properties. > - ADSMGGETLOCKS() implemented. > - ADSMGGETWORKERTHREADACTIVITY() implemented. > - ADS_VFP support and some other 9.0 capabilities added to > several places where they were missing from. > > > > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
