clear GUI items from screen

[Naveg]

after a cls, the GUI items are still there, just not visible, how do i remove them all at once? without a dispose command for each

[cycro1234]

I don't know if you can do all of them at once. I've always used the disable command to disable the ones I do not need.

[Naveg]

well what happens is i have a screen with a binch of GUI things, then i do a cls, and i have new GUI things. But what happens is the other ones are still there, so if i click somewhere where it was it shows up.

[Naveg]

in other words, i want to do something that is like...GUI.Dispose(all)...you get the idea.

[Bacchus]

make a proc for it then

[Naveg]

Bacchus wrote:

make a proc for it then

how....? sorry i'm new to GUI concepts

[Bacchus]

code:

proc watever GUI.Hide(blah) %reapeat for all :P end watever

thats the easy way

[Naveg]

Bacchus wrote:

code:

proc watever GUI.Hide(blah) %reapeat for all :P end watever

thats the easy way

yea i could do that, i though there might have been a way to do it in a few lines. guess not. thanks!

[StarGateSG-1]

That would work ok but you need process instead it will work better and is less messy

This is a procedure example

code:

%Declares the procedure foward procedure guiclear %The procedure body procedure guiclear GUI.Hide(guiname) %repeat as nessisary end guiclear

You call this with its name

This is a process example

code:

process guiclear GUI.Hide (guiname) %repeat as nessisary end guiclear

This is less messy and can be called without interrupting the program

If none of this works try combining the process with an array for the button and every time you make new buttons override the other ones.

Procedure sucks for small things

[Martin]

If you're smart about how you declare all of your GUI objects, you can clear them with a simple for loop. As it stands, the best way to do this is to write a procedure to clear them all out.

Making it a process is a horrible idea. I've said this a million times before, but never use processes. They are inconsistant, unwieldly and don't behave the way that most people thing that they do. Forking music is the only exception to this rule.

[person]

procedures would be better for ur purpose

[Naveg]

martin wrote:

If you're smart about how you declare all of your GUI objects

could you clarify please?

[Cervantes]

Vladimir wrote:

martin wrote:

If you're smart about how you declare all of your GUI objects

could you clarify please?

martin wrote:

you can clear them with a simple for loop

That would imply he's using an array of buttons.

StarGateSG-1 wrote:

That would work ok but you need process instead it will work better and is less messy

StarGateSG-1, this is important. Read this.

[StarGateSG-1]

I don't know who you think you are but i took those bits of code from a warking program I made 4 years ago and they still work today.

PROCESSES ARE NOT HORRIABLE UNLESS YOU ARE A NEWB TO PROGAMING YOU NEED TO KNOW HOW TO USE THEM RIGHT.

Turing is like any other language if you no how to use it right the possibilities are endless, you can't even write parts in C++ and run with it. After all all the commands are just groupings C++ hardcode in assembly.

[Cervantes]

StarGateSG-1 wrote:

i took those bits of code from a warking program I made 4 years ago and they still work today.

Well, of course it'll work to some extent. If they didn't work at all, there would be no point to including them in Turing. But the thing is, they don't work well. Strange things can happen. Most of the time, everything will run pretty well fine because the randomness is pretty well 50-50 for two processes. Meaning that at any given time, both processes will have executed approximately the same number of times. But don't you think it's risky, since you don't actually know how your program will execute?

StarGateSG-1 wrote:

PROCESSES ARE NOT HORRIABLE UNLESS YOU ARE A NEWB TO PROGAMING YOU NEED TO KNOW HOW TO USE THEM RIGHT.

As far as I know, you can write some code that will ensure the processes run well (one at a time, one followed by the other, no randomness as to when either runs). But that's not very efficient, takes extra coding, and is needless.

StarGateSG-1 wrote:

Turing is like any other language