- Created: 15 March 2017
We are pleased to announce that XSharp Beta 10 has been released to our FOX subscribers today.
This beta contains many new features and works together with Visual Studio 2015 and Visual Studio 2017.
Some of the highlights of this build:
- Support for User Defined Commands in the preprocessor, including Function style Defines
- Many improvements in the Visual Studio integration.
- A new 'ASTYPE' keyword, which works just like the 'as' keyword in C#. So it combines a type check and an assignment in one statement
- Full support for VO style DEFINEs The type specication is now completely optional.
- Some bug fixes
- Performance improvements for compiling assemblies with large numbers of defines and/or (_DLL) functions
For a complete list of changes look at the version history in the documentation on this website.
Our next build is scheduled around end of April, short before the XBase.Future converence in Cologne.
- Created: 06 March 2017
Tomorrow, March 7 is the 20th anniversary of Visual Studio and the launch of Visual Studio 2017.
X# is ready for the event and one of the launch partners. You can watch the launch event online at this link.
To celebrate the 20th anniversary we have decided to extend the 30% discount on our Friends Of XSharp (FOX) subscription for another 3 months. Click here to subscribe to our FOX program with 30% discount.
If you are interested in offers from other launch partners, look here.
We are approaching the dead line for the “Early Bird” price for the xBase.Future conference in Cologne on April 25-27. Register now and qualify for the discount
We expect to release X# Beta 10 by the end of this week. This new build has some exciting new features, especially in the area of the Visual Studio integration (2015 & 2017). We have added support for Class and Member dropdowns, Collapsible blocks in the editor (for #regions, types, members, block statements etc), code completion, intellisense errors in the error list and editor and info tips. It is not perfect yet, but we will continue to work on this in the coming months.
In the image below you see some of these new features in action.
We have also added UDC support to the preprocessor, so almost all your “old” Clipper and Visual Objects UDCs will work with X#. You can even use the old @ SAY .. GET commands in your code, if you want, as long as you map these to meaningful function calls.
In fact we are working with a customer to migrate a Clipper/Harbour application that is full of these commands to X# !
And the good thing is: the X# Visual Studio Language integration is "smart" enough to recognize your UDC keywords and color them as if they are built-in keywords.
- Created: 28 February 2017
More and more people are using X# and are deploying their applications written in X#.
We have received some examples from our customers and have added a "gallery" of these example applications to this website. Click on the Examples menu option above to see a list of examples.
We'd love to hear from you as well and share your success story with the rest of the world. Please send us images and a short description of your application.
A great opportunity to look at successful applications is also the "Application Show" at the XBase.Future conference in April.
We'd love to see you there. Please register now !
- Created: 15 February 2017
It is time to let you know what we have done since beta 9.Below is a list of the things that are ready and will be included in beta 10.
We have also published the contents of our help file on the website.
- We have completed support for the DEFINE keyword. The type clause is now optional. The compiler will figure out the type of the define when no type is specified.
The DEFINEs will be compiled to a Constant field of the Functions class, or a Readonly Static field, when the expression cannot be easily determined at compile time.
- We have extended the preprocessor . It now has support for #command, #translatem #xcommand and #xtranslate
- Added ASTYPE expression, similar to the AS construct in other languages. This will assign a value of the correct type or NULL when the expression is not of the correct type:
VAR someVariable := <AnExpression> ASTYPE <SomeType>
- Tested and works with Visual Studio 2017 RC 4
- We have added supports for snippets and included several code snippets in the installer
- Added support for ARM and Itanium platform types
- The parser that is used in the Windows Forms editor now also properly handles background images in resource files. Both images in the resx for the form and also background images in the shared project resources
- We have added Nuget support for our project system.
- Added a project property to control how Managed file resources are included: Use Vulcan Compatible Managed Resources
- Fixes several problems with dependent items
- Added implementation of the OAProject.Imports property, which is used by JetBrains
- Fixed a problem converting WPF style projects
- Created: 05 February 2017
More than a year ago, we have published our first development Roadmap for the X# project. This new roadmap continues the tradition and describes what our plans for 2017 are.
Our plans for 2017
You will not be surprised that the open items from our roadmap for 2016 are still on the to do list for 2017. Some of the things on our to list:
- Improved Visual Studio support:
- Nuget support
- Editors for the VO Binaries
- Support for other VS subsystems, especially those that are based on T4 templates.
- “Intellisense” features for the editor, such as completion lists, parameter tips, Goto definition etc
- Class browser and Object browser support
- Debugger support for Globals and X# expressions
- Create the X# runtime, so you no longer need the Vulcan Runtime to run your apps that use RDDs and the VO SDK classes. Our intention is not only to replace the Vulcan runtime, but also to improve it.
After all, we have done this before, so we can do it again, but then better!
- Thread Safe runtime and RDD system
- Runs on AnyCPU
- Support Runtime Macros AND scripting (our macro compiler will support the complete language!)
- Portable where possible. Unfortunately, there are many areas (IO related mostly) that can’t be completely portable
- Add support for an extra xBase language. At this moment, we are considering to add support for (x)Harbour. The (x)Harbour community is very active and seems to be the most interesting target audience.
Contents / Motto
Most “intellisense” features in VS
Complete X# Runtime
First version of (x)Harbour support
Complete version of (x)Harbour support
- Created: 30 January 2017
We are proud to announce the release of XSharp Beta 9.
This beta mainly focuses on bug fixes and compatibility With this build we consider the VO and Vulcan support completed: the complete Vulcan SDK compiles as well as 99.9% of the 3rd party products, such as ClassMate, ReportPro, bBrowser and Vn2Ado. You should have no problems compiling your Vulcan code with this build of X#.
Many changes to the compiler have been released before as Beta 8a and Beta 8b. We have made some more changes since beta 8b mostly as a result of your feedback, for which we are very grateful.
This build also includes updated Visual Studio integration. Unfortunately not with Code completion and other editor features, but we did make quite some changes to the build system and project system. Not all of these are directly visible, but we fixed some glitches, especially with regard to dependent items, resource compilation, the error list etc. We have now also enabled all the VO compatibility compiler options in the project properties dialog.
And if you are wondering "where is my intellisense": we have decided to delay the Code completion support until the next build because we were not completely satisfied with it.
You will also find quite some changes in the documentation. All of the compiler options are documentation now, and we have included a list of the most common error numbers and messages.
Today we are uploading both a build for our Friends Of XSharp (FOX) subscribers and a public build. This public build is identical to the FOX build but does not include the optimized version of the compiler.
Last but not least: our special 30% discount on the price of a FOX subscription was expiring this week. We have decided to extend this price until February 15th. Click here to subscribe now
- Created: 30 January 2017
In part 1, part 2 and part 3 of this article series I have shown you some problems that we found in existing code (in our own code as well, and we thought that that code was perfect). Today we will discuss a few other problems that we found.
Wrong order of arguments in indexed ASSIGN in the SDK
Have you ever tried to change the caption of a tab page in a Vulcan app that uses the GUI classes with something like that? :
SELF:oDCMyTabControl:TabCaption[#MyTabPage] := "New caption"
If you have tried that, then you must have noticed that this code does not work in Vulcan (it does not work in VO either), the tab page remains unchanged! X# revealed why, it is because the TabCaption ACCESS/ASSIGN pair has been declared incorrectly in VO (and subsequently also in Vulcan):
ASSIGN TabCaption(symTabName , cCaption) CLASS TabControl
This is an indexed ACCESS/ASSIGN, and in the ASSIGN declaration one parameter is the name (as a SYMBOL) of the tab page caption to change and the other is the new caption. But the order in which the parameters have been entered is incorrect! The first parameter should be the new value to be assigned, followed by the index expression(s). This is revealed by the X# compiler which reports:
error XS9039: The parameters for the Access and Assign declarations must match by name and type. The first ASSIGN parameter is the value, the other parameters are the indexers and must be the same as the ACCESS parameters.
So this ASSIGN should have been defined as:
ASSIGN TabCaption(cCaption , symTabName) CLASS TabControl
After making that change in the SDK code, now changing the caption of a tab page via code is working perfectly!
Weird problem with _winNMDATETIMESTRING in the VOSDK
This is by far the strangest problem we have found with the help of X#, while trying to compile the original SDK from VO. You can see it by navigating through the repo explorer of ANY version of VO to the CommCtrl module of the Win32 API Library, press CTRL+M to open all the entities of that module in the editor and search for “_winNMDATETIMESTRING”. This will point you to that chunk of code in the editor:
DEFINE DTN_USERSTRING := (DTN_FIRST + 2) // the user has entered a string
MEMBER _winNMDATETIMESTRING ALIGN 1
MEMBER nmhdr IS _winNMHDR
MEMBER pszUserString AS PSZ
MEMBER st IS _winSYSTEMTIME
MEMBER dwFlags AS DWORD
Something looks very bizarre here, doesn’t it? At least it looked bizarre to our compiler, which reported a parser error when compiling that code in X#. After a few minutes fearing that the unexpected Athens snow and cold had made our eyes “see” things that were not there, we realized what had really happened: Many, many years ago, the original authors of the VO SDK had accidentally typed “MEMBER _winNMDATETIMESTRING ALIGN 1” instead of “STRUCTURE _winNMDATETIMESTRING ALIGN 1”, causing the whole structure to get somehow embedded as part of the DEFINE DTN_USERSTRING entity above! The result of this is that the _winNMDATETIMESTRING STRUCTURE is not actually available in the SDK and this problem has been carried over also to Vulcan, where this structure is not available either. Of course this is not something of huge importance, but it was a pretty weird problem that X# revealed and I wanted to share it with you!
Typo in ShellWindow:Dispatch() of the VO SDK
This is another problem in the existing VO SDK, you can see it by opening the Dispatch() method of the ShellWindow class in the GUI Classes, again in any version of VO (or in the Vulcan SDK). In about the middle part of that entity, you will see this code:
CASE (uMsg == WM_SETCURSOR)
IF (oEvt:wParam) != (DWORD(_CAST, hwndClient))
lclient := FALSE
lclient := TRUE
lHelpEnable := TRUE
lHelpEnable := FALSE
lHelpEnable := FALSE
SELF:__HandlePointer(oEvt, lHelpCursorOn, lclient)
When compiling this in X#, the compiler reports: warning XS0219: The variable 'lHelpEnable' is assigned but its value is never used. That made us look more closely to the code and realize there is another typo, the 2nd argument passed to the __HandlePointer() method should be “lHelpEnable”, not “lHelpCursorOn” as it is now. So this is another thing that must be corrected in the VO SDK.
Miscellaneous potential problems revealed by X#
Most of the issues in code revealed by X# that were described above are critical ones, as in most cases they lead to serious problems when executing it at runtime. But by no means are those the only problems revealed by the compiler. X# also warns us about many other, less critical, things in our code, like inconsistent accessibility (for example when a PUBLIC method has a parameter of a type that is INTERNAL), class fields or events that are left (accidentally?) uninitialized and much more. I personally found many dozens of them when compiling XIDE in x#! Those warnings are for up to the developer to decide if he/she wants to follow the compiler’s advice to adjust the code or not. Describing all those cases would probably require a whole book, but maybe some of them could be covered in another blog article in the future.
- Created: 26 January 2017
In part 1 and part 2 of this article series I have shown you some problems that we found in existing code (in our own code as well, and we thought that that code was perfect). Today we will discuss an important other problem, that has to do with WIn32 interoperability.
Win32 Callback functions
There exist many functions in the Win32 API that require a callback function to return their results to, or use it for some other reason. Probably the most known one is the EnumWindows() function, which enumerates all top-level windows managed by the OS and it can be used like this (VO code – please don’t mind the style, it’s for minimum line length):
FUNCTION Start() AS INT
EnumWindows(@EnumWindowsCallback() , 0)
// this is the callback function:
FUNCTION EnumWindowsCallback(hWnd AS PTR , lParam AS INT) AS LOGIC
LOCAL pszString := MemAlloc(100) AS PSZ
IF GetWindowText(hWnd,pszString,100) != 0
There are a lot of such callback functions used in the VOSDK and in a lot of VO-programmers’ code as well. And this code can work in .Net, too, but unfortunately not without some changes, because the calling convention of the function when compiled in .Net is different to what the OS expects. Making those changes (see below) is not too difficult, but the real hard part is to locate those places (possibly among 100,000s of other lines of code) where callbacks are used.