Is There A Way To Assign Values Through Different Windows?

[DemonZ]

Currently I am compiling a game that so far is over 1000 lines long and am thinking about shortening it to make it easier to read and fix. But In order to do so I want to have a menu that when you select one of the modes (1 player, 2 player, help, options, quit) it will open up a second window to your program according to what the user selected and somehow branch them together, for example.

code:

x := 0 loop x := x + 1 if x = 20 then bool := true Window.Open ("Other program") end if end loop

And then when the other window opens you can still keep the assigned values of the first window into your second window. If this is possible then please tell me how and ill do the best I can. thanks[/code]

[Tony]

it's still the same single program you are running, different windows are just for multiple output. There's nothing to it.

[DemonZ]

No, its not, its actually more than one, but when one of the menu items is pressed, the program will activate but I still want to keep the values and be able to export them and import them into other programs.
for example:
program 1

code:

var x : int x := 0 loop x := x + 1 if x = 100 then Window.Open ("Other Program") end if end loop

Now program 2 opens

code:

put x

Now the question is: if I output x in the second program, will it have the same value as in the first one?

[neufelni]

Tony wrote:

it's still the same single program you are running, different windows are just for multiple output. There's nothing to it.

I think what he is trying to do is compile different parts of his program into exe's, and then opening them in a separate window using Sys.Exec from his main menu.

I do not think that there is any way to pass variable values from one program to the other.

[Tony]

Nick wrote:

using Sys.Exec

based on his sample code, I highly doubt that.

DemonZ wrote:

will it have the same value as in the first one?

There's just one way to find out.

[DemonZ]

actually if sys.exec is what opens more than one program, than im trying to do it with that. I dont want to compile a 1000 line program because then there are going to be too many loops within loops and then youll have to make variable that will be able to exit some loops, while not exiting others, and that would be to much boolean variables, so yah Sys.Exec looks like a command Ill look into, especially since I can organize my program better and not get lost in the hundreds of lines in my program. Thanks for the advice, but I guess ill have to think of another way of passing variable values from one program to another. huh... oh well ..... back to the drawing board

[jrblast]

I guess you could pass them between one another by writing to a file, then having the other program read the file. This will create potential problems though, if the file is deleted etc...

Or, I'm not too sure how well this works because I don't have much experience with importing files, but you could import all the programs that you would otherwise use Sys.Exec for. have the whole program you import as a procedure/function (whichever suits your uses better) and then call the proc/fcn instead of opening the new program (the proc/fcn should be made to open a new window itself. May complicate things a bit, but I think it would work better

[DemonZ]

ok that just might work, ill give it a try, thanks for the support

[Dan]

I highly recomend not using the System.Exec method and using the bulit in window functions. However if you most use it, you can pass arugments between programs threw the comand line.

For example:

notepad.exe somefile.txt


Will open notepad and load the file somefile.txt beceus notepad takes arguments. Turing can also take arguments but i blive this has to be set up when you complie it to an exe in turing. If you use arugments you could pass values to the other turing exe with out having to use files.

[Clayton]

DemonZ wrote:

actually if sys.exec is what opens more than one program, than im trying to do it with that. I dont want to compile a 1000 line program because then there are going to be too many loops within loops and then youll have to make variable that will be able to exit some loops, while not exiting others, and that would be to much boolean variables, so yah Sys.Exec looks like a command Ill look into, especially since I can organize my program better and not get lost in the hundreds of lines in my program. Thanks for the advice, but I guess ill have to think of another way of passing variable values from one program to another. huh... oh well ..... back to the drawing board

or.... you could learn to better organize your code so that you don't have that dilemma, couldn't you? By the sound of it, you are running most (if not all) of your code linearly. Instead, try to branch it into different subprograms. But, basically, what I'm trying to say is, keep your code clean and organized, and you won't run into that exact problem

[DemonZ]

Now thats exactly what I did, I had it priortized with labels for different components of the program, problem is, its kind of hard to scroll down to the 700 hundredth line and then scroll all the way up, or trying to figure out how to exit this loop, and not this one, This is a basic outline of my entire program:

variables constants, and procedures, proccess on top

loop - Main game
loop - Main Menu
end loop

loop - Submenu
loop - 1 PLAYER Game Menu
loop - 1 PLAYER game
end loop
end loop
loop - 2 player game menu
loop 2 PLAYER game
end loop
end loop
end loop - SUB menu
end loop - Main game

Not only that, some of those loops are enclosed in If statements and structures, and I have to use a different screen mode for my menu than for my game, making it even more complex, plus, the game menu only flickers heavily, and not even offscreenonly can save you. And what do you propose I do about back buttons and forward buttons? I would have to make like 20 different boolean variables that would exit some loops and not exit others, and the whole entire game runs super slow, because its compiling one entire file. If you want I can post it with all the files and youll see what I mean, this program is super frustrating at 1000 lines of code, but, if I can divide these separate files up into separate programs, and then let the main menu fetch these files, that would make it so much easier. Anyway if you want I can post my entire program so you get a better view of the problem.

[ericfourfour]

DemonZ wrote:

variables constants, and procedures, proccess on top

You didn't mean to say that did you?

[[Gandalf]]

ericfourfour wrote:

DemonZ wrote:

variables constants, and procedures, proccess on top

You didn't mean to say that did you?

Actually, even though they are generally a bad solution to things, processes are still benefitial to know in the long run. As long as a differentiation is made clear between good things functions/procedures and processes, no harm is done by learning something new.

[DemonZ]

the proccess' are for music, nothing more.

[Clayton]

DemonZ wrote:

loop - Main game
loop - Main Menu
end loop

loop - Submenu
loop - 1 PLAYER Game Menu
loop - 1 PLAYER game
end loop
end loop
loop - 2 player game menu
loop 2 PLAYER game
end loop
end loop
end loop - SUB menu
end loop - Main game

perhaps you should go back to the drawing board. Planning ahead will avoid you having these problems. This is why you shouldn't be making a game in your first few months of programming...

DemonZ wrote:

this program is super frustrating at 1000 lines of code, but, if I can divide these separate files up into separate programs, and then let the main menu fetch these files,

I think you are talking about procedures here. A procedure is a sub-program, meaning you can call it and that section of code can be run again and again each time you call it (I'm sure you already know that).

DemonZ wrote:

and the whole entire game runs super slow, because its compiling one entire file

The fact that it's all one entire source file has nothing to do with the speed of the execution. Obviously you are doing something extremely unefficient if you are experiencing massive slowdowns.