ReneMiner
15-05-2024, 10:27
I wanted to parse part of a running tb-script from pb-module but all tries end in failure.
The idea was to add 2 new keywords and then to capture all script text after the first new keyword was invoked until the second new keyword is
encountered.
A sub is called from first keyword that will store the result as local static to a dedicated function for this purpose only, the second keyword must provide data (position, size) of a buffer where to write the already by the 1st sub assorted and filtered data, i.e. it will ignore functions within type-end type and just collect name, dimensions and datatype of subelements.
A small example
'---Load Console Module
Uses "Console"
uses "readType" ' the module intended to copy a type-definition from script into a buffer
'#ParseType - first new keyword just literally collects all data until runs into "#EndParse"
'#EndParse (byval pBuffer as Dword, byval lMax as Long)
dword hData = heap_alloc(1024)
#ParseType
type whatever
b as Byte
c as currency
d as double
End Type
#EndParse( hData,1024 )
Problem: with #-prefixed new keywords are not accepted by thinbasic
without the #-prefix the type-definition can not be parsed - the data seems to be removed from stack already and it does find NOTHING between the new keywords.
Reading code directly from script requires the script to be readable so this is not possible if scripts are obfuscated at all nor from bundled .exe since source-scripts names in temp-directory do not nescessarily match the executables name and do not reveil the order how thincore did concatenate these.
Helpful were a module-function that allows to read scripts code as the thinbasic-functions Function_GetBodyCode or Function_GetSourceCode -
but it were better to have a codeLine-Number
thinBasic_CodelineGet( byval lLine as Long ) as string
( a codeline that spreads via continuation over multiple text-lines would be returned ) and of course
the possibility to request the count of codelines to know the max. limit.
thinBasic_CodelineMax() as Long
Also for the exisiting script functions it were helpful to have a direct way to request the codeline where it starts as
thinBasic_CodelineOfScriptFunction(Byval fPtr as Dword, Optional byval sFuncName As String) As Long
to allow using optional script-functions name or its pointer
The codeline-reading function would never take anything from stack.
The advantage over the by new keywords framed code?
Think of multiple modules using that approach that require to wrap the portion of some code in order to have some information available...
The idea was to add 2 new keywords and then to capture all script text after the first new keyword was invoked until the second new keyword is
encountered.
A sub is called from first keyword that will store the result as local static to a dedicated function for this purpose only, the second keyword must provide data (position, size) of a buffer where to write the already by the 1st sub assorted and filtered data, i.e. it will ignore functions within type-end type and just collect name, dimensions and datatype of subelements.
A small example
'---Load Console Module
Uses "Console"
uses "readType" ' the module intended to copy a type-definition from script into a buffer
'#ParseType - first new keyword just literally collects all data until runs into "#EndParse"
'#EndParse (byval pBuffer as Dword, byval lMax as Long)
dword hData = heap_alloc(1024)
#ParseType
type whatever
b as Byte
c as currency
d as double
End Type
#EndParse( hData,1024 )
Problem: with #-prefixed new keywords are not accepted by thinbasic
without the #-prefix the type-definition can not be parsed - the data seems to be removed from stack already and it does find NOTHING between the new keywords.
Reading code directly from script requires the script to be readable so this is not possible if scripts are obfuscated at all nor from bundled .exe since source-scripts names in temp-directory do not nescessarily match the executables name and do not reveil the order how thincore did concatenate these.
Helpful were a module-function that allows to read scripts code as the thinbasic-functions Function_GetBodyCode or Function_GetSourceCode -
but it were better to have a codeLine-Number
thinBasic_CodelineGet( byval lLine as Long ) as string
( a codeline that spreads via continuation over multiple text-lines would be returned ) and of course
the possibility to request the count of codelines to know the max. limit.
thinBasic_CodelineMax() as Long
Also for the exisiting script functions it were helpful to have a direct way to request the codeline where it starts as
thinBasic_CodelineOfScriptFunction(Byval fPtr as Dword, Optional byval sFuncName As String) As Long
to allow using optional script-functions name or its pointer
The codeline-reading function would never take anything from stack.
The advantage over the by new keywords framed code?
Think of multiple modules using that approach that require to wrap the portion of some code in order to have some information available...