End one program and start another

Blitz3D Forums/Blitz3D Beginners Area/End one program and start another

IcyDefiance

(Posted 2009) [#1]

OK, my programming experience from other languages is starting to kick in with this one, and I'm starting on a few more complicated things. I'm in the middle of programming an automatic updater for that FPS I'm working on, and I have a simple problem that's making it hard for me to update the main executable.

For reasons that will take too long to go through in this post, I need to be able to end one program (usually accomplished by just using the End command) and start another (usually accomplished with the ExecFile() command). The problem is that ExecFile() pauses the program until the file that is executed ends, so if I put ExecFile() then End, the program doesn't close until the other one does. If I put End first, then it never gets to the ExecFile() command.

The best solution I have so far is to make the update manager a separate file from the main executable so I don't have to restart the main exe when it's updated. I can clear the graphics mode and all variables to save the RAM and the average user would never know the difference. But the program would still be dormant in the background, which would simply be annoying, and what happens when I want to update the update manager? I would have to just end the program and have the user restart it manually. Again, not a huge deal, but it's certainly an annoyance.

I'm willing to use a DLL or something if I need it, but there really should be a simple solution that I haven't seen yet.

Amanda Dearheart

(Posted 2009) [#2]

I don't understand much of Blitz3d commands, but many languages have a system that can handle Window Messages. In the days of DOS, we called them Dos Interrupts or TSR (Terminate and stay Resident) programs. What you can do is place a function in a code block that checks to see if the execfile statement was executed, and if so end the program, like this piece of pseudocode

Begin Window Message

void function that handles Execfile check

end Window Message

function that handles Execfile check

if (execfile == 0 )
end
end function

Its just an idea. I don't even know if Blitz3d has a system that supports just such a command. Perhaps you might be able to acheive just such an result through the .dll as you have said!

Yasha

(Posted 2009) [#3]

ExecFile() pauses the program until the file that is executed ends

Intriguing. Have you tested this thoroughly? Because on my system, it seems to fire-and-forget, and the parent program ends as expected.

In any case, Mikhail's FastLibs (www.fastlibs.com) do include an explicit ExecOnEnd (not sure if that's the exact name) function. Although this might not be in the free one.

RifRaf

(Posted 2009) [#4]

yes execfile will halt your program, use this api call

Decls


.lib "Shell32.dll"

ShellExecuteA(hwnd%,op$,file$,params$,dir$,showcmd%)

when your game is ready to launch another exe and end you call it like this

; at the top of your program you have to record the window handle

Global hwnd%=SystemProperty("apphwnd")

;later when you are executing another program just call

ShellExecuteA(hwnd%,"open","whatever.Exe","","",1)

edit : the last parameter indicates how the new window will behave. 1 and 9 bring it to top and max size, 0 hides it.. even from the process window. 2-8 do stuff too but I forgot what.

IcyDefiance

(Posted 2009) [#5]

@Amanda: Something like that would probably work, but like I said, the ExecFile() command pauses the entire program. My code looks like this:

ExecFile("fps.exe")
End

It executes the file, but doesn't end.

@Yasha: Very strange... Yeah, I've tested this thoroughly, and it does it every time. I can't even start to offer an explanation for that. And I looked up that FastLibs thing, but I really don't want to use another block of another person's code if I don't have to. Keeping track of 3 different licenses and trying to stay within their boundaries is tough enough, I don't even want to look at another one. I would use it if I had to, but RifRaf had a better idea.

@RifRaf: Thank you so much, that works perfectly. I'll have to figure out what all those numbers do, maybe I could use them to have a bit more fun, but that'll come later. Anyway, now my update manager works just about perfectly, and I'll be posting a download link on my worklog sometime soon. I just have to do a little more bugtesting with it first...