|
Post by Marco Kurvers on May 7, 2022 11:47:59 GMT -5
In Liberty BASIC 5 a Library works perfectly. To use it you need to pay attention to the following:
Make sure you only use functions in your library for now. Subroutines will not working. I think that it comes later. Program your code only in the functions. Do not programming the code outside the functions. For example, if you create a window outside the functions, the window will open automatically if you include the file as a library in your program.
Example:
library "program-name.bas", #lib
For use a function, do this:
x = #lib FunctionName() ' where the FunctionName is in the 'program-name.bas'
|
|
|
Post by Carl Gundel on May 7, 2022 11:57:15 GMT -5
In Liberty BASIC 5 a Library works perfectly. To use it you need to pay attention to the following: Make sure you only use functions in your library for now. Subroutines will not working. I think that it comes later. Program your code only in the functions. Do not programming the code outside the functions. For example, if you create a window outside the functions, the window will open automatically if you include the file as a library in your program.
Example:
library "program-name.bas", #lib
For use a function, do this:
x = #lib FunctionName() ' where the FunctionName is in the 'program-name.bas'
Thanks. LIBRARY is implemented to have a C style #include which people have been asking for. In addition, the LIBRARY command is from True BASIC which is a version of the original Dartmouth BASIC, as a nod to that.
|
|
|
Post by Marco Kurvers on May 18, 2022 12:29:52 GMT -5
Carl, I have found something more.
We don't really have to worry about just being able to write functions in a Library. I've tested features that don't return value and it works. For the time being, we must also perform such functions as normal functions in an assignment or in an expression. Not with a Call command.
But look out! For some reason, it's better to use these functions only in an assignment. I have discovered that if they don't get a value, the programmer get a surprise in the expression.
|
|
|
Post by Carl Gundel on May 18, 2022 12:34:28 GMT -5
Carl, I have found something more. We don't really have to worry about just being able to write functions in a Library. I've tested features that don't return value and it works. For the time being, we must also perform such functions as normal functions in an assignment or in an expression. Not with a Call command. But look out! For some reason, it's better to use these functions only in an assignment. I have discovered that if they don't get a value, the programmer get a surprise in the expression. Can you please be more specific? A code example please. Thank you.
|
|
|
Post by Marco Kurvers on May 24, 2022 11:08:26 GMT -5
Here's my explanation with example of what I mean.
Because we cannot yet write subroutines in a library, it is possible to write functions that work as subroutines. We can't call them with the CALL statement, but they don't have to return value either. These functions are an emergency solution as long as subroutines are not yet possible.
Normally we write a function as:
function MyFunc(x) MyFunc = x * 2 end function
But if we will a subfunction in a library, we can write this:
function MyFunc(year) print "Hello, you are "; year; " years old." end function
Because we don't call a function with the CALL statement, we do this:
x = #lib MyFunc(28)
Variable x does nothing, but the text 'Hello, you are 28 years old.' is printed on the mainwin.
I said too: 'Look out!". Why? If we try this:
print #lib MyFunc(48)
We get not an error, but two values. A string value and a zero value:
Hello, you are 28 years old. 0
You can see if there is not a return value in a function, the default value is always zero. If you will make a subroutine, the only way is to make a function without an expression assignment to the functionname. But do not print these functions.
|
|
|
Post by Carl Gundel on May 24, 2022 13:41:10 GMT -5
Here's my explanation with example of what I mean. Because we cannot yet write subroutines in a library, it is possible to write functions that work as subroutines. We can't call them with the CALL statement, but they don't have to return value either. These functions are an emergency solution as long as subroutines are not yet possible. Using CALL will be in LB5, as such: call #handle param1, param2
|
|
|
Post by Marco Kurvers on May 24, 2022 14:25:32 GMT -5
I have tried this, but I get an error. With a subname or only the parameters I get for both an error.
call #lib TestSub 2, 3 --> Syntax error
call #lib 2, 3 --> Syntax error
Later I thought maybe you mean that I can call the function with a call statement, but I that's a syntax error too.
.
|
|
|
Post by Carl Gundel on May 24, 2022 14:38:37 GMT -5
I have tried this, but I get an error. With a subname or only the parameters I get for both an error. call #lib TestSub 2, 3 --> Syntax error
call #lib 2, 3 --> Syntax error
Later I thought maybe you mean that I can call the function with a call statement, but I that's a syntax error too.Yes, it doesn't work yet. That's why I said that it 'will be', which is future tense.
|
|
|
Post by tsh73 on May 24, 2022 15:38:37 GMT -5
IMHO this is normal behavior. You did not set return value, so function returns 0, and you print it But function has an action within - that is text print So you get two lines printed: thing from within function, and returned 0.
|
|
|
Post by Carl Gundel on May 24, 2022 16:12:56 GMT -5
IMHO this is normal behavior. You did not set return value, so function returns 0, and you print it But function has an action within - that is text print So you get two lines printed: thing from within function, and returned 0. Yup. You nailed it.
|
|
|
Post by pierre on May 27, 2022 5:34:21 GMT -5
The new library function, as actually implemented in LB5 alpha build 353, only allows passing parameters by value.
Say, we have a variable 'b', value 50. We write a separate function to multiply this value by 2. The result can be printed from within the function to the main window of the calling program, which gives us the impression that variable 'b' is now 100, but this new value is not retained for further use and printing variable 'b' fromt he calling program will always give us 50.
Let's see what happens if we try to pass the variable by reference :
'------------------------------
calling program :
library "testlib.bas", #lib b=50 dummy = #lib multiply(b) print b end '------------------------------
library program "testlib.bas" :
function multiply(byref x) '<--------- !!! x = 2 * x end function
'------------------------------
This throws the following error :
message not understood #asByref after pressing OK we get: unhandled exeption: message not understood:#selectSourceForFrame
I found a workaround:
If we want to get the new value back into the calling program, whe have to pass the variable 'b' by value, then write a new function in the library file in order to capture this value and make another function call to retrieve it.
calling program :
library "testlib.bas", #lib b=50 dummy = #lib multiply(b) b = #lib getb() print b end '---------------------------------------
library program "testlib.bas" :
global b
function multiply(x) x = 2 * x b = x end function
function getb() getb = b end function
So, it is possible, but somewhat cumbersome..... Any ideas ?
|
|
|
Post by Carl Gundel on May 27, 2022 6:41:30 GMT -5
The new library function, as actually implemented in LB5 alpha build 353, only allows passing parameters by value. . . . So, it is possible, but somewhat cumbersome..... Any ideas ? You're right. I will try to solve this for v5.0, but I other more important things to do first. Obviously we don't want it to blow up, so it can be improved in that sense first.
|
|
|
Post by pierre on May 27, 2022 7:18:20 GMT -5
O.K. Thank you, Carl.
|
|
|
Post by Walt Decker on May 27, 2022 9:04:49 GMT -5
Since you know that passing a variable to a function by reference will not work do this:
B = 50 B = #lib Multiply(B) print B
FUNCTION Multiply(A) A = A * 2 Multiply = A END FUNCTION
|
|
|
Post by pierre on May 27, 2022 9:28:04 GMT -5
O.K. That is a shorter, by all means more elegant solution. Thank you !
|
|