thinBASIC 1.9.16.X

[ReneMiner]

I have an Error- but i have no time to locate the cause. My girlfriend is annoying me to play something...

I loaded the above posted AVL-Tree-example into thinICE- then let it run (f5)
after ending your sample and thereafter try ending thinICE by pressing esc-key i get message of undeclared variable in tControl_Codefield.InputKeyboard line 2471
(bResult) which is a static and declared for sure few lines above (2467)

[primo]

Thank You Eros for adding open recent files/open from recent paths. this makes life easier

[ReneMiner]

I've found a solution for the above described "bug", it's caused by order.

Will need a few hours to check all my scriptunits and apply the rule i've found.

Local Static variables inside functions must be very first within the function.

This is valid syntax:

' CORRECT :)

Function f()
  Static bStatic As Boolean    ' static first!
  
  If <condition> Then Exit Function
End Function

this is not valid - illegal - bad - do not do this:

' WRONG ! WRONG ! WRONG ! :(

Function f()
  If <condition> Then Exit Function 

' never exit a function before local statics are declared!
  
  Static bStatic As Boolean

End Function

' WRONG ! WRONG ! WRONG ! :(

+++

to thinBasic-Helpfile,
concerning AVL-tree.

the below listed functions have a wrong parameter-name (pHash instead of pTree) in parameters table:
Tree_Clone
Tree_Exists
Tree_Get
Tree_Validate

[ErosOlmi]

Thanks René for founding that.

In thinBasic local variables are allocated when they are encountered.
If function exits before encountering a variable declaration, that variable is not declared.

There are some internal optimizations that can be influenced by the above behave like:

• when a script function is executed the very first time, thinBasic keep track of the allocated variable and function parameters.
  From the second execution it optimize local function stack using the counter variable, counted during first execution.
  If not all variables were encountered during first execution, something weird can happen (usually a GPF)
• static variables are allocated not in function execution stack (that is local to the execution and destroyed when function execution ends) but inside internal function data structure (one for each script function) and never destroyed. This because static variables must retain their value across function executions. If a static variable is not visible the very first time a function is executed, a GPF can occurs.

I will see if I can optimize something on this aspect.

Ciao
Eros

[ReneMiner]

I know it's very nice to have the ability to declare variables on-the-fly.
From the other view it would be easier to handle for thinCore if all variables are listed on top of the function.
Many programming-languages have this condition mandatory and i would not mind if i had to if it helps to stabilize execution.
In fact i will try to follow that rule in future.


What do these:

Function_GetBodyCode
Function_GetSourceCode

???

PS. see my post above again for some minor "help-file-repairs"

[ErosOlmi]

What do these:
Function_GetBodyCode
Function_GetSourceCode

Experiments for future ideas.
Both require a function name as string parameter.
One return full function code, the other just the inner part.

PS. see my post above again for some minor "help-file-repairs"

Thanks, fixed for the next release.

[ReneMiner]

Very nice.
I tried a simple as:

'#FILENAME "Function_GetCode.tBasic"

' --------------------------------------------------------------------
Function TBMain()
' --------------------------------------------------------------------
 
  MsgBox 0,  Function_GetBodyCode( "TBMain" ),
    %MB_OK, "Function_GetBodyCode(""TBMain""):"
  
  MsgBox 0,  Function_GetSourceCode( "TBMain" ), 
    %MB_OK, "Function_GetSourceCode(""TBMain""):"
  
 
End Function

and i made an executeable bundle of it.
Still works and has the same output even if not a thinBasic-file any more...

[ReneMiner]

2 * Hash-tables:


1.
If i want to use a hash-table to store data its likely the case that my data-elements (mostly udts or arrays) may have more data noded to it.

Lets say, i store my control-udts of every window in a seperate hash table and want to destroy some data and i need a list of all keys to call _Destroy() on the stored udt-data (for example to free noded multiline-text)

I wish for a function that does this:

String myList()
Long numKeys = Hash_ListKeys pHash Into myList

