ReneMiner
28-01-2015, 11:58
confusing headline- i changed the topic but not the title...
String sName = UDT_ElementName(Byval Typename as String, Byval Offset As Long)
' where Typename contains the udt-name and offset equals some UDT_ElementOffset...
... but this idea is not good as i thought as first and i edited this post for half a day already... :D
Better - the core of the idea is this:
UI_OOP-module should have some built-in oop-types for all dialogs, menus, timers & controls
user-defined dialogs always have to be an extended type of the provided UI_OOP_DIALOG-basetype
UI_OOP-controls are part of their parenting window-structure so they can be "adressed by name"
alike "myWindow.OKButton.Enable( AllDataFilledIn )"
' all build in:
Type t_UI_OOP_Basetype ' very basetype to all UI-objects
hndl As Long ' either hDlg, hMenu, hTimer or hControl
hParent As Long ' obvious
ParentPtr As Function
' retrieves the pointer to the parents type-structure from user-slot 1 at hParent
Enable As Function
' some functions apply to dialogs and controls
' maybe some of them should be only part of base-dialog- or base-control-udt
' --- or both and not here in the basetype
SetVisible As Function
SetText As Function
GetText As Function
' these will probably all UI-objects but timers have.
' So for timer-types or others that don't accept text/are invisible
' just write an empty function to overrule this basetype-functions
' or write the function different (as for dialogs that are extensions of this basetype)
SetFont As Function
'...
EnumType As Function
' somehow we have to enumerate the type-names *** see link at very end of post
End Type
Type t_UI_OOP_Dialog Extends t_UI_OOP_Basetype
numControls As Long
' this is important for CONTROLID
' simply add this to %WM_USER and increase for each new initialized control then
Init As Function
cb_Proceed As Function ' automatic universal callback-function built-in ;)
Locate As Function
SetSize As Function
SetMinSize As Function
GetClientWidth As Function
GetClientHeight As Function
SetBackColor As Function
'... etc.
' every user-defined UI_OOP-window must be an extension of this type
End Type
Type t_UI_OOP_Control Extends t_UI_OOP_Basetype
' ...every control is an extension of this type,
Init As Function ' this function were non-functional for the basetype
' but every extended type (=control) would have this and
' automatic assign %WM_User + control-number to hndl - thats why we have the hParent
' -there we can ask the user-slot # 1 for the needed pointer and it has a numControls-property
' and forget about current BEGIN CONTROLID, END CONTROLID when using oop
' the distance (in bytes) of varptr(Me) from Varptr of the parenting window-structure tells some
' value that's known as UDT_ElementOffset.
' since i had another idea previously how to call on user-defined functions
' wanted to retrieve the Udt_ElementName...
cb_Proceed As Function
' automatic seperate callbacks of controls & menus from the windows callbacks
End Type
Type t_UI_OOP_HScroll Extends t_UI_OOP_Control
'...every control gets its specific functions depending on control
' the user has to write what happens if a scrollbar changes its value
' a builtIn-controls-callback-type-function (cb_Proceed) has to take care for the change itself
'...
End Type
Type t_UI_OOP_CommandButton Extends t_UI_OOP_Control
' some common button-specific functions here, SetPos, Enable etc.
' etc. many more controls, popups, menuitems, timers - "a lifetime-quest"
and the user can do this:
Uses "UI_OOP" ' might include classic "UI" also then
Type t_someWindow Extends t_UI_OOP_DIALOG
OKButton As t_UI_OOP_commandButton
CancelButton As t_UI_OOP_CommandButton
ExitButton As t_UI_OOP_CommandButton
CheckColor(3) As t_UI_OOP_Checkbox
myTimer As t_UI_OOP_Timer
'...
End Type
Dim myWindow As t_someWindow
Function TBMain()
With myWindow
.Init(0, "this is a window", 0, 0, 640, 480, %WS_BORDER | %WS_POPUP | %WS_VISIBLE | %WS_DLGFRAME | %WS_THICKFRAME, %WS_EX_PALETTEWINDOW )
.OKButton.Init( "OK", 8, 24, 200, 32 [,Style [,ExStyle]])
' in t_UI_commandButton.Init() it would request this buttons parent-pointer from the variable "myWindow"
' this would be the tricky part for you to extract this "myWindow" from the call on "myWindow.OKButton.Init"
' especially if With myWindow/End With is used... ;)
' - but we could of course pass the result of myWindow.Init (= .hndl) for the meantime
' or have to use "With myWindow/End With" MANDATORY TO INIT CONTROLS & other in dialog contained stuff
' so UI_OOP could read out the current "With-VarPtr"/ request it from thinCore?
'...
.CheckColor(1).Init("Red", 8,120, 200, 20)
.CheckColor(1).SetChecked ' (Optional True|False, default True)
.CheckColor(2).Init("Green", 8,140, 200, 20)
.CheckColor(3).Init("Blue", 8,160, 200, 20)
.myTimer.Init(1000)
'...
.Show [Modal | Modeless]
End With
End Function
Sub myWindow_OnStartUp()
' this is a user-defined function called by the auto-windows callback on %WM_InitDialog
'- but then it's too much "INIT" and we did .init the window previously already, so i call it _OnStartUp
' here probably could stuff happen as creating TBGL inside canvas, filling displays & controls with data,
' starting timers etc.
myWindow.myTimer.Enable() ' (Optional True|False, default True)
End Sub
Sub myWindow_OnClose(ByRef abort As Boolean)
' this is a user-defined function that will be called if dialog ends,
' user might set abort = True to prevent window from closing ;)
End Sub
Sub myWindow.myTimer_OnTime()
' user defined code for myWindow.myTimer-event
' blink-blink
End Sub
Sub myWindow.OKButton_OnClick()
' this is a user-defined function!
' an Index has to be found out by the universal-callback and would get passed here
' myWindow has only 1 OKButton so Index will be 0 means "Byval Index As Long" in functions paramters not necessary
End Sub
Sub myWindow.CheckColor_OnClick(Byval Index As Long)
' this is a user defined function too, but since there are 3 checkboxes
' Index will tell us which
' the callback can subtract the control(current)-varptr of the control(1)-varptr
' then divide this by sizeOf(control(1)), finally add 1 to stay 1-based so we have the Index
Select Case Index
Case 1 ' clicked "red"
Case 2 ' on "green"
Case 3 ' were "blue"
End Select
End Sub
USER SLOT 1 of dialogs already occupied with varptr of the window-structure. Suggest to use the same slot at controls for same purpose and store the pointer to the control-udt-data.
USER SLOT 2 in future should hold a pointer where to read out the type-name (UDT-name) of the dialog or control: Inside functions of a basetype the real type can differ and be an extended type. If we can request the Type-name from a control itself then we can use basetype-functions to delegate a basic functionality to be processed in a later added extendeds type-function by creating layover of the real type using Dim Like [Read UDT-name At Pointer] inside basetype-function - as long as the later added type follows the same pattern/function-paramters
And of course we can always create the real type of layover for any purpose.
A simple approach were this:
$t_someWindow = "t_someWindow" ' i need to setup a $const for every used type in my script
Dialog Set User Me.hndl, 1, VarPtr(Me)
Dialog Set User Me.hndl, 2, StrPtr($t_someWindow)
'...
Dim lDialog Like StrAtPtr$(Dialog_GetUser( CBHNDL, 2)) At Dialog_GetUser( CBHNDL, 1)
Function StrAtPtr$(ByVal p As DWord) As String
' see support, i suggested this function already
If p Then Function = Memory_Get( p, Peek(DWord, p-4) )
End Function
But I have some multi-purpose-enumerating-function that will do without String-constants but uses Heap and is Array-Scan-Powered.
It could be modified to be a type-enumerating-function only (all ucase then = faster if stored ucase) and to check if Type_Exists for security-reasons.
find it there:
http://www.thinbasic.com/community/showthread.php?12467-enumerating-thoughts&p=91805#post91805
(http://www.thinbasic.com/community/showthread.php?12467-enumerating-thoughts&p=91805#post91805)
String sName = UDT_ElementName(Byval Typename as String, Byval Offset As Long)
' where Typename contains the udt-name and offset equals some UDT_ElementOffset...
... but this idea is not good as i thought as first and i edited this post for half a day already... :D
Better - the core of the idea is this:
UI_OOP-module should have some built-in oop-types for all dialogs, menus, timers & controls
user-defined dialogs always have to be an extended type of the provided UI_OOP_DIALOG-basetype
UI_OOP-controls are part of their parenting window-structure so they can be "adressed by name"
alike "myWindow.OKButton.Enable( AllDataFilledIn )"
' all build in:
Type t_UI_OOP_Basetype ' very basetype to all UI-objects
hndl As Long ' either hDlg, hMenu, hTimer or hControl
hParent As Long ' obvious
ParentPtr As Function
' retrieves the pointer to the parents type-structure from user-slot 1 at hParent
Enable As Function
' some functions apply to dialogs and controls
' maybe some of them should be only part of base-dialog- or base-control-udt
' --- or both and not here in the basetype
SetVisible As Function
SetText As Function
GetText As Function
' these will probably all UI-objects but timers have.
' So for timer-types or others that don't accept text/are invisible
' just write an empty function to overrule this basetype-functions
' or write the function different (as for dialogs that are extensions of this basetype)
SetFont As Function
'...
EnumType As Function
' somehow we have to enumerate the type-names *** see link at very end of post
End Type
Type t_UI_OOP_Dialog Extends t_UI_OOP_Basetype
numControls As Long
' this is important for CONTROLID
' simply add this to %WM_USER and increase for each new initialized control then
Init As Function
cb_Proceed As Function ' automatic universal callback-function built-in ;)
Locate As Function
SetSize As Function
SetMinSize As Function
GetClientWidth As Function
GetClientHeight As Function
SetBackColor As Function
'... etc.
' every user-defined UI_OOP-window must be an extension of this type
End Type
Type t_UI_OOP_Control Extends t_UI_OOP_Basetype
' ...every control is an extension of this type,
Init As Function ' this function were non-functional for the basetype
' but every extended type (=control) would have this and
' automatic assign %WM_User + control-number to hndl - thats why we have the hParent
' -there we can ask the user-slot # 1 for the needed pointer and it has a numControls-property
' and forget about current BEGIN CONTROLID, END CONTROLID when using oop
' the distance (in bytes) of varptr(Me) from Varptr of the parenting window-structure tells some
' value that's known as UDT_ElementOffset.
' since i had another idea previously how to call on user-defined functions
' wanted to retrieve the Udt_ElementName...
cb_Proceed As Function
' automatic seperate callbacks of controls & menus from the windows callbacks
End Type
Type t_UI_OOP_HScroll Extends t_UI_OOP_Control
'...every control gets its specific functions depending on control
' the user has to write what happens if a scrollbar changes its value
' a builtIn-controls-callback-type-function (cb_Proceed) has to take care for the change itself
'...
End Type
Type t_UI_OOP_CommandButton Extends t_UI_OOP_Control
' some common button-specific functions here, SetPos, Enable etc.
' etc. many more controls, popups, menuitems, timers - "a lifetime-quest"
and the user can do this:
Uses "UI_OOP" ' might include classic "UI" also then
Type t_someWindow Extends t_UI_OOP_DIALOG
OKButton As t_UI_OOP_commandButton
CancelButton As t_UI_OOP_CommandButton
ExitButton As t_UI_OOP_CommandButton
CheckColor(3) As t_UI_OOP_Checkbox
myTimer As t_UI_OOP_Timer
'...
End Type
Dim myWindow As t_someWindow
Function TBMain()
With myWindow
.Init(0, "this is a window", 0, 0, 640, 480, %WS_BORDER | %WS_POPUP | %WS_VISIBLE | %WS_DLGFRAME | %WS_THICKFRAME, %WS_EX_PALETTEWINDOW )
.OKButton.Init( "OK", 8, 24, 200, 32 [,Style [,ExStyle]])
' in t_UI_commandButton.Init() it would request this buttons parent-pointer from the variable "myWindow"
' this would be the tricky part for you to extract this "myWindow" from the call on "myWindow.OKButton.Init"
' especially if With myWindow/End With is used... ;)
' - but we could of course pass the result of myWindow.Init (= .hndl) for the meantime
' or have to use "With myWindow/End With" MANDATORY TO INIT CONTROLS & other in dialog contained stuff
' so UI_OOP could read out the current "With-VarPtr"/ request it from thinCore?
'...
.CheckColor(1).Init("Red", 8,120, 200, 20)
.CheckColor(1).SetChecked ' (Optional True|False, default True)
.CheckColor(2).Init("Green", 8,140, 200, 20)
.CheckColor(3).Init("Blue", 8,160, 200, 20)
.myTimer.Init(1000)
'...
.Show [Modal | Modeless]
End With
End Function
Sub myWindow_OnStartUp()
' this is a user-defined function called by the auto-windows callback on %WM_InitDialog
'- but then it's too much "INIT" and we did .init the window previously already, so i call it _OnStartUp
' here probably could stuff happen as creating TBGL inside canvas, filling displays & controls with data,
' starting timers etc.
myWindow.myTimer.Enable() ' (Optional True|False, default True)
End Sub
Sub myWindow_OnClose(ByRef abort As Boolean)
' this is a user-defined function that will be called if dialog ends,
' user might set abort = True to prevent window from closing ;)
End Sub
Sub myWindow.myTimer_OnTime()
' user defined code for myWindow.myTimer-event
' blink-blink
End Sub
Sub myWindow.OKButton_OnClick()
' this is a user-defined function!
' an Index has to be found out by the universal-callback and would get passed here
' myWindow has only 1 OKButton so Index will be 0 means "Byval Index As Long" in functions paramters not necessary
End Sub
Sub myWindow.CheckColor_OnClick(Byval Index As Long)
' this is a user defined function too, but since there are 3 checkboxes
' Index will tell us which
' the callback can subtract the control(current)-varptr of the control(1)-varptr
' then divide this by sizeOf(control(1)), finally add 1 to stay 1-based so we have the Index
Select Case Index
Case 1 ' clicked "red"
Case 2 ' on "green"
Case 3 ' were "blue"
End Select
End Sub
USER SLOT 1 of dialogs already occupied with varptr of the window-structure. Suggest to use the same slot at controls for same purpose and store the pointer to the control-udt-data.
USER SLOT 2 in future should hold a pointer where to read out the type-name (UDT-name) of the dialog or control: Inside functions of a basetype the real type can differ and be an extended type. If we can request the Type-name from a control itself then we can use basetype-functions to delegate a basic functionality to be processed in a later added extendeds type-function by creating layover of the real type using Dim Like [Read UDT-name At Pointer] inside basetype-function - as long as the later added type follows the same pattern/function-paramters
And of course we can always create the real type of layover for any purpose.
A simple approach were this:
$t_someWindow = "t_someWindow" ' i need to setup a $const for every used type in my script
Dialog Set User Me.hndl, 1, VarPtr(Me)
Dialog Set User Me.hndl, 2, StrPtr($t_someWindow)
'...
Dim lDialog Like StrAtPtr$(Dialog_GetUser( CBHNDL, 2)) At Dialog_GetUser( CBHNDL, 1)
Function StrAtPtr$(ByVal p As DWord) As String
' see support, i suggested this function already
If p Then Function = Memory_Get( p, Peek(DWord, p-4) )
End Function
But I have some multi-purpose-enumerating-function that will do without String-constants but uses Heap and is Array-Scan-Powered.
It could be modified to be a type-enumerating-function only (all ucase then = faster if stored ucase) and to check if Type_Exists for security-reasons.
find it there:
http://www.thinbasic.com/community/showthread.php?12467-enumerating-thoughts&p=91805#post91805
(http://www.thinbasic.com/community/showthread.php?12467-enumerating-thoughts&p=91805#post91805)