SOMEBODY'S a tad cranky.......
You made posts saying "hey I found the solution it's [insert HK's solution here]". I just congratulated you for finding it
Yes I noticed the FASTDOEVENTS call... a call that isn't an official vb function and you didn't post in the blurb so I could only guess as to what it was actually doing. I'm a programmer, not a mind reader. 
I'm confused; you understand what DoEvents means but not what FastDoEvents means? None of the API stuff your using is "an official vb function" so why does it matter? If your going to use API you might as well use API, afterall it's what Windows is, and VB6 "official functions" just wrap those into VB6 syntax anyway.
For the record I DID look at your code, but it never makes any sense to me. I mean I understood the exit message stuff only because I've personally used it before, but seeing as how you didn't post the definitions of the api or the constants you used, if I hadn't had been familiar with it it might as well said "magicalfunction_9" And then you throw around terms like "process the message pump" which means just that, to process the exit message call and tell me you meant doevents? Every time I've ever heard an explaination of doevents it's been referred to as "give it time to breathe" or something to that degree. It also has less to do with how readable your code is and more to do with how you go about things.
How can it not make sense when every line is commented? Process the "message pump" is standard Windows terminology while "give it time to breathe" isn't. "Message pump" is a standard windows term for a loop that processes messages in a Window. VB6 forms are just wrappers for a standard Window created using CreateWindow() API. I've never heard of "give it time to breathe" and it just sounds like something someone made up to explain something they don't understand.
This is what the API version of a message pump looks like (AKA "DoEvents" in some languages). An example message this will process is WM_CLOSE.
MSG msg;
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}The MFC way uses different syntax but you get the point. Also you can always look things up on Google if you don't understand what a term means. But as a fellow coder, I thought the code snippet would explain itself, and there was also a link to the full source code too in my post incase you missed it.
While checking for an exit message is certainly a way to do it, since waitforsingleobject is going to error out the first time you call it to a dead process anyway, you can check that way and save code and resources. It's by no means bad coding, it's actually very good, but it seems so odd to me that when you show something like that I'm so puzzled as to why you'd do it that way that I pretty much ignore the rest and in this case it was a minor thing that you didn't focus on in your explaination that would have helped and not the method you discussed.
Using GetExitCodeProcess is the better way to do it IMHO. There is nothing odd about what I showed you, what is odd is the way you explain it away.
My solution is different than yours.... it's a dumb loop with doevents which is more efficient. No call to get the exit message and then check to see if it has fired which saves prescious processes. I really appreciate your help hk but you'd have to post all your code if you want to get credit for posting a solution.
There was a link to the full source code in my post *rolls eyes*
I know a lot of people aren't concerned about the minimal amount of resources that are taken up by a loop as opposed to freezing the program all-together but I am because mame is so processor intensive. I've been aware of the warnings against using an infinate wait in vb for years but all I knew was it worked anyway and when a fe is frozen it doesn't eat up resources while a fe in a loop does.
Optimization is important, saving resources is important. But you think doing things in certain ways to save those resources is in fact doing things the wrong way. Sometimes you have to accept a few extra cycles to do things the right way.
One of the things I was and am currently worried about due to the changes I had to make to dk in particular is memory allocation. When a proggie is frozen, it's memory space is given a lower priority and thus when the system starts running out of physical memory it's the first to go to swap space. Now it'll be running though, so I'm not sure what kind of priority it'll get.
Don't quite understand your terminology here. Why are you running out of physical memory? Do you mean when you launch an external process? What you should be doing is closing the DirectX device, freeing up all your textures and closing your window and going into a low CPU usage state to wait for the program to exit. It should be looping over not "frozen". You can't use threading in VB6 so there is no other way around it.
And I do appreciate all the help guys, don't get me wrong. But the reason I brought this up wasn't really to fix my own personal code, it was to figure out why a prefectly functioning function.... THE shellandwait example upon all examples were built, has suddenly stopped working.
You could be alot more humble when people help you instead of trying to make it look like a competition. What's more offensive though is when you say "I'm right and your wrong" when it's clear to me the opposite it true. If you didn't make outrageous claims and acusations there would be no argument here.
While everyone was randomly throwing alternatives my way, which is very much appreciated but completely missing the point, I was trying to get to the root of the problem. It is waitforsingleobject with an infinate setting in conjunction with using this call on mame, regardless of the launch method that is freezing mame. Regardless of bad programming practice, ect.. it worked for years and then all of the sudden it doesn't. Nevermind though, it's not worth all this arguing and I wasn't trying to get people upset rather to have them try the code I posted and see if it feezes for them to determine it was my computer exclusively, a service pack or ect. Like I said, nm though....
I didn't think I missed the point at all. I got straight to the point and posted the solution in my first reply. I posted the code that solved the problem. I explained why there was a problem. Don't understand how you could say that??
Home
Help
Search
Login
Register
Send this topic
Print
Topic: Calling all DEVS.... ShellandWait broken? (Read 4875 times)
