The workbench project manager reflects the project file (.xpj) and provides interfaces for modifying it.
The command DLLFUNCTON is deprecated. Use EXTERN instead.
Xbase++ supports an immense variety of user-interfaces. Windows desktop GUI with common Windows controls or with ownerdrawn controls, WebUI with CSS representing your favorite styling, Xbase++ graphics engine, console interfaces, ... you name it. Even no interface, as required for Windows services, is possible. Most important: there is absolutely no preference. Xbase++ applications can be designed for your specific needs and whatever interfaces you or your customers are asking for. There are no restrictions in terms of interoperability with all the other features available in Xbase++. Mixing GUI with graphics? Do it! Using graphics in your WebUIP? Of course. Having GUI elements within @SAY/GET masks? Why not! This is Xbase++'s Hybrid UI. Just no interface means no interface. Anything else: Xbase++ provides it.
Xbase++ accesses data with DatabaseEngines (DBEs). Those included in the development package – DBF, FOX, NTX, CDX, SDF and DEL – offer an unprecedented level of flexibility. For example, Xbase++ makes it possible to create an index for an SDF file and carry out a search within the SDF file.
The FOX DatabaseEngine supports blobs, and in conjunction with the persistence of all data-types of Xbase++ you can store and retrieve objects. Using DatabaseEngines, such as the ADS-DBE (Advantage Database Server), you are now able to save customer-objects in a client/server database and in this way roll your own object-oriented client/server database.
Besides many indispensable features, Xbase++ has been designed without limitations. What does this mean? The only limiting component of an Xbase++ application is the underlying operating system (Windows XP, Vista, Win7/8.1 and Server 2012). Were you ever in the need for a multi-dimensional array with millions of elements? Generate it. Reading and manipulating strings of more than 1 GB? Feel free. Were you ashamed in the past about your hundreds of PUBLICs or PRIVATEs? No need. Did you feel restricted opening DBFs with only 16 indexes? Not with Xbase++. Did you ever run into problems with the size of your resulting EXE file? No problem with Xbase++. Did you wish to exceed the size of your macro evaluable strings? Use Xbase++.
The Xbase++ compiler creates native code whenever possible. However for codeblocks and macro expressions, so called virtual machine code is generated which later on is executed by the virtual-machine of the Xbase++ runtime engine. This approach gives Xbase++ the utmost performance possible and best dynamics when required. In fact, Xbase++ outperfoms Clipper and Visual FoxPro multiple times when it comes to mandelbrot calculations, for example.
The Xbase++ compiler identifies many more errors than Clipper. This way the compiler increases productivity and the quality of your code and projects. It creates native COFF (Common Object File Format) object files which are linked to become standard Windows PE executables (EXE) and Dynamic Link Libraries (DLL).
The Xbase++ language supports COMMANDs, FUNCTIONs/PROCEDUREs, class objects and methods as well as codeblocks. This makes Xbase++ unique as it combines the very best of all worlds in an elegant way: the capabilities and abstraction of a COMMAND language such as SQL, with the encapsulation and isolation principles of Object Oriented Programming (OOP). We now have the freedom to mix implementation between classes through functions, and finally create a pure data driven logic using codeblocks (a.k.a. lambda expressions or anonymous functions).
Xbase++ is not limited to one concept! You as the developer have the entire freedom to use any programming paradigm you prefer and freely mix them as required. Again Xbase++ does not patronize you but supports your programming style and requirements.
Get touch support for your existing Xbase++ application without any code changes. For example, using touch gestures for panning through your data is now a standard feature of XbpBrowse and XbpQuickBrowse objects. Moreover, full-featured multi-touch applications with support for pan, rotate, zoom or tap gestures can be created using the new events supported by all existing Xbase Parts.
With the PostgreSQL DatabaseEngine (PGDBE), for the first time it is possible to move existing Xbase++ applications using flat-file tables and index files to a leading SQL Database Management System without any restrictions.
The PostgreSQL Database Engine makes this possible due to its hybrid characteristics. First, the Database Engine behaves exactly as DBFDBE, FOXDBE, NTXDBE and CDXDBE DatabaseEngines when opening or creating tables, using standard xBase commands and functions such as DbUseArea(), DbCreate() or USE. In other words, the PostgreSQL DatabaseEngine supports navigational or Index-Sequentiel-Access (ISAM) to SQL data. Second, by using SQL commands such as SELECT, INSERT, UPDATE or DELETE the DatabaseEngine supports transparent use of the PostgreSQL Database Management System. Therefore no restrictions apply for applications developed using SQL as the only data access and data manipulation method. Finally, the DatabaseEngine even allows mixing of the two different access methods. There is no easier option in supporting the migration of existing navigational data-access-based applications to PostgreSQL server and then adding SQL query capabilities later to increase performance.
In fact, developers who don't want to switch from their navigational approach of programming can continue to write new code based on their existing knowledge of navigational commands and functions of the Xbase++ language. There is no good or bad. On the other hand, developers who feel more comfortable with using SQL only can start to develop new application using SQL data-access methods exclusively. This even allows the mixing of development teams with different knowledge sources, as the two data-access methods supported by the DBE do not interfere and can be mixed to any extent.
By using the Xbase++ 2.0 DBF Upsize tool you can move your existing DBF/NTX/CDX-based application data to the PostgreSQL server. Modernize your existing DBF/NTX/CDX-based application just by adding a few lines of code and make use of the PostgreSQL client/server system via the PostgreSQL DatabaseEngine. This can dramatically increase performance and reliability of your applications with almost no code changes. Full support for all ISAM commands (LOCK, REPLACE, DELETE, ...) and functions (dbSeek(), RLock(), Recno(), LastRec(), ...) is provided. It never has been easier to port an existing Xbase++ application to PostgreSQL server.
With Universal-SQL, Alaska Software has added SQL commands as first class citizens to the Xbase++ language. Universal SQL commands are supported for workareas, arrays and objects as well as remote datasources such as PostgreSQL or the Advantage Database Server.
Universal-SQL in Xbase++ 2.0 supports SQL statements like SELECT, INSERT, UPDATE and DELETE, and can be used to perform operations against a local or shared DBF table, CSV files or a remote database. Even the mixture of these different datasources is supported. Universal-SQL even unifies different SQL syntaxes introduced by different DBMS systems. User level variables or functions, even user-defined functions, can be used in expressions of Universal-SQL statements leading to a new level of productivity when it comes to SQL development.
Multithreading - the ability to run PRG code and thus programmatical tasks in parallel - is one of the core strengths of Xbase++. It is used in various areas internally. Having a UI dialog running in a separate thread is a question of one line of code. Outsourcing tasks such as printing or doing a lengthy database operation in a separate thread is normal and can be found in numerous Xbase++ applications.
Technically, the Xbase++ runtime automatically protects your variables from multithreaded inconsistencies. Even simultaneous operations on strings and arrays with multiple dimensions are protected. You, as the programmer, do not have to care. Objects provide a SYNC attribute which is used to ensure consistency in a multithreaded process. For your interest: The Xbase++ internal garbage collector runs in a separate thread, and last but not least, the entire event management process with respect to the operating system also runs in its own thread. This is one of the reasons why you will never see an Xbase++ application saying "Application not responding"! Your Xbase++ app will always respond!
There is no other programming language available which gives you the multithreaded freedom of execution with this level of simplicity and safety as Xbase++ does.
With its unified web application architecture Xbase++ supports all the types and ranges of WebApplications required in todays heterogenous IT infrastructures. WebApplications can be developed as stand-alone services or behind existing WWW servers such as Microsoft's IIS or Apache.
Whatever type of web application you are developing, a small service or a larger scale payment-gateway, Xbase++ fits your needs. Always keep in mind the great plus, that you can still use all other features of the Xbase++ platform as well as your existing source code and knowledge. Therefore use the local DBF DatabaseEngines to handle tens of thousands of transactions per second, use the Xbase++ Graphics Engine to create images in realtime within your HTML page. Use web sockets to push real-time data to the web or your mobile device. Create mobile applications for your POS or warehouse solutions, and connect them to your local workstation via WiFi. Connect your Xbase++ applications over the internet and exchange data in real-time like in a peer-to-peer network. Xbase++ supports any scenario.
The Xbase++ OOP model supports the concept of object prototyping via so called DataObjects. It is now possible to dynamically add member variables to instances of the class DataObject or classes derived from it. Those dynamic members behave exactly like members of regular classes and objects. This means they are visible to the debugger, support reflection, are persistent, and perform as regular members.
As a best practice, developers can use DataObjects as the general transport mechanism of data between the different tiers of an application. Developers should not use DataObjects() as a substitute for the existing concept of Class-Objects and Instance-Objects. Always remember, regular classes and objects are real types, defined by you, and their type and interface can be easily verified using ::IsDerivedFrom(). As a general rule, use classes for your operations such as OrderMgmt() and use DataObjects() for your entities such as Address, Customer, Product, ShoppingCartEntry and ShoppingCart.
DataObjects are the new universal container in Xbase++ 2.0 for transporting all of your domain-specific data between the different layers of your application.
The Xbase++ Workbench is a solid environment for source code editing, debugging and project management. Besides all the project related features such as dependency and build management, the integrated source level debugger supports Windows as well as Web application debugging. The Command Windows allows you to test any legal statement or expression of the Xbase++ language, giving you the flexibility to verify before you write. Using the Source Code Editor in conjunction with the project management allows super efficient navigation within your project. Jump to declaration, go to previous location, skip through all your compile warnings, fold your code using #region directives or simply add an XML DOC comment to your method and have them automatically popping up when writing code. Of course the source code editor not only supports PRG code and CXP pages, HTML and SQL files are also supported.
The object oriented programming model of Xbase++ combines state of the art concepts such as object-prototyping or object-instances created from classes. It is suitable for creating complex and large class frameworks with clearly defined interfaces. Standard OOP features supported by the Xbase++ platform are:
Finally, if it comes to COM/ActiveX support, the Xbase++ runtime automatically creates proxies for an ActiveX/COM components. Consequently, ActiveX components can be used from within an Xbase++ application such as any other Xbase++ object. No difference.