ipc.setowndisplay

[abax2000]

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)?

[Pete Dowson]

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

[abax2000]

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

[Pete Dowson]

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

[abax2000]

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?

[Pete Dowson]

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?

Yes, that certainly should be true, though I don't think I've tested it explicitly.

Regards

Pete

[abax2000]

thanks Pete

[Pete Dowson]

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