Starting from release 9.0.0 Nitisa framework can be installed as common Visual Studio extension and Form Builder can be used directly in Visual Studio as integrated editor. To install Nitisa as extension do following simple steps.
Nitisa extension is available for Visual Studio 2017 and newer.
After the installation you will find several available projects(for different platforms) in the Visual Studio's New Project dialog in the Visual C++ option.
You don't have to build Nitisa as in standalone installation. It will be built automatically when you compile any Nitisa project created from installed templates first time (and first time only).
If you don't want to use Visual Studio as development environment or want to omit using Nitisa integration into Visual Studio for some reason, you may proceed with the following simple steps to start using Nitisa framework.
If you work in Visual Studio 2019 it most probably will ask you to retarget solution projects when you open Nitisa.sln. Just accept retargeting.
You might wonder about differences between using framework alone and using it as Visual Studio extension and which is better option for you. Well, we are going to explain the difference right now.
Using Nitisa extension for Visual Studio simplify framework preparation, project creation, and Nitisa update. It also allows to work with Nitisa as a part of Visual Studio, so you don't have to worry of anything except for extension installation itself. But in this case Form Builder is built somewhere else and placed in the place you usually don't bother about. It results in some restrictions. Form Builder as a part of Visual Studio can not load external packages, it only uses integrated standard ones. You also cannot modify it as the source code is not available.
On contrary, standalone installation is provided with a complete source code and allows to build Form Builder in *RT configurations which can load packages in form of dynamically loaded libraries.
So, if you just create applications using the power of Nitisa framework, the extension for Visual Studio is the right chose for you. But, if you develop your own widgets and packages of widgets, which you want to be available in the Form Builder, better chose is using standalone installation.
Can you use both standalone version and extension for Visual Studio? Yes, you can. You even can use many version of standalone installations. Just be careful in specifying paths for include and library files in your applications.
Installation process is very simple:
./build-all.sh in the terminal. It will take some time but you don't have to worry as it is required only once. The solution of the downloaded framework has four supported platforms: ARM and x86 for 32-bit builds, ARM64 and x64 for 64-bit builds. Where ARM and ARM64 platforms are used for Android projects only. It also has several configurations. They are Debug, DebugRT, Release, ReleaseRT. Configurations without RT produce static libraries with static runtime library linking. Configurations with RT produce static libraries with linking runtime library in DLL. We recommend using RT configurations to build Form Builder and for building your own packages. When developing applications non-RT configurations are usually used.
For the Linux projects you will also need to setup connection to your Linux for remote building.
Anyway you are free to add your own configuration for your applications. Just don't forget the framework core and Standard package configuration should be compatible with build configuration of your application(pay attention on using runtime libraries, platform toolset, and SDK version).
There are some simple recommendation we can give to facilitate you to chose which platform and configuration to use. If you plan to run your application on 32-bit platform only, you have no chose but to use x86 platform. If you plan to run your application on 64-bit platform only, you may use either x86 platform option(which produces 32-bit binaries) or x64 one. Until your application doesn't operate with a huge amount of data (>2Gb), the best chose is x86 platform option as it produce smaller and a little faster binaries. Otherwise use x64 one.
As for the configurations, you can use Debug and DebugRT ones for development and Release and ReleaseRT ones for production binaries. Use *RT when you are developing widgets and packages of widgets which are supposed to be manageable by Form Builder. In other case use configurations without *RT.
This paragraph is applied to standalone installation only.
Build solution in DebugRT or ReleaseRT to produce Form Builder executable files which dynamically load packages. This is the recommended option.
Build solution in Debug or Release to produce Form Builder executable files which do not load packages but rather link with them. In this case only packages available by default are integrated into Form Builder and to add another packages you will need to change Form Builder's source code and rebuild it.
If you installed Nitisa via Visual Studio you may remove it in standard way as common extension: go to Tools->Extensions and updates menu, find Nitisa there and click Uninstall.
Additionally you need to delete compiled files which are located at all users application data folder(which is usually C:\ProgramData). The subfolder there to be deleted is called Nitisa.
If you downloaded and unpacked Nitisa in some folder you may just remove the folder where you unpacked it previously.
If you work on Linux only, all you need is to delete folder in which you previously unpacked Nitisa framework.