You may use Positionmesh to set it's relative centerpoint. You may also use MeshWidth etc. to determine the wanted new position. You can also do this with FitMesh, it also allows to scale the mesh. Both will permanently alter the mesh.
For a Gui I would suggest to keep everthing as modular as possible. Design it in a way that minimizes the number of function calls to use it. EG:
One Function to create a Gui Element.
One Function to read its value
One function to set its value
One function to remove the Gui element
One function to render all gui elements
You should not be forced to use any gobals. It should be handled like this:
my_input=CreateFormInput(x,y,maxlen)
...
print FormInputText(my_input)
IMHO it's most flexible to use banks. You can create them dynamicly, without to define their structure in the code (like with types)
So you could use a bank handle as "my_input". In the first long you'd store what type of gui elemet it is (eg 1=input, 2=checkbox ...), in the second long you could store the mesh handle, then maybe x,y,z and so on, whatever you need, the protocol is up to you.
So when you free the element, you would do something like
mesh=peekint(my_input,4)
freeentity mesh
freebank my_input
my_input=0
And then you need a list of active gui gadgets. So when you create a new one, you would append it to the end of the list. when you remove one, you should delete it also from the list. It's a simple task to do this with an array, but using a type instead will make blitz do the indexing job for you and all you have to do is things like FOR EACH...
For a Gui I would suggest to keep everthing as modular as possible. Design it in a way that minimizes the number of function calls to use it. EG:
One Function to create a Gui Element.
One Function to read its value
One function to set its value
One function to remove the Gui element
One function to render all gui elements
You should not be forced to use any gobals. It should be handled like this:
my_input=CreateFormInput(x,y,maxlen)
...
print FormInputText(my_input)
IMHO it's most flexible to use banks. You can create them dynamicly, without to define their structure in the code (like with types)
So you could use a bank handle as "my_input". In the first long you'd store what type of gui elemet it is (eg 1=input, 2=checkbox ...), in the second long you could store the mesh handle, then maybe x,y,z and so on, whatever you need, the protocol is up to you.
So when you free the element, you would do something like
mesh=peekint(my_input,4)
freeentity mesh
freebank my_input
my_input=0
And then you need a list of active gui gadgets. So when you create a new one, you would append it to the end of the list. when you remove one, you should delete it also from the list. It's a simple task to do this with an array, but using a type instead will make blitz do the indexing job for you and all you have to do is things like FOR EACH...