Running a compiled exe from a menu?

Blitz3D Forums/Blitz3D Beginners Area/Running a compiled exe from a menu?

Quantum(Posted 2007) [#1]
I'm pretty new to Blitz so I've just made myself a little `collect some keys, open some doors` kinda adventure game as a way of teaching myself B3D.

I've just bought Sprite Candy and I'm trying to use one of the demo `menus` supplied with it to create a menu system that will load the .EXE of my little prog... my intention being then to re-run the menu when the timer in the adventure prog expires or the player quits.

Following the graphic set-up & button definitions in Sprite Candy is a section where the user can define actions to be taken on specific button clicks... IE :-

Case "CLICK"
PlaySound Snd_Click

Select Button
Case Button1
; BUTTON ACTION GOES HERE...
Case Button2
; BUTTON ACTION GOES HERE...
End Select

Along with several other permutations I've tried:

Select Button
Case Button1
execfile("testprog.exe")
Case Button2
End
End Select

... but all that seems to happen is the menu gets reduced to the task-bar and nothing else happens? (the `quit` button work though ;) lol).

I guess this was just a long winded way of asking... How (if at all possible) do I run a Blitz compiled EXE from within a Blitz compiled EXE lol... or would I have to incorporate the entire code of my prog INTO the same EXE as the `menu` routine by calling the various parts with "Include"?... simply having it run different .EXE's would be far more flexible for what I had in mind though.

I've searched the forum & couldn't seem to find an answer, so I'm sorry if this has been explained elsewhere!

Thanks :)


Blitzplotter(Posted 2007) [#2]
I've had some luck with running compiled exe's from VB6... have you a copy of it ? Sorry, I have no experience of Sprite Candy.


Quantum(Posted 2007) [#3]
Thanks for the reply Blitzplotter... but I've never looked at VB... `Sprite Candy` is basically a series of pre-made B3D routines that take care of stuff you would usually spend ages coding... but essentially, it uses pure B3D language I think... Someone told me that they thought it was possible to do what I'm trying to do... but they couldn't remember how it was done... I've searched the command ref and the forum & I can't seem to find an answer... so it looks like I'm gonna have to try incorporating everything into a single .bb file with function calls... a shame really... cos it'll limit the versitility of my menu routine :( lol

... oh well!... nothing is ever easy lol ;)


GfK(Posted 2007) [#4]
Running different EXEs for the game and front end is an absolute no-no.

You want one executable that contains your entire game and its front-end.


Quantum(Posted 2007) [#5]
Ah!... Thanks Gfk... I'd just about come to that conclusion after 2 days of experimenting :-S... Grrr! lol

I'll start re-coding to include everything in a single .EXE now I know it can't be done the way I wanted :)

Thank you both for the advice :)


Yo! Wazzup?(Posted 2007) [#6]
try searching ExecFile() in the command reference.


GfK(Posted 2007) [#7]
That's what he's already doing - see his first post.

There are several reasons why you should never use different EXEs for the menu and game, not least of which is the ugly flicker as one app closes and the other opens. You also have to worry about passing parameters from one EXE to the other. User Account Control in Vista would go bananas as well every time you tried to open another EXE.


Quantum(Posted 2007) [#8]
Thanks folks... but I've made it all into one program file now (with some help from Zmatrix).

I've not used Vista yet Gfk... but from what you said, it looks like that just further endorses my original idea as being a bad one! lol

cheers for the input though :)


Blitzplotter(Posted 2007) [#9]
Passing parameters from one exe to another can be problematic, however it can be overcome, albeit with time.

Designing an interface within the same exe as your game is potentially the most fruitful path. Jim Brown did some good posts on this topic.


Quantum(Posted 2007) [#10]
Thanks for that Blitzplotter... I'll bear that in mind for next time :)