run scripts without interface

[meerkat]

To run LB cgi scripts in Apache you need to compile the programs.
During new development, it would a great help, and a lot easier, to run the *.bas scripts without having to compile for each test.

Would it be possible to run LB with a switch that would bypass the user interface.
For example I have Apache ScriptAlias set to E:/LB4/cgi. That is where I keep my LB cgi scripts.
So during cgi development we could simply tell Apache to run LB *.bas programs with:
#!E:/LB4/liberty.exe -rs This switch would tell LB to Run *.bas scripts using liberty.exe
#!E:/LB4/liberty.exe -rsd This would tell it to run in debug mode.

Thanks for the help..
Dan

[Chris Iverson]

You could use -R -A -M, I think. I honestly hadn't thought about that.

From the helpfile:

-R Run a BAS file on startup

-D Debug a BAS file on startup

--------the following three are in the registered version only--------

-T Make a TKN file from a BAS file on startup

-A Automatically Exit LB on completion of BAS file

-M Minimize the Liberty BASIC editor on startup


Note that you do need to have LB registered on the machine you're running the code on.

Also, the standard shebang syntax of specifying the script executor in the file itself won't work for LB. # is not a comment character, and LB would attempt to interpret the first line as code.

I'm not familiar enough with Apache to know for sure, but there might be another way in Apache's config to specify what executes the script.


EDIT: Actually, I managed to get it working.

First, your Apache config. Apache can be configured to look execution handlers up in the windows registry instead of using the first line of the script.

Add this somewhere in the config(I added it right after my ScriptAlias directive):

ScriptInterpreterSource Registry-Strict

Next, we need to edit the registry to tell Apache how to execute .bas files. Open the registry editor as admin, and go to the following path:

HKEY_CLASSES_ROOT\.bas\Shell\

If you don't have a "Shell" folder, right-click the .bas folder, and click "New Key".

Next, create the following path under Shell:

ExecCGI\Command

That's two new keys you'll have to make. The full key you end up with should be:

HKEY_CLASSES_ROOT\.bas\Shell\ExecCGI\Command

Go there, and you should see the blank (Default) value. Set that value to the following(don't use the -M flag; it doesn't work, and it's unnecessary anyway):

"C:\Program Files (x86)\Liberty BASIC v4.5.1\liberty.exe" -R -A "%1"

Of course, edit the path however you need to to point to your actual install of liberty.exe.


Then, throw the .bas file into your script folder, and edit your HTML file or browser URL accordingly(for my example, it'd be cgitest.bas instead of cgitest.exe).


Works successfully for me.

[meerkat]

Thanks Chris..
I'll give it a try..
I'm new to LB - I have a lot to learn..

I think I have a standard way to make web pages interactive. For example I may want to have LB look up a customer after the user enters a ID and display the name or *error in the cust name field.

I have a js script that gets hit for reasons like mouseover, onChange etc. Anything can hit it including dropDowns or whatever.
The script enters data into lbPass and clicks a hidden link or button.
The button sends data to the server that reads the lbPass data.
LB checks the lbPass to determine what to do. In this case it will see "doCust', and do the SQLite customer lookup and return the customer name or error into the customer name field.


<script>
function lbHit(x) {
document.getElementById('lbPass').value=x;
document.getElementById('lbLink').click();
}
</script>

'LB gets whatever is placed in lbPass
<input type='hidden' value='nothing' name='lbPass' id='lbPass'>"

'customer ID input
<input type='text' size='5' name='custId' value=";custId$;" onChange=lbHit('doCust')>"
The lbLink button/link is also hidden

[Chris Iverson]

Definitely a good start on some stuff, although you also need a way to pass the customer ID in in that example.

Additionally, I'm not sure onChange would be a good event to use, as it will fire every single time a customer types something in. If a customer is entering a five digit customer number manually, your code will call out to the LB backend five times, once each time another number is added, and the first four times will(if you're lucky) error out with an invalid ID code(if the ID number they enter is 12345, then it will fire with ID number 1, then 12, then 123, then 1234, then 12345).

I say "lucky" because, if you're unlucky, one of the in-between numbers they enter will match up with another customer's ID, and your customer will get back someone else's data.

For example, if you have a customer number 01234, and one 12345, then (if these are being treated as numbers and not strings) when it fires on 1234 before doing 12345, it will match customer 01234(since standard number handling cuts off the leading zero, as it's meaningless).

That's why there's usually some method of letting the user click on something to confirm they're done entering data.


Also, if you start having issues with the "manual click" method of doing things, you may want to look into how to use XMLHttpRequest, since making requests to your backend without needing to reload the whole page is the entire reason XMLHttpRequest was created. I have an example of using it in the test code I posted in the other topic.

[meerkat]

Thanks Chris..

I like XMLHttpRequest and will definitely use it..

The reason I used ONCHANGE is to make sure something changed in the field.
- onChange occurs when the element loses focus and only if something changed in the field.
- onblur happens when the element has lost focus, changed or not.
- There are places where I use onkeyup. As soon as the keyboard key is released, the event is triggered. I may display a drop down "<SELECT name='something" with a list of maybe the first 20 matches, and as the continue to type, the drop down is narrowed down. They may select from the drop down instead of typing the rest of the field.

For numeric and decimal fields I'm using the <input type numeric/decimal and since I know the beginning and ending numbers of the customer number, I'll use the min and max. That way it's checked as they type for numeric. I'm also using the proper type for date picking, color picking and other types of input.

In the past I always worried about "turn around time" and only had maybe one [submit] button per page. With 5g network latency being very fast, interactive pages are acceptable.

Trying to keep track of session stuff on the server is too much work.
After trying several ways to maintain session variables, I decided to hold them with leading s.* in the web page. Again because the new network speeds, I'm not worried about passing this stuff around.

I could hold a hidden <input variable for each field. So for custId, I could have a <input id=s.custId value=";custId$ ...
Or I may hold all variables in one input type text as; <input type=text id=session and a value for each field as "custId=";custId$;chr$(231);itemNum=";itemNum;chr$(231).....

A hidden session variable for each field would be a lot easier with more flexibility.
I'll will see how it works out;

Turns out, in my case anyway, I don't have that many variables. Probably around 20 per page.

[Chris Iverson]

Ah, my bad, I got onChange mixed up with other programming languages. Yes, you're correct, it only fires(for text input fields) once focus leaves the element.

Let us know how it goes, it's always great to see people use LB in new ways!