Can we use Control/Dialog Name?

[ReneMiner]

Eros you are the only one who can answer this:

We assign the name to a control or dialog while we create it. It is assigned without double-quotes, that means its kind of a variable?

Is that variable used in any way except to tell UI the name?

Can't we just assign the name like this:

(simplyfied code!)


' -- a basic object-udt for anything that is a

Type tWindowsObject
[RESERVED_FOR_UI As Bytes(128)
' it were a possibility if UI needs storage for 64-chars-wide-string or
' not to cover anything that wil be stored to the variable that we use as NAME for dialogs & controls]

hWnd As Dword ' the objects windows-handle
pParent As Dword ' pointer to the parenting tWindowsObject
pChildren As String ' pointer-list (&= MKDWD$(Varptr(childvar)) to append children here)

' -- i omit statics & functions that this udt would have to manage all the inheriting objects and to
' reply to any requests concerning relatives. This UDT would also handle the assignment and of
' storage of CONTROLID's. Instead to ask the ID we have (variable-)names and indexes in 3 dimensions as
' every thinbasic variable offers.
Function _Create(whatever assigned)
msgbox "ERROR this type is a template only. You can not create objects from it."
End function
End Type

' this now the udt containing a dialogs data and wrapping the properties to functions:

Type tDialog Extends tWindowsObject
Title$ As String ' store the caption of a window.

Function Caption(Optional Byval sTitle As String ="&%$(/%$§$&" ) As String
' function to assign and request window-caption
' "&%$(/%$§$&" is a random pattern to make sure that
' user wants to assign empty string and not not requests current caption only

if Not sTitle = "&%$(/%$§$&" then
Dialog Set Text me.hWin, sTitle
Me.Title$ = sTitle 'store title to the object

' request the stored value again from the object to have it fit (perhap was truncated)
Dialog Get Text, me.hWin to sTitle
Function = sTitle
End Function

'Function _Create(optional byref Parent As tWindowsObject,
' byval [File] sText As String,
' posX, posY, sizeW, sizeH, lStyle,lExStyle)
' This function sadly not doable this way.
' It can not assign its own name because we do not use quoted string for Name-assignement

' (also we can not achieve to pass keywords like File without quotes.
' Like Parse File "filename" would be nice to use that as switch too whether sText contains
' the caption or filename to obtain the data. )
'End function

End Type
' sadly not possible as easy as this:

' Global MainDialog As tDialog( NULL, FILE "ini or resource-filename")

'But to stick with currently possible methods use the regular way - now knowing which direction (see above)


If I do this:

Dim MainDialog As tDialog
Local hDlg As Dword At Varptr(MainDialog.hWin)
' no need to create hParent At the parenting udts .hWin if no parent...

Dialog New Pixels, Name MainDialog, 0, sTitle, x, y, w, h, style, xstyle to hDlg

I assign the same VariableName - that i dimension before as tDialog already !!!




Now my question :

Will it be enough to allocate a RESERVE of 128 Bytes before the name is passed or will it internal store anything at all to that name?

_______________________________________________________________________________________________

Thoughts about a direction only: (Stop reading it!)

Maybe you are storing hWin only?
Maybe UI stores handle of Parent too? - Then it were better to have the pointer of the parents assigned udt stored but
in fact the objects data in the udt contains all that information.

The first 4 Bytes of the udt mandatory would hold windows handle (hWnd).
Now it sounds complicated but is easy



think of any tWinObject and all that extends it (remove the RESERVED_FOR_UI in your mind)

VARPTR(anyObject) equals "AbsolutePosition:Byte1" of the objects data-structure

BYTES 1,2,3,4 hold "ME.windows-handle, "hWnd"

following
BYTES 5,6,7,8 hold Varptr( Me.ParentObject ) equals "AbsolutePosition:Byte1" of this current objects parent.


That means At the position
Varptr( Me.ParentObject ) is where the UDT starts that holds Me.Parent's data
AND at the same timeit is where to peek me.Parent's hWnd

If we could simply assign the Name of an existing Variable that meets that condition:

Size 8 Bytes

so use a LongLong or Quad if you dont want to create an udt

HI(<currentName>) equals hWnd
LO(<currentName>) pointer where to peek 4 bytes telling currents parent's hWnd.

If I create 5x5 images andplace them to the background of anything- will it be possible to create 5x5 variables
myImage(5,5) and pass on their creation the names myImage(x,y) so UI knows- "oh that guy has an index, or 2 or 3--- i dont care as long as he provides a space where i can put his handle!" But in fact UI gets presented a value that
the control does not know about itself but the programmer would like in the callback to know which of the 5x5 in Callback Function image_OnHit() was hit by the players ball. And ui could remember what index belongs to that handle...

so Programmer will luckily provide for 2d-array myImage(5,5) in the

callback Function myImage_OnHit(byval X as Long, byval Y as Long) as Long


' if named index1 and index2 does not matter, its up to the programmer
' but 2 dimensions mean 2 varaiables in the range of long

'---------------------------------------------------------------------------------
Function = TRUE ' kindly wave back so ui will keep sending messages to you
End Function


Using 8 Bytes would mean had to take care of the controlID's ourselves because we need another 4 bytes to store it.
And to make it complete: 12 bytes ? computers do not like odds. 16 were fine.
4 bytes a pointer to a list (@heap, an array or simply a string) where we can node all additional objects that to see as direct Child-objects.

The dialog might hold a viewport...but inside the viewport lives another dialog holding controls there....

The order of the childrens pointers can mean a lot - zOrder(drawing order), default tabbing-order (tab-key)... so these can be useful for UI how to proceed in doubt

[José Roca]

Maybe you are storing hWin only?
Maybe UI stores handle of Parent too? - Then it were better to have the pointer of the parents assigned udt stored but


Are you aware that you only need the window handle?

If you want to get the parent handle, then use GetParent(hWin)

If you want to get the control identifier, the use GetDlgCtrlID(hWin)

[ReneMiner]

Yes i know José. It's a sideeffect to have the pointer of the parent readable directly following the winndoows-handle and if placing virtually at the position that is stored following current windows hWnd an udt of a base-type we have instantly a sorted list of all siblings of the current object including the own position . But actually the goal was, the very nice and easy clean understandeable syntax to extend and not just tell UI -module: Hey my windows name is "myDialog"you can call the callback of it telling what event happened - and that were the only use of the name?


I want to get as much as possible from every variable that has to be declared- maybe i'm a relict of 8 bit times where we had 64kB and to think well how we partition the memory.

And my main-thought is that if we could "borrow" the name of an existing udt that we can customize as we need that goes along with the evolving syntax and since variables have INDEXES in 3 dimensions already why should there a complicated solution be developed if it were that easy.

But since UI that variable probably uses for any reasons that i forgot or never thought of i ask indirectly if it were possible that UI provides a basic UDT for any object. We would combine the ability of a variable that can be stored in an array or even 2 or 3 dimensional with the current evolution of UI. I see a lot of opportunities that could be opened to the users if that what we assign as a name for UI -objects had some deeper meaning than just carry a name.

If "Type mycustomDialog extends UI_Mastertype" then my dialog or even mycontrol will have a fixed pattern that UI works with. Since its extended during runtime it will not experience any limitations that the udt might have if UI would "extends" it by itself it could provide a base-UDT to all windows-objects. So everything has the same basic properties. If its just a type- no functions to a type from UI-side could be added this way? it is not necessary.
No problem at all to create copy of udt using cut and paste or even write it on a paper, give it a new name and the additional properties. If extending not works from inside- save it as text and use ThinBasic_SDK-functions to add it- if it were a problem for UI to use the implemented way using Extends-Keyword to provide a customizable type it could provide one for different types of Menuitems, Controls, Dialogs or invisible controls like imagelists, timers, or any other that are predefined. If probably it is possible to disable the use of a leading underscore for User-defined udt-propertiess and functions and if needs 2 years to develop all the deatil- no stress about if an obvious name was used by many users already. Anyway in my opinion callback- from callback invoked functions - should stick with using underscores. The dot stays to the objects properties and abilities which are directly noded to the udt.

The underscore to combine Object-variable-name with the event that occured is valid for certain predefined functions that are controlled by the system. The user can/must not call these _OnEvent() _Create() or _Destroy() - it should raise a gpf. He is allowed to write and provide the functionalities as he needs them. Must follow a few rules, for example if he uses an array or multidimensional object its up to him to provide the required variables to receive indexes and or a variable anyway that tells if shift/ctrl or alt or if whatever device was plugged and used that UI can call the predefined functions - passing all that is clear visible and known - hiding the confusing many handles even if a millisecond more execution speed. The user has a clearly structured and understandeable tool in thinbasic to have the required function fast. Thats what theey care for. The execution-speed he also leaves them who know how to get here or there some frame additional drawn-.


Should there be any hindrances as maybe UI-module were not able to create extensions the same way as we do in a script then it certainly can copy and existing udt manually -staying simple is difficult enough that i still think essential and was a real milestone when Eros added it maybe 6 years ago. It was partially invoked by myself and instantly Eros knew how to make the previously standard-UDT that almost every language provides to something very special that made many shortcuts possible and i can not imagine anymore thinBasic without it. At the same moment Eros also was aready on it to make the usage of UI-module more user-friendly by introducing named controls as VB Classic had.

Now its a bit of gap that can be closed taking advantage of the thinBasic-special-feature if we use a simple Variable that at least must hold the hWnd and can be fully customized by extending this 4 bytes
Since we have to assign always the handle of a parent if we create the window Why should there be no fixed place so everyone knows where to find all about relationships without knowing anything abo-ut Win32Api- no need - if thinbasic provides it clearly the user can focus on going towards his planned goal without doing any cumbersome things that he might not have the time to learn or to understand since someone who knows how saved them plenty of time-

I think you know - you did it yourself often enough and every minute- hour - day - week or month that you put into developement of a new library or feature saved many users a lot of time to stay focused realizing their ideas. The hour that you spend saved 1000 Users more than 2000 hours because they could not do it so effective as you can. Many of them would have given up already if there were not your code solving the problem. I can use GDIp without to think why it works or how. I can load- rotate - blend, stretch or convert image formats so to say with one click . Your thought that you put (not only into tb-modules- sometimes i also borrow functions from other dialects ) saved me countless hours because i did not have to understand how a *.png must be structured or how to decode the format etc.

I have many "useless" ideas. But even if some sound crazy or like "no you can't go this way because no one does" is not a reason to stick with the present which is the past of tommorow. And to be honest, before i ask myself why someone doesn't go this or that so obvious appearing way, i ask the one who should know.

Thats why am asking - putting my pros and cons together. Thinking if possible or not is still not sure. The advantage of a negative sounding expression like "doubt" is that we want to know better than we do now. Even sometimes i have problemsto stop myself typing - so i better
up
break it

[José Roca]

> without knowing anything abo-ut Win32Api

Knowledge of the Windows API is fundamental to be a good Windows programmer. OOP frameworks come and vanish, but the Windows API remains. All the wrappers that I have written are to ease the use of the Windows API, not to replace it. I couldn't care less about wanna be programmers wanting to write applications without learning the basics. They become tool's users instead of programmers. One thing is to help a beginner and another to waste time with people that aren't willing to learn. If I give you a tool, you should learn how it woks, not simply to use it because it works. This is the difference between a programmer and an user. If everybody was an user, I wonder who will write the tools.

[ReneMiner]

:focus: Hmm, i must admit i did not have the luck to be born as a programmer but only as a user. And i like to achieve that my user-scripts are finished quickly and free of bugs then because a lazy user as i am one, does not like to learn how to use a debugger anyway.
:cray::scare:It's too difficult if no sources of information are available in the whole wide world about how the name that an UI-object gets assigned is been used internally by thinCore since its a very well kept secret - different from wina32api that everyone can google.

:D
And stupid how i am - i still try... and hopefully I will not learn anything that forces me to use a different tool than thinBasic - because i know it longer than the current OS, it was there long time previous previous the previous of the previous OS of the current- we called it XP in that time which was the ancestor of the famous Windows Longhorn (https://archive.org/details/thelonghornarchive) before it came to the catastrophic extinction when Vista tried to conquer the world - and even it was made from bones and stones only - it worked out to calculate how many bananas we got peeled per hour. While the old win-api has been renewed over the time and as many new functions it has, while the old ones are deprecated or have been replaced with new extended syntax that contains ugly words as PointerSafe or LongLong or QWord and many programmers do not care about their projects any more-

i know here are some that are replacing, renewing, extending just to keep everything runnable, compatible. :yahoo:
And thats cool. Because as a user i am really not interested how windows works but how i can use it. :comp12:

The windows api will certainly not tell me where the parenting udt-data of my window is stored in memory- it only will tell me the handle - which lazy users get delivered for free if they know where to find the data because it were at the beginning of the data.
:friends:
But as said, as i am only a user who has no idea what is going on i the secret dungeons of win32api i fear that the idea to use an existing udt-variables name as name of a control or window might damage windows irreversible.


It will probably do the same as if one presses the delete-key while already pushing the windows-key

and ...

as absolute logical result
:suicide:
- as everything within windows can be explained by logic expressions -:

it will delete windows.


:drink:

[José Roca]

Because as a user i am really not interested how windows works but how i can use it.


If you knew how it works, you won't have problems to use it...

...and you won't say things like...



The windows api will certainly not tell me where the parenting udt-data of my window is stored in memory- it only will tell me the handle


When you use a main window created with CreateWindowEx, the first thing that you receive in the window callback is a WM_CREATE message, and the lParam parameter contains a pointer to a CREATESTRUCT structure (CREATESTRUCTA if you use CreasteWindoeExA or CREATESTRUCTW if you use CreasteWindoeExW)



typedef struct tagCREATESTRUCTA {
LPVOID lpCreateParams;
HINSTANCE hInstance;
HMENU hMenu;
HWND hwndParent;
int cy;
int cx;
int y;
int x;
LONG style;
LPCSTR lpszName;
LPCSTR lpszClass;
DWORD dwExStyle;
} CREATESTRUCTA, *LPCREATESTRUCTA;


Here you have all the information that Windows stores about te window.

See: https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-createstructa?redirectedfrom=MSDN

Now, if you use something like PowerBASIC's DDT engine, that uses the Windows Dialog Engine, you wont's receive a WM_CREATE messasge, but a WM_INITDIALOG message, and you won't get a pointer to the CREATESTRUCT structure. If you use the Windows Dialog Engine instead of CreateWindowEx, then you have to deal with its limitations. Apparently, thinBasic also uses that dialog engine.

But it is not the Windows API which won't give you the information, but the Windows Dialog Engine, that was not designed to create main windows, but auxiliary popup dialogs for quick data entry.

[ReneMiner]

i know theres a differend between createwindow - which will creatfrom assigned paramters or load from file and will create an own class then and the createwindowex wicht creates a copy of an existing class. Yes of course, dialogs are not the real windows but- in reality ven a button is a window. So the difference might me the defaults in it. But this is not helping me to find out if thinbasic -that gets a name assigned to the window- just as


Dialog New Pixels, Name myMainWindow,hWndParent,caption,posx, posy, sizew,sizeh, style, exstyle



i name it myMainWindow and that invokes all callback procedures that are targeting that windows-object will get called
with the name of the window in front of the procedures name as

myMainWindow_OnInit()
myMainWindow_OnCommand(Byval cbDETAIL As tUI_INPUTINFO**)
myMainWindow_OnSizing()

etc.

myMainWindow i assign while its not a quoted string and i am sure that it i some kind of variable but i want to know if this variable has any other usage or if we could do it vice versa:

Dim myMainWindow As tDialog

' assume tDialog an udt that hold my user-data about this dialog, it still has a few slots that could store something ;)

Now if i will create a dialog using the existing udt-variables name i have in fact a dialog that has optional 3 indexes as any thinbasic variable can have. It offers plenty of new ways to use these in thinBasic. But :

Is that ok to do?

is that variable that only borrows its name needed for something else internally?


The dialog connected to the udt (of corse at varptr of tDialog the windows-handle is stored as well as the varptr will be stored to the windows-object "dialog". For our purposes we use sometimes additional variables instead of requesting some value its often faster to store it. If i think like GetTickCount... you wait 20 to 30 ms for the result if the pc is not busy in background...

and the **:

mychildWindow.CreateNew Pixels, myParentwindow,t$,x,y,w,h,st,xst
myChildwindow.UseEvents(%UI_EventInit | %UIEventDestroy | %UI_EventSizing | %UI_EventTimer ...

smart if code-editor will react and create the function skeletons. And UI would know what callbacks are in use...

[José Roca]

The help file says that it is a string, so how are you going yo pass an UDT?

If you want to store more information why don't use DIALOG SET USER?

[José Roca]

It is very difficult to uderstand what you mean in your lengthy posts. I guess that you're suggesting to pass an UDT inspead of an string, but in this case Eros will have to change thinBasic, and all the existing code that uses DIALOG NEW will have to be modified.

[ReneMiner]

So i want to Pass the Name quite regular AS IT IS now. But i will Not use any arbitrary Name without a Sense but i would like to use a real variable that represents some udt. Also for the controls i would like toUse udts. The dimensioned ist shall borrow its Name to UI and IT provides the structure that UI would need to fire a callback referencing the involveditem AS "Me". (In a class it would be called"This". AS i use a variable that represents an Udt my variables Name consists of alphabetic chars, numeral Digits and perhaps underscore before the dir.Also IT can have Parenthesis containing Up to 3 numeric expressions that would indicate the array+-elements Position (Indexes) withinthe Array . Arrays i guess are possible for child-windows only- but i am Not Sure. All Eros would have to Change IS to Parse the optional Parenthesis containing the Indexes and memorize these.or we Store them to the user-,propertiesand use the leftover Slot to hWnd. If an Udt ist available armttached at an Item there will BE enough optiinc that Users can Store 16 bbytes( or more) at this structure. Ui knows its Name and can easily find Position and can also remember the Indexes and Note the ist Point!n either call the callback, Passing the Indexes to the callback AS Function-parameters .And IT could be Made Backwards compAti 33

[Petr Schreiber]

Hi Rene,

the current thinBASIC version is currently in Beta stage - exploring the possibilities, what works, what not, so that is part of the reason extensive documentation is not available for this functionality.

Once we get closer to the "final" form of UI, I would like to also have community powered resource for UI, like I prepared for UDTs:
https://thinbasic.github.io/book-thinbasic_user_defined_types/
(anyone can contribute via pull request to https://github.com/ThinBASIC/book-thinbasic_user_defined_types)

Eros is doing excellent job on it, including some cool magic with #resource files.

Currently, there is no time to advance on this research, due to high workload, but I am sure we will get to moving this area of thinBasic later this year.


Petr