Jump to content
The simFlight Network Forums

ipc.setowndisplay


Recommended Posts

It seems that lua windows set with ipc.setowndisplay, stay on screen for the time that the lua script is iterating; after that the window goes. The only way to keep the window on screen is a ipc.sleep command just after ipc.linedisplay.

On the contrary, communal lua windows (set by ipc.setdisplay etc) stay on indefinitely (until closed manually by the user or the script reset).

Is there any way to keep the windows created by ipc.setowndisplay visible indefinetely, until the user closes them (right click)?

Link to comment
Share on other sites

It seems that lua windows set with ipc.setowndisplay, stay on screen for the time that the lua script is iterating; after that the window goes. The only way to keep the window on screen is a ipc.sleep command just after ipc.linedisplay.

On the contrary, communal lua windows (set by ipc.setdisplay etc) stay on indefinitely (until closed manually by the user or the script reset).

This is because there is only one communal Lua window which actually exists all throughout the session, and is simply shown or hidden by Lua actions. The "own display" is part of the Lua thread itself and cannot continue to exist when that thread no longer exists.

Is there any way to keep the windows created by ipc.setowndisplay visible indefinetely, until the user closes them (right click)?

No. The best I could do is probably to implement a new event which occures when the user closes the window. Then you could use the event to remain running, even not doing anything else but waiting for the event, till the user closes it. If this would meet your need let me know and I'll take a look.

Regards

Pete

Link to comment
Share on other sites

The "own display" is part of the Lua thread itself and cannot continue to exist when that thread no longer exists.

Just to clarify that the "own display" goes away with no ipc.exit issued; nevertheless, the script is "idle" (nothing more to do, and the events cancelled.)

The solution you propose seems that it would serve the purpose just fine, if I understand correctly (monitor this new event (as done for event.offset), and when it takes place just issue in the code an ipc.exit (or whatever) - or something along the lines).

If it can be "easily" implemented, please do.

vbr

Link to comment
Share on other sites

Just to clarify that the "own display" goes away with no ipc.exit issued; nevertheless, the script is "idle" (nothing more to do, and the events cancelled.)

The display will close when the thread is closed -- i.e. when the plug-in terminates, no matter how it does so. The thread is not closed when there are events being awaited, it is simply suspended awaiting them.

The solution you propose seems that it would serve the purpose just fine, if I understand correctly (monitor this new event (as done for event.offset), and when it takes place just issue in the code an ipc.exit (or whatever) - or something along the lines).

Yes,.

If it can be "easily" implemented, please do.

I'll have a look, but if I can't squeeze it in over the next few days I'm afraid it won't be till late January. If you don't hear from me before the end of next week, remind me after Jan 15th in case I forget (though I wil write it down in any case).

Regards

Pete

Link to comment
Share on other sites

I'll have a look, but if I can't squeeze it in over the next few days I'm afraid it won't be till late January. If you don't hear from me before the end of next week, remind me after Jan 15th in case I forget (though I wil write it down in any case).

No problem, thanks a lot for taking it over.

PS:

The thread is not closed when there are events being awaited, it is simply suspended awaiting them.

By that , I understand that if all events in a thread have been cancelled (and even if ipc.exit is not used) the thread is "closed". Is this so?

Link to comment
Share on other sites

  • 1 month later...

I'll have a look, but if I can't squeeze it in over the next few days I'm afraid it won't be till late January. If you don't hear from me before the end of next week, remind me after Jan 15th in case I forget (though I wil write it down in any case).

I've been looking at this, and it is really a complex bag of worms. To do anything with the Window I need to track down the Window handle associated with the reference FS gives me, but I've searched and searched for that and it is simply not anywhere easily reachable. I have no idea how they've implemented these Windows.

I do wish it were easy, because then maybe I could get into the ATC and other Menus and divert them to Client PCs. So I'll pursue it for that reason. But there's no solution in sight for a long time, if ever.

Regards

Pete

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.