I created a sample page with 1 canvas section and 1 grid (VFP as scripting language).
It runs ok within the APP builder, but when I try to go web app view, I cannot see the input fields and the grid at all. I “inspect” the web view and seems that it is created but just not showing….
Name:  lianja.jpg Views: 50 Size:  85.5 KB


for web/mobile Apps the scripting language must be JavaScript.


Does “Lianja.get” runs in server side.prg ? I tried with 1 simple screen and Lianja.get is unable to get the variable value. I have a test screen with 4 variables. On compute click, I run a _test.prg, where the value of 4th variable is the summation of the first 3 variables.

Name:  lj-test1.jpg Views: 35 Size:  36.2 KB

Name:  lj-testcode.jpg Views: 33 Size:  54.5 KB

It works if I change _test.prg to read parameters and pass in the variables on click e.g. txt4.value=Lianja.evaluate(“_test(“+txt1.value+”, “+txt2.value+”, “+txt3.value+”)”)…but this will be very tedious if there is a lot of variables to be passed in.


Server side programs do not have access to the UI, so you cannot use Lianja methods.

In your simple example you could process on the client:

txt4.value = parseInt(txt1.value) + parseInt(txt2.value) + parseInt(txt3.value);

Or as you say, pass the individual values to the server side program.

You can also pass all the values from a section using the section.getJSON() method, e.g.

Client side JS click delegate:

// Event delegate for 'click' event
function page1_section1_field1_click()
	oJSON = Lianja.get('page1.section1').getJSON();
        // convert from object to string
	var cJSON = json_encode(oJSON);
	txt4.value = Lianja.evaluate("addvals('"+cJSON+"')");

Server side addvals.prg:

para p1
oJSON = json_decode(p1)
total = val(oJSON.txt1) + val(oJSON.txt2) + val(oJSON.txt3)
return etos(total)


I can’t seem to get my Lianja to generate a tablet_index.html.

I opened my deployment folder: D:\lianja\cloudserver\tenants\public\wwwroot\apps. The folder is empty.

I opened example_webapp1 and checked that the tablet UI Presentation Rule is ticked and that the directory and deployment directory settings were correct.
I saved the app. Message: App Saved
I clicked the Tablet App View and the app is displayed in the Tablet App View and works as expected.
I clicked the Tablet App View Deploy button. Message: example_webapp1 generated in debug mode and the folder example_webapp1 is created in the deployment folder.
On checking the folder there is an index.html but no tablet_index.html.

When I try to load the app on a tablet, I get a message saying tablet_index.html not found.


run the Tablet View. Right click the results screen and click Inspect. See if there is a red x in a circle, bottom right of Inspector. If there is, that means there’s an error. Click it and it will tell you the location of the error, showing you where in it happened.


I’m testing the Lianja Tablet Web UI Demo app on an iPad 4 and I’m running into some issues. I’m not sure if these are Lianja issues or iPad issues.

I am unable to scroll the App Centre main screen. I’ve published 13 apps and I can see 12 in portrait and 6 in landscape orientations, and I can run the apps that I can see, but I can’t scroll the screen to see all the apps.

The App Centre LogOut button doesn’t appear to do anything. Tapping the icon simply highlights LogOut and nothing else.

In the example_webapp1, in the Customers Orders page, click add or edit on a record and it displays three date fields with drop down date controls. When I touch these controls a Lianja date selector is displayed but then an iPad date style selector is displayed over the top. Can this be prevented? It isn’t particularly bothersome other than the iPad date selector has a clear button and allows entering an empty date.

I have tested this on my Galaxy Tab and found that it appears the App Centre allows scrolling but it’s nearly impossible to actually scroll without accidentally selecting a tile and the LogOut button still does nothing. However, editing date fields only shows the Lianja selector.


The App Center is primarily for desktop and web apps.

Mobile apps are normally built as discrete apps that are installed on mobile devices.

Running web apps on a touch enabled mobile device you will also encounter some permission issues if you are trying to access the camera, local storage etc. Mobile apps handle these permissions as well as the native UI controls such as the date picker.

Building a native PhoneGap app with the correct settings will allow you to request permission to access hardware specific functionality that may be rejected in a web app for security reasons.


a “native” device (phone or tablet) app is generally considered one to be written directly to the underlying framework (Android or iOS or Windows-whatever-they-are-calling-it-this-year). A PhoneGap (Cordova) app is a JavaScript app running in the Cordova framework that interfaces with native functionality on the device.

There is much debate (but less than there used to, because JavaScript compilers and native graphics have advanced so far) about whether a Native app (which will actually use webview for much of its display) is better than a Cordova app (sometimes called a “hybrid” app). For business apps there is very little noticeable difference.

The good news is that Lianja does all the heavy lifting needed to make a Lianja app (written for mobile) into a Cordova app.

Those writing “desktop” apps need to be aware of an alternative, which Lianja also supports: Electron apps. The app is delivered as an EXE (along with a lot of other files). It looks like a modern app, but runs directly on the desktop. It gets its data from the Lianja Cloud Server, just like other mobile apps. Underneath, Electron runs on node.js — which is important because node dll’s can interface to anything on the desktop machine. And, just as there are Cordova add-ins (tons of them) that provide additional functionality, there are node dlls (tons of them) that provide additional functionality.

Lianja facilitates mobile app development by allowing other-language calls to be made transparently on the backend, from the JavaScript in the UI (using exports.conf). Except for very special apps (like some stuff that Herb has developed), there is every good reason to write for mobile, and then package for what you need.


