Variable scope suggestion

[DirectuX]

Hi, ReneMiner,

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

1. 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-thi...-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.

[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...