The Christmas build (2.0.0.8) has been received very well, but unfortunately a few small issues in the compiler make this build difficult to use for some of our clients. The good news is that we are getting very positive reports about the level of compatibility of the runtime and the compatibility and speed of the macro compiler.
We will deliver a new version in the coming weeks that fixes the compiler problems and also has some bug fixes to the runtime and VS integration.
The biggest other change in that new build will be the support for dBase style "dynamic" variables, such as PUBLICs and PRIVATEs. We have added this to the language, even though we think that there are better ways to code, but we know that some of our (potential) customers are using it. We have also added support for the PARAMETERS keyword which is an alternative for the declared parameters and works just like the parameters in a clipper calling convention. But the compiler does not create local variables for these parameters but private variables.
Memvars will be available in the VO, Harbour and Xbase++ dialects. So not in Vulcan and not in Core. And you also need to explicitely enable them by setting a special compiler option. We have also added support for undeclared variables (yes, really). This requires an additional compiler option and will always produce a special compiler warning (that you can disable). Undeclared variables are mapped to a runtime call that either returns the value of a field in the current workarea or otherwise a value of a PRIVATE or PUBLIC variable.
We have done our best to make this perform as fast as possible, but your code will be faster (and less error prone) if you stay away from the dynamic memory variables. So the choice is yours.
Unfortunately the work on the DBFCDX driver and additional work on the VS integration has received lower priority in the last weeks. Two of the devteam members have had to deal with the death of (close) familiy members, and 'family comes first' as you can imagine. So work has had lower priority as you will understand.
Something else is that Visual Studio 2019 preview 2 has been released. Our VS integration works nicely with this new version (you may have to run te installer again to install the VS support), however there is a problem with the 'New Project' dialog. Microsoft has hardcoded the languages in the languages dropdown, so XSharp is now shown as language. Also when you select the project type Windows Forms or Console then our templates are not shown. Only when you type XSharp in the search control then will our templates be shown.
In Preview 1 you could disable the new "New Project" dialog and switch back to the old dialog from previous versions of Visual Studio. That is no longer possible in Preview 2.
You can imagine that we are doing everything we can to get this corrected before VS 2019 is released, but we are not sure if there is time / priority for this in the Microsoft team.
Opening existing solutions / projects is not a problem, it is only the dialog to create new projects that has this problem.
For now we recomment not to use VS 2019.
Stay tuned for more news on the new release.
Finally: don't forget to register for our 'Summit' in Austin. The dead line for the special hotel room price is February 15. And of course we'd like to see many of you there !
First, and most important, my condolences to the 2 team members suffering the loss.
Second, I was wondering if you could show a line of code using dynamic variables which we should avoid?
Finally I think not using VS 2019 will probably be a good advise anyhow. I already wrote Microsoft would not change a bad decision, in this case the hard coding of languages, they never do. It would be no less of a miracle when you get it changed. It will most likely mean that VS 2019 has many more unpleasant surprises. Last July I finally installed VS 2017 because I could no longer work on UWP's in VS 2015. It has taken me 1,5 day to get it working (see https://developercommunity.visualstudio.com/content/problem/288722/visual-studio-2017-does-not-install-due-to-access.html, in case you're interested). Now it works (more or less) I plan not to touch it until again I am forced to do so (I don't even install updates) because the next 1 or 2 years I don't want to waste again hours on installation attempts to this piece of crap.
Dick
Karl
DBFCDX is on top my priority list now.
Robert