Variable scope suggestion

[DirectuX]

Hi,

Currently and according to the documentation, for a given variable there can be :


Local scope inside a sub or function,
Global scope inside a script,

to the extent of my knowing and at this stage of thinBasic developpement, there can't be an Include scope
which could be useful when splitting a script into reusable/shareable parts between projects
and assuring there will be no variable-name conflict.

Actual workaround is to manually prefix each variable to make distinction.

Same idea for subs/functions ?


Your opinion ?

[ReneMiner]

Maybe you could use Private scope if you try to stick to type-oriented programming.
It's like


Type t_TypeWithAPrivate
Private
mySubelement As Byte
Public
anotherSubelement As Word
'...
' Me.mySubelement is only accessible
' inside functions
' between Type - End Type...
End Type
Dim foo As t_TypeWithAPrivate
' foo.anotherSubelement is accessible from
' anywhere in the project


If you create each include-file - including it's own variables and functions - as a Type then it's possible to use dot-notation. Always Me.varName within the code-unit (between Type and End Type) else prefix the unit with a fitting name (foo in the example), something like
"SE" - sound-engine
"BUG" - error-handler
"DX" - your directX wrappers...

[DirectuX]

Hi,

Yes, TYPE would reduce the name-conflict risk to one variable, let the functions.
Goal is indeed to avoid name conflict. But I surely misunderstand this :


If you create each include-file - including it's own variables and functions - as a Type
Do you mean wrap TYPE / END TYPE around the whole included code ?


else prefix the unit with a fitting name (foo in the example), something like
"SE" - sound-engine
"BUG" - error-handler
That's how I started but it's heavy, especially since thinAir's autocomplete doesn't suggest user defined variables or functions.

[ReneMiner]

Yes of course Type-End Type around the whole code-unit. The only thing outside Type-End Type would be for example:

Dim DX As t_DirectX


Hmm, the auto-complete... Yes...

Eros !!?

How about reviving the tbProject-file-extension ???
Could be easier if a tbProject-file contains all
-global external function-declarations,
-included code-units (a global variable for each)
-global dimensioning
-Function TBMain()

Built-in to the tbProject-file should be directives:

Option Explicit
No untyped subs nor functions outside the tbProject-file
No global variable-dimensioning nor external function-declarations (.DLL) nor #include-statements in any other code-unit than in the TBPROJECT-FILE.
All additional code-units only persist of Type-definitions
A code-unit will be included in a way like

#Include Global DX As "myDirectX.tBasicU"

The first codeline of myDirectX.tBasicU must start with
Type ...(no matter the name, Extends invalid here)
and ends with
End Type

anything below End Type in this file will be ignored.
:(
...
:)
Better may be
Alias Type As CodeUnit
In the example:

CodeUnit myDirectX
' this is my directX-wrapper
...
End CodeUnit

So it's possible to define other Types here and the code above CodeUnit or below End CodeUnit can hold UDT-definitions.

Declarations of Functions from external libraries within CodeUnit and End CodeUnit could be possible... As udt-subelements!
Those were local to the CodeUnit.

Example ( I return to Type-syntax for better understanding)


Type myDirectX
Declare Function XXX Alias "XXX_ex" Library "dxlib.DLL"(parameters) As Long
End Type

Dim DX As myDirectX
Long foo = DX.XXX(parameters)



Perhaps with rules and directives like that it will be possible to maintain backward-compatibility and make a step into direction TOP (type-oriented-programming)
as well as having auto-complete for udt-variables

On the other hand, is there a code-browser as in the old thinAir that lists properties (subelements & functions) of udts?

[DirectuX]

Yes of course Type-End Type around the whole code-unit. The only thing outside Type-End Type would be for example:
Dim DX As t_DirectX
That! It is something different. I wouldn't never guess that MemberName could represent a function.



TYPE

Description
Define a User-Defined Data Type (UDT), containing one or more member elements.

Syntax

TYPE MyType [BYTE | WORD | DWORD]



[STATIC] [MemberName AS TypeName]

[STATIC] [MemberArrayName[(nElements)] AS TypeName]


[...]

END TYPE

source: https://www.thinbasic.com/public/products/thinBasic/help/html/type.htm





