Pausing SIm on Menu select

[DocNZ]

Im writing an application to record flight times. In every situation in which the sim is paused (pause, replay etc), my application pauses the recordings. ie when the user presses 'p', FS pauses, and by monitoring offset 0264 flag, I'll pause my applications own internal timings and recordings.

However there is one situation in which a user can"pause" the sim, but my application doesnt pick it up and will continue timing; that is when a menu item is being selected.

Ive search through the offset list, and there doesnt appear to be a flag to monitor menu selection. Ive used offset 32f0 to disable all the menus, but even "hovering' over a disabled menu item still pauses the sim, and my app will still keep recording.

Any help would be great. I would like my app to know when a user activates an FS menu, somy app can pause, then know when the user is out of the menu, so my app can resume timings.

Can FSUIPC flag this?

Or do I need to capture windows messages from FS?

[Pete Dowson]

However there is one situation in which a user can"pause" the sim, but my application doesnt pick it up and will continue timing; that is when a menu item is being selected.

...

Can FSUIPC flag this?

I don't know. I'd need to do some experiments. I'd probably need to trap a number of Windows messages. I think I can detect when a menu is being selected, but I'm not so sure I can easily or reliably detect when it is being "hovered" on.

What about other occasions when FS is effectively frozen, like grabbing its title bar and holding it (with the mouse)? And does the "pause on task switch" option show as "paused" when the user is accessing another program?

If you have some good ideas about exactly how I should do this, I don't mind adding a flag for it at all. I am planning a minor release this weekend -- to fix a problem with Button programming on PFC devices -- so if you are quick I can slip it in now!

Regards,

Pete

[Pete Dowson]

... I don't know. I'd need to do some experiments ...

For the menu stuff, after experimenting a bit with Spyxx, I think the following might work okay:

Set "in menu" flag on:

1. Seeing a WM_MENUSELECT message, or

2. Seeing a WM_NCHITTEST message which returns "HTMENU".

The latter is a little problematic, though, as I'd need to get the message processed to see the result. If there's any other subclassed or main window which wants to process this I could mess them up. But I can't see any other easy way to detect "hovering".

Maybe I process it AND pass it on. This would be a little inefficient because the Windows processing (that determines the Window and returns the HTxxxx value) would be executed twice each time the NCHITTEST occurred. But this is only when the User moves the cursor over non-client bits of the display, so I don't suppose it will be at all noticeable.

The "in menu" flag would need clearing on:

1. WM_EXITMENULOOP, or

2. WM_NCHITTEST return is not HTMENU, or

3. The flag was last set by the HITTEST and a WM_NCMOUSEMOVE is seen.

I may include this stuff in 3.202 and let you play with it. If anything else is needed it would have to go in a later update.

Regards,

Pete

[Pete Dowson]

... I don't know. I'd need to do some experiments ...

Further on this, I've run aground I'm afraid.

First off, whilst I can detect when the user merely has the mouse over the menu, this can't be what you want to know as FS is still most definitely running then. Only when a menu is selected (by ALT or mouse click) does FS actually stop.

Until a menu item is actually chosen, I can indicate quite easily the fact that FS is paused because of menu browsing. However, if he selects an item which opens a dialogue, I can trap no further messages until he closes the dialogue. The WM_EXITMENULOOP message tells me he's stopped browsing, but nothing tells me he's in a dialogue. Effectively none of my FS message-based code can run whilst FS is in a modal dialogue.

I seem to remember facing this problem before and not being able to solve it -- I needed to know when the aircraft dialogue was being accessed so that I could prevent changes to aircraft-dependent things when this may be dangerous and crash FS. I ended up doing it a different way, based on memory validity checks and so on.

So I'm not sure I can really help you after all. If you have any good ideas about this please let me know and I'll try them.

Regards,

Pete

[vdkeybus]

Isn't the simulation time or timer halted whenever the simulator stops ? Couldn't you use that to detect a frozen state ? (Like comparing with the system time.)

Jeroen.

[Pete Dowson]

Isn't the simulation time or timer halted whenever the simulator stops ? Couldn't you use that to detect a frozen state ? (Like comparing with the system time.)

Yes, the seconds counter halts, but when is is running it changes according to the sim rate. You might have to wait more than a second to see the counter change. Of course, it would be possible, it just makes things a little more complicated and may not be suitable for time-critical things (i.e. if seconds matter).

I've found that if I flag the stoppage on a WM_MENUSELECT then clear the flag on the next WM_ACTIVATE message it works across dialogue actions. It isn't foolproof -- if you open a dialogue then go activate another program and then return to FS, the WM_ACTIVATE message arrives even with the modal dialogue still open. This is about as good as I've got it so far, though.

Regards,

Pete

[DocNZ]

Pete, thanks for your prompt reply and experimentation. You've got alittle further than me. Only today did I discover the modal dialog problem, so that kinda throws another spanner in the works.

I didnt know the second timer (assuming it the $0368 one) halts because the first one certainly doesnt. I'll still work on the windows messaging technique, but I think the answer (for my application) probably lies in the second timer.

I'll experiment and return with some results. Ultimately it would be great to have an FSUIPC flag that indicates a pause in all situations. If I find a way, Pete, you'll be the first to know.

[Pete Dowson]

I didnt know the second timer (assuming it the $0368 one) halts because the first one certainly doesnt. I'll still work on the windows messaging technique, but I think the answer (for my application) probably lies in the second timer.

I don't think there is a "second timer" in FS2004. Either way neither would halt. The "timer" discussed earlier related to the time of day clock -- the seconds counter stops when FS is paused or frozen. As I mentioned, though, it takes a second at least to determine if it has stopped, and it could be a lot more if the user is running at a slow sim rate.

I'll experiment and return with some results. Ultimately it would be great to have an FSUIPC flag that indicates a pause in all situations. If I find a way, Pete, you'll be the first to know.

Well I do have a couple of other ideas which I'll try today, but then I really have to get on with other things. So if you do have anything let me know straight away. Thanks,

Regards,

Pete

[Pete Dowson]

Well I do have a couple of other ideas which I'll try today ...

I think I've reach a reasonably satisfactory method.

The menu entry detection is by WM_MENUSELECT. That covers both browsing and the subsequent selection. I am now not clearing this on WM_ACTIVATE, but only when I get the next normal frame-rate chained call from FS -- I use these in any case to synchronize critical FS changes to the frame rate. Those class stop when FS is in a dialogue.

That seems to cover everything related to menus and their resulting dialogues.

I still had the problem with modal dialogues which can occur directly, not via the Menu system. One normal example is the Save Flight dialogue when brought up by pressing ";" (or whichever key is assigned). I've dealt with that by detecting the WM_ENTERIDLE message, which seems to only occur with dialogues. Again, this is cleared when my frame rate routine is called by FS.

I'm setting different bits in the byte at offset 0x3365 for these two things -- the 1 bit for entry via MENUSELECT, the 2 bit for entry via ENTERIDLE. You'll get both with menus. The 2 bit may flicker off and on during the exit phase from a dialogue because the ENTERIDLE message occurs quite a lot and piles up.

In the end you have to look at three places - the Pause flag at 0264, the "ready to fly" flag at 3364 (only applicable to FS2004, mind), and this new byte at 3365 (which should be okay in all versions of FS).

I hope this covers your needs. Have a play with it when you get FSUIPC version 3.202 -- I should get this out later today or possible tomorrow at the latest.

Regards,

Pete

[DocNZ]

Bl***y hell Pete, absolutely brilliant!! Just what I need. I hope you get paid well for this in some form or another!! Im impressed with your dedication. I look forward to playing with 3.202.