Thread: Run programs on hibernate/suspend and resume!

Originally Posted by evandude

Thanks for the info. I am not nearly as much of a programmer as either him or you, but I'll ask him about it.

I recall he said he found a way to send a message back to windows to abort the shutdown, however he said it just caused windows to send back another shutdown message to the program, but with a "force" flag set this time to forcibly kill it. Not sure if this is the same thing you suggested, or something different. As I said, I'm not a programmer

You're right! Stupid Microsoft. It just ignores me. They must have done that to keep us from stopping a virus from shutting down the PC every 20 seconds. I haven't found anything on MSDN about it not working, so it must have been a recent patch.

I think a better option would be to not use the power button and do it with a software shutdown like the serial port one. Then you have lots of time.

justintime, it looks like this program is about halfway to your specs. dividing it into different apps launched on different shutdown methods, and intercepting the shutdown seems like the only things left to go.

however... I really think your app is better suited to a different input method as curiosity said. especially if the actual shutdown/hibernate/standby is going to be done in the script anyway... in which case it doesn't matter HOW the script is triggered, and triggering it from the windows shutdown stuff seems like a big hassle. if you use serial input or some other method, you can have as much shutdown time as you want without windows even realizing what's going on until the script was all done and told windows to shut down.

evandude:

It does matter how the script is triggered... the idea is that when you shutdown your car, your OPUS will trigger a shutdiwn sequebce (or hibernate or whatever you have it set up to do), and at that point, you would want to run a few things before the sequence actually initiates.

Get it? That's why it needs to be tied to the hardware shutdown... that's all the OPUS knows what to do!

that would be very easy to get around. instead of hooking the power button wires to the mobo header, hook them to another small board. from that board, run wires to the mobo header for the power button, and to the serial port (or whatever other input method you chose)

If the computer was off, the board would deliver the power on pulse to the mobo header. if it was on, it would instead deliver the pulse to the serial port/etc. It could be as simple as a handful of discrete components.

True, doing it entirely in software would save you from having to build anything or do any wiring. However, it does not appear so far that cancelling a windows shutdown is very easy. If someone manages to figure out how to do it, then your program wouldn't be hard to adapt from this one. But if nobody can figure out how to do it, then you should at least be aware that a simple hardware adaptation is another feasible way to get it done.

Evndude... it *can* be done. I already found a software that does it, but it is not freeware, and what's worse, it eats up 3MB of RAM!e pot #14 of my other thread, here:
Utility to change behavior of ATX power button (e.g.: launch an app)

Originally Posted by evandude

that would be very easy to get around. instead of hooking the power button wires to the mobo header, hook them to another small board. from that board, run wires to the mobo header for the power button, and to the serial port (or whatever other input method you chose)

If the computer was off, the board would deliver the power on pulse to the mobo header. if it was on, it would instead deliver the pulse to the serial port/etc. It could be as simple as a handful of discrete components.

True, doing it entirely in software would save you from having to build anything or do any wiring. However, it does not appear so far that cancelling a windows shutdown is very easy. If someone manages to figure out how to do it, then your program wouldn't be hard to adapt from this one. But if nobody can figure out how to do it, then you should at least be aware that a simple hardware adaptation is another feasible way to get it done.

Well then we just need to have the programmers figure out HOW to do it and we'll be set

I've been testing this Hibernate Trigger utility to disable my GPS using Devcon, and re-enabling it upon resume (also using Devcon).

It didn't help a bit. Not Hibernate Trigger's fault... it's just that disabling/enabling the GPS does not really help resolve the issue that iGuidance has when hibernating. Oh well, back to the drawing board!

Does the GPS have to be shut off or disconnected to get it to work again, or can you just restart iGuidance to get it working?