|
|
Post by Walt Decker on Dec 5, 2020 16:33:37 GMT -5
1. For what is CALLFN used?
2. Are WindowWidth/WindowHeight client sizes or window sizes?
3. Does LB use one class template for registerclassex()
4. Are string variables wide string or ANSI?
5. Why are buttons pinned to a corner while other controls are not?
6. What is PTR, i. e. is it a pointer to the actual data address or a pointer to the data description?
Delving farther into PTR, does it provide an address where data can be changed but not
accessed?
7. Why does:
CALL SomeSub Varb.1 AS PTR
produce a syntax error?
8. Since variable names are case sensitive is #fetch different from #FETCH?
9. When establishing a branch for a window or control:
a. Can the branch be a function?
b. I have noticed that if a branch is a sub it has only one argument. That argument,
aparently is then handle of some window or control. Can it have more than one? If
so, what do they contain?
10. Many common controls, e. g. scrollbar, treeview, send specialized messages, e. g.
WM_VSCROLL/WM_HSCROLL, WM_NOTIFY. How would one trap those messages?
11. With MENU is there a way to make sub-submenu items?
|
|
|
|
Post by Carl Gundel on Dec 5, 2020 17:50:26 GMT -5
1. For what is CALLFN used? Interesting. I must have intended to use CALLFN for something a long time ago, but it does nothing. Window sizes. I'll have to take a look, but that is code that is managed by libraries that I didn't write. Is LB not behaving as you expect for some reason that you suspect is related to this? ANSI. That was an ill considered idea. I should make the corner orientations optional in LB5. There will be a better way to do layout. I believe that it is a pointer to data which is copied temporarily out of the Smalltalk object memory space, and then when the call is finished it is copied back in. You can also allocated and lock memory yourself. Liberty BASIC doesn't support PTR unless you are calling external functions, and for use with structs which are also for calling external structures. They are unique. button #one.ok, "OK one", [okone], UL 10, 10, 100, 25
open "one" for window as #one
button #ONE.ok, "OK ONE", [okONE], UL 10, 10, 100, 25
open "ONE" for window as #ONE
wait
[okone]
close #one
if ONEClosed then print "done." : end
oneClosed = 1
wait
[okONE]
close #ONE
if oneClosed then print "done." : end
ONEClosed = 1
waita. No b. It can only have one argument. You can use a popular DLL called wmliberty.[/quote] www.b6sw.com/No, but there will be with LB5. |
|
|
|
Post by Carl Gundel on Dec 5, 2020 18:31:57 GMT -5
1. For what is CALLFN used? Interesting. I must have intended to use CALLFN for something a long time ago, but it does nothing. Okay, looking into the code CALLFN is a keyword used in compiler inline generated code. I probably should have named it something like CALLFNINLINE or some other unlikely name. Did you discover it by accident innocently using it was a name in your own code, or did you find some obscure reference to it in the docs somewhere? |
|
|
|
Post by Chris Iverson on Dec 5, 2020 21:48:17 GMT -5
Possibly docs, there's a reference to it in the "Reserved Words" page in the helpfile.
|
|
|
|
Post by Carl Gundel on Dec 5, 2020 23:30:31 GMT -5
Possibly docs, there's a reference to it in the "Reserved Words" page in the helpfile. Well, it is a reserved word after all.  |
|
|
|
Post by Stefan Pendl on Dec 6, 2020 5:47:20 GMT -5
May be it was used because of its presents in QBASIC programs.
People mostly use any BASIC code and run it to check what needs to be changed to port the code from a different BASIC dialect.
|
|
|
|
Post by Walt Decker on Dec 6, 2020 12:57:07 GMT -5
CALLFN I pulled out of the docs in the "reserved words" section.
At this point I do not know enough to expect anything. It just seemed the logical choice
for an interpreted language and that knowledge will give me a better idea of what I can do
in native LB.
I am not clear on PTR.
"FUNCTION SomeFunc" is bogus; however, in a DLL I have one similar.
Function code:
FUNCTION SomeFunc ALIAS "SomeFunc"(BYVAL TxtPrt AS DWORD) EXPORT AS LONG
'TxtPtr = unsigned address of text
LOCAL TxtLen AS LONG '<--- # of bytes in string
LOCAL TxtIn AS STRING '<--- temporary string
LOCAL PtrTxt AS STRING POINTER '<--- pointer to string
PtrTxt = TxtPtr '<--- create a pointer to the text string
TxtIn$ = @PtrTxt '<--- get the string and put it in another string
TxtIn$ = "This is NOT some text"
TxtLen = LEN(TxtIn$) '<--- get # of bytes in string
@PtrTxt = TxtIn$ '<--- set the input string
SomeFunc = TxtLen '<--- return # of bytes in new string
END FUNCTION
Calling code:
OPEN "SomeDLL" FOR DLL AS #DllCall
Txt$ = "This is some text"
RetVal = 0
CALLDLL #DllCall, "SomeFunc", Txt$ AS PTR, RetVal AS ULONG
Intuitively, "Txt$ AS PTR" should be pointing to the first byte of Txt$. The function
should be able to access that address and use the data pointed to for its purpose.
The explanation appears to indicate that the data can not be changed. In fact, when
trying to access the data pointed to at address "Txt$ AS PTR" a GPF(memory protection violation)
is generated at "TxtIn$ = @ptrtxt."
Memory allocation and locking: does that have to be accomplished via API?
PRINT #Win, "TrapClose Qsub" produces a syntax error where Qsub is a SUB defined
elsewhere. This implies that an app cannot be ended in a sub. Is that correct?
|
|
|
|
Post by Chris Iverson on Dec 6, 2020 21:51:11 GMT -5
Couple of things in that code, but I don't know if it's a contrived example or copied from somewhere and renamed. I don't know what language that is, either, so I'm making some guesses. Feel free to correct me if I guess wrong.
1. "BYVAL TxtPrt AS DWORD" if you're passing a pointer, wouldn't that have to be BYREF? BYVAL assumes a copy of the data is made, BYREF assumes a pointer to the data is made, generally.
2. The incoming parameter is named "TxtPrt", but you refer to it later as "TxtPtr". If that typo is in the live code, you're likely crashing because you're dereferencing a null pointer.
For memory allocation and locking: yes, it has to be done via the Win32 API. All of the memory management functions provided by Win32 are available to you, but it's up to you to copy memory to/from those regions you create.
As for subroutine close handlers, I don't seem to see a problem?
'Form created with the help of Freeform 3 v07-15-08
'Generated on Dec 06, 2020 at 20:49:15
[setup.main.Window]
'-----Begin code for #main
nomainwin
WindowWidth = 550
WindowHeight = 410
UpperLeftX=int((DisplayWidth-WindowWidth)/2)
UpperLeftY=int((DisplayHeight-WindowHeight)/2)
open "untitled" for window as #main
print #main, "font ms_sans_serif 10"
print #main, "trapclose Quit"
[main.inputLoop] 'wait here for input event
wait
sub Quit hndl$
close #main
end
end sub
|
|
|
|
Post by Brandon Parker on Dec 6, 2020 22:41:11 GMT -5
1. For what is CALLFN used? Interesting. I must have intended to use CALLFN for something a long time ago, but it does nothing. Carl, You have been holding out on us all these years .... ?! It looks like CallFN actually calls the function specified. Now if you could use a variable or even Eval$() in the place of the hard-coded function name, that would be awesome. CALLFN test2()
End
Function test()
Print "Test"
End Function
Function test2()
Print "Test 2"
End Function{:0) Brandon Parker |
|
|
|
Post by Carl Gundel on Dec 6, 2020 22:54:27 GMT -5
Interesting. I must have intended to use CALLFN for something a long time ago, but it does nothing. Carl, You have been holding out on us all these years .... ?! It looks like CallFN actually calls the function specified. Now if you could use a variable or even Eval$() in the place of the hard-coded function name, that would be awesome. CALLFN test2()
End
Function test()
Print "Test"
End Function
Function test2()
Print "Test 2"
End Function{:0) Brandon Parker Sorry, but what does this do for you that just writing a sub doesn't do? |
|
|
|
Post by Brandon Parker on Dec 6, 2020 22:55:47 GMT -5
CALLFN I pulled out of the docs in the "reserved words" section. Walt, The code below works for me. I have used the abbreviated syntax for setting the TrapClose command; basically, you do not have to you "Print" and when you do not you can omit the comma between the window handle and the command string. Are you sure you just did not add the "handle$" variable to the sub? When using subroutines for event handlers, you have to have a variable as a parameter (the name does not matter; some need two handles - see GraphicBox events). You technically do not have to use the variable, but by doing so, you could use the same subroutine to do the same thing for various controls. In this case, you could use it as the close event handler for another window if you wanted. You could even check the handle$ variable inside the subroutine using a "Select Case" statement and perform various actions for specific windows. Take a breather and digest the help file one piece at a time. NoMainWin
Open "Test" For Window As #Win
#Win "TrapClose Qsub" 'Same as (Print #Win, "TrapClose Qsub")
Wait
Sub Qsub handle$
Close #handle$
End
End Sub{:0) Brandon Parker |
|
|
|
Post by Brandon Parker on Dec 6, 2020 22:59:25 GMT -5
Carl, You have been holding out on us all these years .... ?! It looks like CallFN actually calls the function specified. Now if you could use a variable or even Eval$() in the place of the hard-coded function name, that would be awesome. Sorry, but what does this do for you that just writing a sub doesn't do? Oh, it does nothing in its current form. Sarcasm is difficult to portray across the screen ...   If I could have done this then it would have been cool... functionName$ = "test2()"
CALLFN functionName$ 'or CALLFN Eval$(functionName$)
End
Function test()
Print "Test"
End Function
Function test2()
Print "Test 2"
End FunctionWhatever you do, DO NOT use CALLFN with a function that has a variable being passed to it. BOOOOMMMMM!!!! {:0) Brandon Parker |
|
|
|
Post by Rod on Dec 7, 2020 3:22:00 GMT -5
I suspect the trap close issue was a missing , we need to use print #handle, command or #handle command. We had a syntax change away from print but you will still find the old format in many places.
|
|
