Re: Tray plugin for Win7x64?

Bruce, what would be the difference then, if you allow pcf's for subprocesses - between subprocessing and
just using multiple instances of powerpro that run different configurations?

--- In power-pro@..., "brucexs" <brucexs <at> ...> wrote:
>
> 
> The subprocess starts from a command line call to a script, but after that it can do anything that does not
involve hot keys, mouse hooks, or any of the GUI stuff on the first couple of configure tabs.  
> 
> 
> It seems the script call could be optional too, but you'd need to think about how you would tell the new
process to do something.  It cannot have hot keys -- possibly a bar button, I guess.
> 
> There may also be some limitations to bars, I have to think through, as they do depend on having access to the
hook dll for some featuers, I think.  Active buttons would not work, for example. I need to investigate.
> 
> Also, secondary processes would not be able to write some ini files that PowerPro uses automatically, to
prevent corrupting them.
> 
> I had thought of the secondary processes as safe ways to run scripts from the main instance where your bars,
hot keys, etc are kept.  That way a broken script does not mean your PowerPro UI is gone.  You may be able to do
limited bars for user ui for the script, but tryng to split your UI across multiple processes likely won't
work.  (Menus should be no problem, as along as you have a way to show them, since no hot keys).  
> 
> I am also thinking now that secondary processes can have their pcf for convenience, although having more
than one process write into the same pcf will likely cause you grief.  In fact, it likely makes sense to
prevent pcf writing by secondary process unless explicitly asked for by cl.savepcf or writealltopcf: 
for example, PowerPro writes the pcf behind the scenes for alarms and timers and that may cause unexpected problems.
> 
> It is no problem to introduce a synonym like shutdown.process:  I'd want to stick with the main command