It's time for a short progress report. XSharp build 2.0.0.9 has been received very well by most of you.There were a few small problems and most of these have been tackled and in most cases a new DLL was created and delivered.
If you look at our GitHub repo you will have noticed that the work on the DBFCDX is progressing also. At this moment index opening and index creation is working, as well as skipping and seeking. The files created are binary compatible with the same files creates in VO and Vulcan. Actually in some rare cases we found a problem in the VO and Vulcan implementation. In the coming days we will finish the work in the CDX driver by implementing updating , deleting and inserting keys in existing indices. When that is finished we will produce a new build.
In the compiler and macro compiler a few small changes were made, nothing big,
Of course we are also preparing for the X# summit in Austin. We hope to see many of you there. If you have not registered yet, it is not too late Please send us an email and we will take care of the late registration.
After Austin we will work on support for the (Visual) FoxPro dialect, Fabrice is going to present X# at a French Foxpro conference and we hope to also present the product at another FoxPro event later this year.
We will also continue to work on the XBase++ dialect.
We have also worked on improving the documentation. As you may know we have used the open source tool Sandcastle to produce our CHM, VS Help and website. Unfortunately Sandcastle does not understand our special treatment of Functions and Globals. By default the functions are documented as methods and Globals and defines as Fields.
We have added a post generation tool that corrects this and now the functions are automatically documented the way you expect. Also the internal types for Usual, Float, Date, Array etc are now replaced with the keywords. See https://www.xsharp.info/runtimehelp/html/Methods_T_XSharp_RT_Functions.htm for an example.
Thank you very much for all your great work!
"Actually in some rare cases we found a problem in the VO and Vulcan implementation."
Could you please elaborate further on what you found out?
Thanks!
We found a small problem in the VO/VN DBFCDX:
when creating an index on a Numeric or Date key the driver allocates an extra (unused) page in the index. This page is later reused when the index expands. As you can imagine we were first looking for problems in our own implementation because our result was not binary identical to the result of the VO/VN drivers.
After thorough inspection we found what the reason for the binary difference was.
this is the best news for the VFP community in years.
Which event are you referring to? Something in the U.S.??
Good news :-)