develop an Android app linked to our vfp product and we’re proposing to use Lianja. Once the App is written, the client wants to distribute it via an internal, secure web site rather than using GooglePlay. My brief research would indicate that this can be done fairly easily by simply providing a a link to the .apk file. I’ve read through the process of deploying a mobile app using Lianja and the online PhoneGap build service and was not clear on the availability of the .apk file.


if you use G Suite (aka Google Apps), there’s an easy answer:

Setting up your own is a bit of work, apparently. I have not done this:

And then there’s the private channel in the official Play Store…/2623322?hl=en

You will get privacy without much work with the first or last options.

Unless you are using PhoneGap plug-ins to access device hardware, you can create an icon for the user to run the app without PhoneGap.…lltohomescreen


I was looking for a little advise when deploying my app for a Windows 10 Tablet. Should I stay with a desktop deployment or use a tablet deployment? I tested it using the windows deployment for desktop, but everything is a bit small. When designing apps for tablets do you typically resize everything larger to make it more functional with a touch screen? This is for internal server use, we will not be accessing it over the internet.


If you write it for mobile, you won’t be confined to Windows 10 tablets. The bad new is the rewrite required. The good news is you can call all your VFP routines directly from JavaScript using exports.conf. When data mapping and advanced form layout arrive (currently in the 4.0 release map, starting after the current bugfix release 3.2) there won’t be any reasons not to write for mobile first/mobile only.Desktop users can use the mobile app in Electron, and will think they are using a desktop app.


a web/phone APP using VFP as the main scripting language. I need 2 sections:
(1) A canvas section for user to key in the variables, click on “compute” then…
(2) A grid section to show the results.

we can’t build mobile/web Apps with VFP ?


You write client-side code in JavaScript.

You can make proc calls to server-side VFP code and return the result to the client.

You can write dynamically generated WebViews in Lianja/VFP server side .rsp pages or server-side .jssp pages.

Your build apps visually using Lianja standard sections, custom section for canvas sections.


In a mobile app:

1) if you press the keyboard icon in a webview, you are creating a .js or .ts (depending on what you have set in app and page and section settings), The file will be named <page>_<section>.[js|ts] and will run in the client. A mobile app can only run JavaScript because that’s all that browsers run, at least for now (there’s a concerted effort to change this, but that’s a couple of years away from being universally available).

2) however, alternatively, you can create an .rsp (vfp language server page — r stands for recital, the earlier product in the Lianja line that uses a VFP-workalike, extended) or .jssp (javascript server page), and attach that filename to the URL attribute in the Data section. You can specify that url to take a static or dynamic parameter:…-Visual-FoxPro

Choice 1) gets executed in the client.

Choice 2) gets executed on the the Lianja Cloud Server.

The neat part about Choice 1), executing on the client, is that as Barry points out you can use exports.conf to turn VFP calls into JavaScript calls. That is huge if you have, for example, a need to munge a bunch of data that will then be used in the webview.

The neat part about Choice 2) is that you can use 3rd-party tools, like KendoUI:…ja-and-KendoUI This will get even easier to accomplish with the “Component Builder API” on the Roadmap for V5.0.


You cannot use VFP as the main scripting language.

In a web/mobile app VFP can be used server side.

Let me explain.

You create an app and set the scripting language to JavaScript (or typescript).

You build your app out of standard sections.

You code any delegates in JavaScript.

You have *most* of the VFP built-in functions available to you in JavaScript.

The “grid” section is a standard section. So if you need any delegates just code them in JavaScript.

A “Custom” section is coded by you in JavaScript.

A “Canvas” section is laid out visually and delegates are written in JavaScript.

You can use Lianja.evaluate() to evaluate VFP code from Javascript. This code runs on the server.

Its all in the doc:

I would recommend you get it working in desktop using JavaScript then run it as a “Web App View”.

Hint: use the requery() method of a grid to refresh its contents.

If you open up example_webapp3 you will see it has a canvas section at the top, a standard form section beneath that and a grid beneath that.

It is simple to edit the delegates in the canvas section and in those delegates:

Lianja.showDocument(“page: page1.section1?action=search&text=” + m_companyname.text);

That will cause the form to refresh and then the related grid under the form.


The UI has to be in JavaScript.

There are two exceptions. 1) an .rsp page can be used in a mobile app, as it generates on the Cloud Server, and so what gets pushed to the client is HTML and 2) using exports.conf, you can call VFP prgs on the server that get executed there and return information to the mobile UI.

I have live desktop apps that I re-wrote in Lianja.
The front end is all html5, so it looks any way you want it to. Meaning, you can leave the controls as they are, or use a CSS file.

Also – Lianja gives you the ability to create mobile and web via drag and drop, or custom code.

Whether building Desktop, Web or Mobile Apps in Lianja you can execute your own functions (known as delegates) when actions occur e.g. a user changes some data in a field or clicks on a menuitem or button. In desktop Apps these delegates can be written in Lianja/VFP, PHP, Python or JavaScript.

In Web and Mobile Apps these delegates need to be written in JavaScript — the language of the browser.

In your JavaScript delegates you can call the built-in functions and object methods that are available in the Lianja HTML5 Client API.

Additionally you can make both synchronous and asynchronous calls to server-side business logic (procedures or functions) that are written in Lianja/VFP or JavaScript (soon PHP and Python too) and return the result to your JavaScript code.

So the essence of what you are doing is building a multi-tier client/server App with its UI presentation layer running in the browser and its business logic and data access running on the server — under the control of the Lianja Cloud Server.

Now you may be wondering, how can I build one App that runs in Desktop, Web and Mobile. This is all accomplished using UI personalities. Each UI element in your App can be included or excluded from the target client when the Lianja App Builder generates the code for it.

When developing a Web or Mobile App, firstly tell the App Builder to use JavaScript for the App (This can be set at the App, Page and Section level).




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s