Named controls ideas

[DirectuX]

so I have to forget about named controls ?

[ErosOlmi]

No, I will not go back in creating named controls. They are great I think.
But after having implemented some of them ... as soon as I started to develop example scripts I discover that my implementation was done on the wave of the enthusiasms and I didn't thought well about all the aspects.

For example:

now a named control is a global variable of a certain class (type).
But what if more controls have the same name but different parent control/window?
A bug: I cannot have two global variables with the same name.
So I need to think how to implement names in order to remove ambiguity.
Maybe dotted notation like ParentName.ControlName.Property like:
Window1.ListBox1.x = 10
so you can also have another ListBox1 in a second window like
Window2.ListBox1.x = 10

Also ReneMiner just noticed:

what if I need more controls with the same name over the same window?
In some Visual languages you can have an array of controls with the same name.
So I need to think I to implement an array of controls.
Windows1.txt(index).x = 5
where txt() is an array of textboxes all with the same name but different index

Things like that, if implemented, will change current naming.

So I will wait before documenting them.

An example of current implementation can be found in \thinBasic\SampleScripts\UI\NamedControls\ directory.

[ReneMiner]

If dot-notation...
Hmm, there's a connection to...
Let's say UI-module gets wrapped into a new
"UI2"-module.

Am not good in finding names

Type tUI2_Window
 ' into UI2-module built-in, pretty small base-type!

   hWnd As Dword
   Function _create(optional 
                                  byval Width As Long = screenwidth * 0.5,  
                                  byval Height As Long = screenheight * 0.5, 
                                  byval sTitle As String = App_Name, 
                                  Byval Flags As Long = %screencentered | %closebutton
                                  ) As Dword
' create simple window here with given
' parameters and store hWnd to Me

' ...return hWnd on successful creation
     Function = Me.hWnd

   End Function
End Type

The user might create his own

Uses "UI2" 
' now we could write:

Type wUser Extends tUI2_Window

 '  but this is another approach
' Alias the codeline above (Type wUser...)

Begin Window wUser
  ' remember the tUI2_Window that gets 
  ' extended here has a hWnd-property already

   ExitButton As Control [Add] Button(...)
  ' since we are inside a Type-declaration there is
  ' possibility of a private scope:
  ' ExitButton inside (functions of this) section 
  ' equals Me.ExitButton
   RGBScroll(3) As Control [add] Scrollbar(...)
   
   Sub RGBScroll_OnChange(Byval Index As Long)
     ' that's an event if an RGBScroll changed its value
    ' Index would tell which one R, G or B
    ' but we just change Backcolor of this window:
  
   Me.Backcolor = RGB(RGBScroll(1).Value, RGBScroll(2).Value, RGBScroll(3).Value)
   
   End Sub

  ' varName[(index)] As Control [add] ctrlType(...)
  ' - syntax only valid if uses "UI2", 
  '  between Begin Window and End Window
  ' I guess "add" can be omitted here

  ' it will need to call an event to arrange controls 
  ' after a window was created
End Window

Dim myWindow(3) As wUser
' in the past there was a problem if an array of udt gets created. 
' I think _create() doesn't apply 
' to all 3 of myWindow 

' so we must call for each
myWindow(1)._create(...)
myWindow(2)._...



' here, outside type-scope we must use f.e.
Sub myWindow.ExitButton_Click(Optional ByVal Index As Long)

'...so inside this Sub  Index tells us which of myWindow
End Sub

I could continue this but I pity you having to realize all that

It's just an idea, maybe it gives a kick to think of different ways

[ErosOlmi]

Renè,

you have always clever ideas.
I will consider all of them.

Ciao
Eros

[DirectuX]

Hi,

No, I will not go back in creating named controls.

Loud and clear.
Notice that I have not requested new feature, just asked related manual pages to deeper understanding of ThinBasic's features. (like in the named control sample).

So, rest of the thread after your answer is just a thought experiment, yes ?

For example:

now a named control is a global variable of a certain class (type).
But what if more controls have the same name but different parent control/window?
A bug: I cannot have two global variables with the same name.
So I need to think how to implement names in order to remove ambiguity.
Maybe dotted notation like ParentName.ControlName.Property like:
Window1.ListBox1.x = 10
so you can also have another ListBox1 in a second window like
Window2.ListBox1.x = 10

In ThinBasic samples there are blocs like this:

Begin ControlID
  %ID_Button_01   
  %ID_Button_02
End ControlID

Here each control has is unique name (or ID) , why would someone want to name two controls with the same name ?

But what if more controls have the same name but different parent control/window?

This make me remember of namespaces/scope
By default a control name would refer to a "local" control, otherwise, parent would have to be precised. In the background it would be managed by a list of aliases, no ?

Maybe dotted notation like ParentName.ControlName.Property like:
Window1.ListBox1.x = 10
so you can also have another ListBox1 in a second window like
Window2.ListBox1.x = 10[/INDENT]

MS Office VBA works almost like this. It benefits well of code auto-completion (typing a dot suggest what's possible next)

What thinBasic calls "Automatic Events" is a great feature in my opinion. I think this can be worked around by an extensive visual designer generated code. (Can any user improve this, or much knowledge is required ?)

(By the way, thinAir's autocomplete isn't aware of variable declarations, nor the debugger displays dotted property values*, it's regrettable)
*for the debugger, my mistake: I've deduced that from objects properties but there are never properties, only methods in what I've seen until now in the samples. Properties seems to be treated via methods as well.

The user might create his own

From my point of view I feel it less evident than what I've seen in actual thinBasic samples. (no offence)

Aside from that, manual mention this : https://www.thinbasic.com/public/pro...lass_names.htm
What differs with thinBasic's home made controls ?