Could be easier if a tbProject-file contains all [...]
Except this wouldn't answer the original difficulty. You couldn't have an autosufficent-include this way, or I missed something.
It's a different feature, interesting, but different.

I would add about that, that there is no need to have a separate file, to keep it simple, one can make use of something like #Region / #EndRegion.

Still, the user definitions recognition (equates, functions with param, vars) is, to my eyes, a must for thinAir.

[ReneMiner]

I suggest this thread
https://www.thinbasic.com/community/showthread.php?12874-ThinBASIC-User-defined-types-micro-book
to learn more about the fantastic abilities of user defined types in thinBasic

[DirectuX]

:yes:
I already had a glance at Petr's UDT book but missed the §1.4.2 UDT Function. Thanks to point that out to me.

[ReneMiner]

Auto-complete of thinAir should be improved then.
I know if all of the source-code has to be scanned in real time it will make the handling/typing slow and laggy.
That's why I thought the tbProject-file containing all global dimensioned/declared stuff it would need to "refresh" those internally only when the input-focus changes to another CodeUnit or if the user explicitly clicks on a refresh-button.
To scan local if cursor within a function then it will be fast enough in real time - I tried already, I know that ;) -someone might remember my thinICE-project that kicked an avalanche off the tB-hills :D

Some code-overview (tree) that shows everything in a structured way is a very nice tool - not only for the user to look at but also to pick expressions that should show up in auto-complete


If cursor within a type-function it's still OK to scan from Type to End Type, if outside a type-function but between type and end type it's obsolete to scan since the Type-definition is currently about to be changed...

[DirectuX]

someone might remember my thinICE-project
Seen with screenshots on the forum. :)


I know if all of the source-code has to be scanned in real time it will make the handling/typing slow and laggy.
That's why I thought the tbProject-file containing all global dimensioned/declared stuff it would need to "refresh" those internally only when the input-focus changes to another CodeUnit or if the user explicitly clicks on a refresh-button.
To scan local if cursor within a function then it will be fast enough in real time

It is sufficient to

scan the line of code that was changed, relevant event is cursor's line-change.
scan any pasted piece of code (rare lag may be acceptable here)

Of course, there is a full scan at loading.


but between type and end type it's obsolete to scan since the Type-definition is currently about to be changed...
What ?

[ReneMiner]

Example


Type tType

' if cursor here no need to scan this udt
' because it's about to be changed
Function myfunc()
' here this udt and the variables/parameters of
' this function have to be scanned until scan
' finds keyword End or another Function or
' unknown As vartype

[DirectuX]

it's obsolete to scan since the Type-definition is currently about to be changed..
sorry, I interpreted this as veraltet, about to change in thinBasic, not by the user :D




Example


Type tType

' if cursor here no need to scan this udt



why not?, for autocomplete, take all user naming:

variables/const names, functions names, subs names, types names, equates names, aliases names.

in your example (TYPE),
a var name will be suggested when Me.variableName
a function name will be suggested when MyTypeInstance.functionName()

[ReneMiner]

Auto-complete of thinAir should be improved then...


Some code-overview (tree) that shows everything in a structured way is a very nice tool - not only for the user to look at but also to pick expressions that should show up in auto-complete

...

As seen here: on the left the code-tree, in the right window the auto-complete suggests when typing a global udts name or keyword Me followed by dot everything that could follow since it's a member of tArray
https://www.thinbasic.com/community/attachment.php?attachmentid=9408&d=1448646570
It scans the global area when loading, saving, switching to another code-window or click on "Refresh" and lists variables dimensioned as global as well as their type, if array etc. (They would be visible in the "Globals"-tab) and scans real-time the local code-area (inside current function only) so it can suggest useable keywords and global variables from the globals-tab or udt-members or function-parameters from code-tree as well as local variables that were found the moment when spacebar after ReDim was pushed here:
https://www.thinbasic.com/community/attachment.php?attachmentid=9509&d=1452772925

[DirectuX]

:cool:

now what thinIce can't do that thinAir can ?

[ReneMiner]

:cool:

now what thinIce can't do that thinAir can ?

Simple answer:
thinICE will no more been IMPROVED :D

[DirectuX]

