somehow i am lucky able to log in again 
Some about tokenizer module class: The functions
<classvar>.Token(index).GetPosStart
<classvar>.Token(index).GetPosEnd
<classvar>.Token(index).GetLen
<classvar>.Token(index).GetLine
seems are not introduced by loadLocalSymbols - help file lists them but runtime experience is
| Error |
5100: A method or property was not found in class. |
Another - concerning
how to achieve? How can i detect from my module if such a "switch" is present?
All i've found was the optional string parameter to Function LoadLocalSymbols contains the module-path - but nowhere is any hint about the parameter in "USES" - do i have to load and parse the script for that?
And by mentioning load and parse: i've fallen in love with thinbasic-core-functions
Function_GetBodyCode
Function_GetSourceCode
which brought me to some weird ideas - working already with support of an include-file: the interpreter can interpret script-changes in real-time ("console interactive-mode")
i use it for visual design of windows by typing in and instant display the changes at a window-prototype on screen and store the typed-in data as thinbasic-code when i type "cf" or "confirm" and you will not even come to the idea that the same moment the console-content is saved and a new (embedded) "script-process" is started - it's so incredible fast when the (already previously registered window-class) new changed window appears on the same location while the previous one runs out by a timer just 1/10 seconds later you would not notice a thing. Only if the changed windows position does not exactly cover the previous one the illusion of a constantly running program is disturbed...
On the run...a general UI-makeover, direction THINBASIC V 2.0
i use a lot of illusion, and often i read in one of your "OOP"-script-samples the sentence it were not easy to create something as "ME" in a callback. So let me share an idea that is proven to work very well:
Don't forget:
We create the illusion of something in a way that users feel it were real - even it's not - they will not bother or complain if it appears logical and is correct in its context.
i let the user create a local variable of an udt
(which ensures the variable is valid and available) -
use a pretty simple hack which works from modules as well as from thinbasic-script:
'######################################################################################################################
'### GetLastName - use from module-class-constructors to obtain the name of the dimensioned class variable ###
'######################################################################################################################
FUNCTION GetLastName(BYVAL sList AS STRING) AS STRING
':::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
' pass
// Thinbasic_VariableGetList( ,";")
' to parameter sList
'....:....!....:....!....:....!....:....!....:....!....:....!....:....!....:....!....:....!....:....!....:....!....:....!
FUNCTION = RIGHT$( sList, LEN(sList) - INSTR(-1, sList, ";") )
'......................................................................................................................
END FUNCTION
(this is the module-version - in thinbasic you must watch for the stack-level - passing Function_GetStackLevel as parameter to the function is not recommended - since it evaluates to the stacklevel of the called function on its entrance - but stacklevel is required if using Thinbasic_VariableGetList from a script. )
I urge the user to exclude creation of objects outside of the TBMain-function in a way that
TBMain must be entered first,
from there a dedicated StartUp-function has to be called that returns True if StartUp was succesful.
(It will never return False but rather stops the execution in case of a problem)
my excuse is always:
Do not create local variables in TBMain because these variables are kind of special:
Such are persistant for duration of the scripts execution and theirs lifetime does not end before the script ends.
(Actually I intend to spread the idea that TBMain should not have "local" variables nor a "local scope" at all )
So i force to create an udt-variable local in a separate "Init + launch-procedure" and the user thinks,
his line:
Dim dlg_xyz As NewDialogOnDesktop
would really create the complete dialog - but what happens is:
Type tAnyDialogs_sharedAncestorType
hWnd As DWord ' (this just to have any property at all)
End Type
Type NewDialogOnDesktop _
Extends _
tAnyDialogs_sharedAncestorType
'....................................................................
UDT_Method _Create()
' here happens some real "MAGIC" !
End UDT_Method
'.....................................................................
End Type
abracadabra....
inside of udt-method NewDialogOnDesktop._create()
- it checks for the name of the users local variable ( "dlg_xyz")
- then app_inifile is checked for a section [dlg_xyz]
you can imagine what happens there...
- anyway the clue is: in NewDialogOnDesktop._create()
a new dialog named as the local user-variable in StartUp() is created.
- without the users knowledge i create a Hash-Table and
- store the hash-handle to the UI-object by
internally you should think of another place to hide it e.g. Api-function
setProp( hDlg, "secretPropertyname", mkDwd$(pHash) )
Always remember: if exit from function Startup the variable of type NewDialogOnDesktop will be destroyed.
What remains is a Dialog that
*** HAS THE SAME NAME ***
as the user named the local variable to create it.
(Remember this when you see *** again)
until here its already all doable, now...
The user will probably (for sure) store the "so important hDlg"
...
suggest 3+ New UI-module-functions:
DIALOG PROPERTY SET hDlg, <propertyname> As DataType [ = <initial_value>]
DIALOG PROPERTY LET hDlg, <propertyname> { = | , } <new_value>
DIALOG PROPERTY GET hDlg, <propertyname>
- where
<propertyname> is nothing but the key to a bucket of pHash
and SET creates it and tells you how to treat its content. LET to change and GET to obtain the value.
The very same functions should be accessible over the dialogs class using
<Dialogname>.Set <propertyname> As DataType
etc.
-since the "major-key" to the hash-table is attached to the class already-
And soon users can define their own properties to any dialog so very simple thanks to the hash-tables
Controls - i would consider - are dialogs major properties
theirs IDs in a hexadecimal format ($NUL can not be a hash-key)
... think that thought to your own end...
...simsalabim...
Anyway thinbasic should control the IDs (detect if a block "BEGIN CONTROLID- END CONTROLID" is present when USES "UI" = if none then thinbasic should allow the
<Dialogname>.Add<controlname> As <controlclassname>
check APP_Inifile or new UI_Inifile for a section matching
[<Dialogname>.<Controlname>]
and let the visual designer load and save this format = happy users...
if beginning a line with [ can have a meaning to UI-module? Maybe as a new Begin?
Begin UI
[<dialogname>]
Class=Dialog
Parent=DESKTOP ; or <Parentname>
Scaling=PIXELS
FontNames="Segoe UI","SpaceMono","Tahoma","Tahoma"
FontHeights=9, 10, 9, 11
FontStyles=0,0,0,1
Size=0.5, 0.4
Loc=0.25, 0.3
MinClientSize=240,160
ShowState=%SW_Normal
Style=%WS_DLGFRAME|%WS_CAPTION|%WS_SYSMENU|%WS_OVERLAPPEDWINDOW|%WS_CLIPCHILDREN|%WS_CLIPSIBLINGS
GradientType=<none>
GradientStart=0,0,0
GradientEnd=255,255,255
BGColor=0x20 0x40 0x80
FGColor=0xF0 0xB0 0x00
ImageFile=example.PNG
ImagePath=Media\Images\
ImageMode=Stretch
Caption="Am just a one-line-caption"
[<Dialogname>.<controlname>]
Class=Textbox
Text "Hello i am Text. I can be multiline"
Tooltip "Click on this object to experience something special"
Loc=4,4
Size=-8,-8
Resize=1,1,1,1
UseFont=2
End UI
relative meaning for sizes:
if a decimal dot (float value) is used the value is to multiply with the available client of the parent.
Size=0.5,0.4 means half of parents client width, 40% of parents client height.
thinkable: objects inside of other objects (viewports/tab-pages) can have multiple times theirs parents size. to prevent misunderstanding, if i set minsize 30,20 to something previously its units or pixels
but then i apply a size of 25,14.35 to this object its obviously no decimal point in the 25 but the minsize
of 30 clarifies: i want it 25 times the available client-size of the parent.
Size=-8, -8 negative sizes?
impossible to display this value - but to subtract it from parents available client size makes sense
same goes for locations...
This can be ini-file as well as thinbasic-ui-file
Callback-functions names
*** WILL CONTAIN THE SAME NAME ***
in their first part as for example
callback function dlg_xyz_OnCallback()
However you did achieve that a callback-function has Callback-variables as CBHNDL, CBCTL etc.
(or as Type-functions would refer to ME)
you can create on entry of a callback a local layover to an udt
Type DialogInCallback _
Extends _
tAnyDialogs_sharedAncestorType
'..........................................................................................
UDT_Method _Create( byval pHash As Dword )
' creation-parameter is the handle of the hash-table that stored and
' contains the mostly user-defined properties and settings of the dialog
' that was created as NewDialogOnDesktop
End UDT_Method
End Type
when you manage to create this variable on entry of a callback-function and grab (by CBHNDL)
Dword pHash = getProp(CBHNDL, "secretpropertyname")
the pointer to the hash-table to pass as creation-parameter of the udt-variable that you can simply
name ME - since the functions name (required - unnamed - other - functions can not work!) already tells
the name.
It's not the same "Me" as in an udt but who will notice it? How?
Anyway the user can create a local variable from anywhere but tbMain and from a callback where you provide it already and avoid the usage of the global objects name in a local variable again by ME -
even for the case the user wants to exchange controls on a dialog - except making it a non-mdi which was mdi previously there are no limits.
i just hope the idea became visible as imagination
Reply With Quote
Bookmarks