in reply to Re: Win32::SysTray Issue
in thread Win32::SysTray Issue

I wondered about that myself and I think...I have not tested it yet...that Win32::GUI::Dialog is just for the systray icon menu as the one poster above was able too print to the console and run the icon menu code at the same time. However my whole program is quite console intensive as its a series of menu choices.

Replies are listed 'Best First'.
Re^3: Win32::SysTray Issue
by jcb (Parson) on Oct 18, 2020 at 02:51 UTC

    If Win32::GUI is like Tk, you may be able to run the event loop in a "forked process" (perl emulates fork using threads on Windows) while your main program continues on with the menu choices. Arranging IPC in this scenario to make the systray icon anything more than a simple reminder that the program is running is up to you.

    Try:

    $tray->runApplication unless fork;
      that works however all it does is allow the main program to work and the icon menu does not...the program does not hang up anymore. Half solved.

        That would be the first step; the rest involves setting up some kind of IPC between "parent" and "child" so that the icon menu can influence the main script's processing.

        An anonymous monk provided a better solution: simply call Win32::GUI::DoEvents­ periodically in your code. Note that this option means that the icon will be unresponsive until a DoEvents call is reached, so it does need to be called fairly often, such as on each iteration of any time-consuming loop.

        I use Tk on X11, so I am not particularly familiar with Windows GUI programming, but this seems to be similar to the type of problem I have solved in the past by forking workers and having them return results back to a main GUI process using pipes. In your case, the issue is a bit more complicated by the need for the GUI to be the side task. The *nix traditional solution would be to write an event-driven GUI wrapper for the command-line program but I do not know how well this strategy will work on Windows.