2.
My keys shall hold some information about the data so i already know from the key what it is and if to proceed it

alike:

' create hash-table:
Dword pControls = Hash_New(500, %Hash_String2String)
'...

' create a control:
Dim lButton As tControl_Button
' assume i use some enumerating-functions here to store Type and Name ;)

lButton.pType  = Heap_AllocByStr("tControl_Button") 
lButton.pName = Heap_AllocByStr("myButton")
lButton.Index   = 1
'... some more settings here but this serves...

' this be the header of my basetype
' its 2 Dwords, 1 Long = 12 Bytes

' and i want that information to be my key:
String myKey  = Memory_Get(Varptr(lButton), 12)

Hash_Set( pControls, myKey, lButton )

but what about the nulls that a hash-String-key must not contain?

Were it possible to have a "Byte"-key, probably with a fixed same lenght for all keys of this hash-table?

Dword pControls = Hash_New(500, %Hash_Byte2String, 12)

- or would i have to convert my key into a size-formatted Hex$?

[ErosOlmi]

Regarding point number 1:

• yes, I already thought about something similar
• thinCore already use something like that
• should not be that complex to develop

Regarding point number 2:

• quite complex at the moment to have nulls inside keys
• HEX conversion is something you can do but would slow down operations because done at script level
• maybe I can get HEX idea and use inside compiled code
• let me think a bit about that

[ReneMiner]

As PeekHex$ | Memory_HexGet & PokeHex | Memory_HexSet ?
(Peek could be optimized by creating sResult in correct size once instead of to compose it

 
' #Filename "ConvertHex.tBasic"
Uses "console"

' --------------------------------------------------------------------
Function TBMain()
' --------------------------------------------------------------------
  
  String data = MKDWD$(123, 456) & MKL$(789)
 
  Local dw1 As DWord At StrPtr(data)
  Local dw2 As DWord At StrPtr(data) + 4
  Local l   As Long  At StrPtr(data) + 8
  
  PrintL dw1, dw2, l
  
  Long nBytes = StrPtrLen(StrPtr(data))
  
  String sKey = PeekHex$(StrPtr(data), nBytes)
 
  
  PrintL "key: " & sKey
 
  ' overwrite data with 0:
  Memory_Set(StrPtr(data), Repeat$(nBytes, MKBYT$(0)))
  
  PrintL "data empty now:", data
  PrintL dw1, dw2, l
  
  ' poke the key into data-space
  
  PokeHex$(StrPtr(data), sKey)
  
  PrintL dw1, dw2, l
  
  Printl $Crlf & "key to end"
  WaitKey  
  
End Function

' ---------------------------------------------------------------------  
Function PeekHex$(ByVal pData    As DWord, _
                  ByVal numBytes As Long   _
                   ) As String
' ---------------------------------------------------------------------
  ' convert a sequence of bytes into Hex$ 
  ' returns hex-expression
  
  Local b As Byte At pData
  Local sResult As String 
  
  Do
    sResult &= Hex$(b, 2)
    SetAt(b, GetAt(b)+1)
    numBytes -= 1
  Loop While numBytes 
  
  Function = sResult
  
End Function                   

' ---------------------------------------------------------------------
Function PokeHex$(ByVal pData As DWord, _
                  ByVal sData As String _
                  ) As String
' ---------------------------------------------------------------------
  ' convert a Hex$ into bytes and poke it to given pointer
  ' sData must not contain Hex-prefix as "&H" nor "0x"
  ' returns converted memory
  
  Local B(2) As Byte At StrPtr(sData)
  Local num  As Byte At pData
  
  While GetAt(b) < StrPtr(sData) + StrPtrLen(StrPtr(sData))
    num = Val("&H" & Chr$(b(1), b(2)))  
    SetAt(b, GetAt(b) + 2)
    SetAt(num, GetAt(num) + 1)
  Wend
  Function = Memory_Get(pData, StrPtrLen(StrPtr(sData))/2)
  
End Function