Hi, ReneMiner,

I'm reading your thinICE code, #SCRIPTVERSION 0.6.1.0 ,
some questions :


is it the last version ?

you use tbasicU file extension, sole reference (it is too much to call this reference) I found is there : https://www.thinbasic.com/public/products/thinBasic/help/html/include.htm?zoom_highlightsub=tbasicU (https://www.thinbasic.com/public/products/thinBasic/help/html/include.htm?zoom_highlightsub=tbasicU) . What's different of standard .tbasic except file-naming ?

also I can't run it. I cant' find the cause. Thinbasic raise an error but the code seems correct according to this page : https://thinbasic.github.io/book-thinbasic_user_defined_types/chapter_01-04-02-udt-function.html. In addition, I tried the _create function in my code too and it didn't work either. Can you confirm the issue ?

[ReneMiner]

I am sorry I can not test this because I do not have a PC.
Only I can suggest to check the thinBasic-beta- archives for version 1.9.16.16

But it's tricky !
Before you download and install:

Rename your original "c:\thinbasic" folder, do not overwrite it.
Then test.
Thereafter you might erase the folder containing version 1.9.16.16 and rename your original folder to c:\thinBasic again.

It will not work if you try to install 1.9.16.16 next to the new thinbasic to another path ( thinICE will check the registry where thinBasic is installed on your system and also Windows will open and run ".tBasic"-files using thinBasic.exe.

DO NOT OVERWRITE CURRENT TB-VERSION WITH THE OLD ONE!

For the. tBasic & .tBasicU- extensions:
A project should have 1 .tBasic- (desktop application) or .tBasicC- file (console-application) where to find the code to be executed for this current project and as many .tBasicU (additional units containing supporting routines, functions) or .tBasicI/.inc (include files, containing mostly declares, constants) as required.

[DirectuX]

I am sorry I can not test this because I do not have a PC.
Only I can suggest to check the thinBasic-beta- archives for version 1.9.16.16
Don't have to feel sorry, it's just a fact.
Just checked, got it run until a halt in tControl_Codefield.tBasicU (a while/wend without end according to thinbasic), also kb setting is ineffective. No matter, I got a global picture and your code is instructive! :read:




For the. tBasic & .tBasicU- extensions:
A project should have 1 .tBasic- (desktop application) or .tBasicC- file (console-application) where to find the code to be executed for this current project and as many .tBasicU (additional units containing supporting routines, functions) or .tBasicI/.inc (include files, containing mostly declares, constants) as required.

Correct me if I'm wrong: it's just semantic for the programmer; No matter the name of the include, thinbasic treats it as being part of the main script, and thinAir makes no distinct handling ? Right ?
So far I have only .tbasic files like this: GUI.tbasic HELPERS.tbasic FS.tbasic ... all included once in myproject.tbasic

[ReneMiner]

The file-extensions as tBasic or tBasicC matter on creating .exe (executable) I think. Something that it will open thinBasic-console-windows or use the ms command prompt. But ain't sure how and which and if other extensions have similar effects

Edit:
I suspect it's easier to find for a user if he wants to start a thinbasic-project from windows-explorer directly instead of starting in thinAir by double-clicking on the tBasic-filename in explorer-window

[DirectuX]

instead of starting in thinAir by double-clicking on the tBasic-filename in explorer-window
there is some obsolete information in thinAIR help file (dialogs screenshots doesn't correspond to actual thinAir)
I've just made a test because so far I had never try to double click the thinbasic files in explorer :



.tbasic

thinAir calls it thinBasic GUI file
has tbicon
double click : file gets interpreted directly, thinAir doesn't show up
right click : open or modify or debug



.tbasicU

thinAir calls it thinBasic unit file
has no particular icon (white sheet)
double click : file gets opened in a new tab in thinAir
right click : nothing valuable


.thinVD

thinAir is not aware of this extension
has no particular icon (white sheet)
double click : is not associated with any executable (does not open from windows's file explorer)
is thinBasic Visual Designer's save-file
right click : nothing valuable



.tbasici

thinAir calls it thinBasic include
has tbicon
double click : file gets opened in a new tab in thinAir
right click : nothing valuable



.tproject

thinAir calls it thinBasic project file
has tbicon
double click : file gets opened in a new tab in thinAir
right click : nothing valuable
thinAir do not offer to create such file



there is other extension about templates, I didn't try them.

[DirectuX]

.tproject

thinAir calls it thinBasic project file
has tbicon
double click : file gets opened in a new tab in thinAir
right click : nothing valuable
thinAir do not offer to create such file

[/INDENT]



found this in the forum, it's about .tproject files


Sorry René but it was an old feature written by Roberto Bianchi (original author of thinAir) that I never ported to the new thinAir when Roberto left the project and oblidge me to rewrite thinAir almost from scratch.

Something in the todo list but never had time to realize.

[DirectuX]

Hi, ReneMiner,

I'm reading your thinICE code, #SCRIPTVERSION 0.6.1.0 ,
some questions :

also I can't run it. I cant' find the cause. Thinbasic raise an error but the code seems correct according to this page : https://thinbasic.github.io/book-thinbasic_user_defined_types/chapter_01-04-02-udt-function.html. In addition, I tried the _create function in my code too and it didn't work either. Can you confirm the issue ?


following the previous manipulation I get to the idea to test this with the previous version of thinBasic too. The _create function runs well with v1.10.5. Regression ? just as a reminder for v1.10.6 I'll create a post in the support section (https://www.thinbasic.com/community/project.php?issueid=552).

[ReneMiner]

I remember, yes. It's unused but as already said it offers a possibility to create a new way of coding.
It's obvious that thinBasic already allows to write code very much type-oriented and I would go so far to make it mandatory - but for backward-compatibility it is OK to keep the classic way of coding as is.

I already described a few rules above in this thread but there's still more...

UDTs can be the base to everything here, currently there's only one kind of UDT ("Type") that we use...

The simplest kind of specialized UDT would be an enumeration.
It would be an UDT that is unique, cannot be Extends'ed, all udt-subelements are static/constant and all sub elements are of the same type.



' currently we can do this
Type tFigure
Static Point As Long = 1
Static Line As Long = 2
Static Triangle As Long = 3
Static Rectangle As Long = 4
'...
End Type
Global Figure As tFigure

' since the enumeration will be unique,
' only one variable of it will exist
' it can not Extends nor been Extends'ed
' all subelements are static public
' all subelements are of the same type (here Long)

Alias Type As Enumerate
' replace keyword Type through Enumerate
' to signalize this is a special UDT
' following the rules above:

Enumerate Figure As Long
Point = 1
Line = 2
Triangle = 3
Rectangle = 4
'...
End Enumerate
' on "End Enumerate" a global variable
' "Figure As tFigure" should be dimensioned
' now we should be able to use f.e.

Long myShape = Figure.Triangle


Another kind of specialized UDT were a CodeUnit as described before in this thread. It's special abilities that differ from regular UDT were - similar to Enumerate - that only 1 global variable of every codeunit can exist. So on "End CodeUnit" the global variable representing the unit could be dimensioned.

A third kind of specialized UDT could be a window.
It should have a new kind of subelements and it would be part of a new, type-oriented UI-module.
So to say a mix of Type with a Window and Controls.


Uses "UI"
' without "UI" a window cannot be
Alias Type As UIWindow

UIWindow t_myWindow [Extends anyOther]
ExitButton As Control Button
Scroll(2) As Control Scrollbar
'...
Function _create()
' init & position the controls here...
End Function

Function _destroy()
' release resources here, save maybe
End Function

Function ExitButton_OnClick()
' replace the classic callback
' react on click the ExitButton here
End Function

Function Scroll_OnScroll(Byval Index As Long)
' replaces callback
' react on scrolling of Scroll(Index)
End Function
End UIWindow

Global myWindow(123) As t_myWindow



Only thinCore must learn that in case uses "UI" a Type Alias UIWindow can have controls as subelements. Controls are to UI built-in specialized Types of course and any user-defined UIWindow will "Extends" a to UI built-in basic window-type with all the properties and methods that every window has.

An UIWindow can - as any CodeUnit - have public and private properties and functions.


Now back to the ".tProject"-extension:

The use of a tProject-file would tell the interpreter that the code strictly follows type-oriented rules...