Brilliant! Thanks very much!!

Hello, Is it possible to hide a bar when in fullscreen, and have it reappear when not in fullscreen? I currently have a bar that shows using *Format context when Microsoft Edge is active screen, but would like it to not be there when playing a  fullscreen youtube video within Edge.

You can do that like shown below

*Format contextif activewindow("=msedge") and win.fullscreen() == 0

Hello, Is it possible to hide a bar when in fullscreen, and have it reappear when not in fullscreen? I currently have a bar that shows using *Format context when Microsoft Edge is active screen, but would like it to not be there when playing a  fullscreen youtube video within Edge.

Thanks for any help!
Glenn

On Tue, Jun 28, 2022 at 08:27 AM, BruceS wrote:

I think this is something that the user, not the plugin, should control.  Of of course you could always override by runcmd'ing the exec but you would not be able to restore old setting.  What are your thoughts?.  

My goal inside the plugin is to be able to get status of runcmd or evalExpr to mark command as successful or not on error. I do not want to get more than this currently. 

I use the console to get global variable from powerpro do math, call script and watch some expression flag ... 
Consider it like a scratchpad for everyday interaction with PP.

I think it could be useful also for other who like powerpro and want to watch or run script from dedicated command line.  
 

Thinking a bit more about this,  I realized that I had already implemented non-setting of undeclared variables as part of script debug.  So I should be able to do this in general after all.  iI think I will be able to upload an experimental  version in a day or two,   It will have an exec command to set the flag.

I think this is something that the user, not the plugin, should control.  Of of course you could always override by runcmd'ing the exec but you would not be able to restore old setting.  What are your thoughts?.

As you say it is adding complexity to enable hook, adding line to the CL or using a script...
Currently i can quickly erase and  check _lasterror_ and for what i want to achieve it is enough for me. In worse case i will just not get the right status of runCmd but is is still better than nothing. I do not need much more and can accept inside console plugin. (The idea was to not save or provide failing code in history ).

I added better handling for sub process in single ini and some minor bug fix.. I should provide an update next week.

Just to be clearer, you'd have to create the hookerror cl with cl commands through runcmd or by by running a configure import to import it from a file you include with your plugin.  It would call a console plugin service with lasterror value.

However, thinking more about it.  I'm not sure if that will work, as ppro would only normally look for this hook list at startup or reconfigure.  If you want to pursue, I could add a pprservice to reset hook lists.

Probably overkill for what you need.

 if no other script arise in the middle. as error message wait for user response before returning.

I have not checked it since it was built, but perhaps the HookError hook will do what you need since I think it will be called for each error (and you can check _lasterror_ there).  


For better or worse, setting an undeclared variable was by design, maybe to prevent duplicate errors if it was undeclared (not misspelled).  As I mentioned in previous post, the code is buried deep in expression and other processing, and I don't want to change.

As you advised, set/check _lasterror_ do the trick if no other script arise in the middle. as error message wait for user response before returning.

About variable, if I evaluate or run with an unknown variable the variable is created anyway (I gave a look on allglobals)
EvalExpr("NotKnown" ,szTmp)   show a popup message but the variable is created anyway and it return TRUE. fortunately _lasterror_ is populated 

_lasterror_ = Variable used before being declared

notknown

On Mon, Jun 27, 2022 at 09:05 AM, BruceS wrote:

EvalExpr is supposed to return a BOOL;

It returns whether or not cancel running scripts was pressed for errors in scripts (the assumption was that plugins would be called from scripts...).  

I had a quick look.  I don't think I can make any changes to this code -- it is buried too deep in other code and I don't know what side effects would result from changing (too much work to debug and test to find out).
Sorry, RunCmd cannot return an error.

EvalExpr is supposed to return a BOOL; is it not working for you?  What are you passing when the issue occurs and what does evalexpr return.

Possible workarounds:
- check for changes to allglobals built in.
- before running cmd or expr, set _lasterror_ to "", then check it after running cmd
Search for onerror in help, topic "error handling",  for more info and other possibilities.

I'm trying to update my ppConsole plugin but i face some issues about getting errors.
Is it possible to retrieve error when executing PProServices->RunCmd and returning FALSE from EvalExpr if any message pops up.

I have issues when running bad expression and i'm not able to get error.

I have  the option to not use undeclared variable. If i enter one, i get a popup, evaluation is stopped but in most case the variable is created anyway.

I will explore that approach. Thanks.

If you won't want to use a child process pcf command list for pproshutdown, then I think another approach would be to create the command list dynamically with cl plugin in your initialization.  It could consist of single line to runfile an existing script file for example.

Thanks for this extra detail.  The bug was easy to find with it.  I'll fix in next experimental version.

Here is the background detail, which also relates to your open notes on shutdown concerns.
Ppro assumes that if a note is open (visible) at shutdown, then it should be visible the next time ppro starts.  So open notes are stored in open subfolder and any updates to the note apply to that copy.  If note is closed, it is moved to its category subfolder.  At startup, main PPro process always executes a Note Open command which shows all notes still in open subfolder.

Now when a child process is used, PPro assumes that it is using same notes subfolder as main process. So to avoid showing notes twice, for a child process the startup Note Open command is NOT executed; this is documented in the help. (I don't think it is possible for ppro to check on what note subfolder might be set since the note open is running as part of startup processing)

Now the bug.  The initialization code for note memory is run by the first Note Command that is run.  It is NOT run by the plugin note.open, only by the Note commands (eg the one you implement with Do workaround).  But since the main process always does a Note Open command at startup, the initialization is run there, so you can run plugin note.open from main process without issues.

But for child processes, there is no Note Open command run at startup, so the initialization is not done, and the plugin note.open corrupts memory, leading to issues you see.  The fix is to do the initialization for notes in child processes as part of startup and not wait for first note command.

deinit support added to the procsess.create function.

Sorry, I don't plan to do this.  As, Christophe says, pproshutdown command list was meant to do this.  

For instance, if one creates a Note in the initialization script and during the life of the process that Note is edited, it will be necessary to close that note before the process is shutdown or the changes to the note will be los

Is the changed note in the open subfolder of your notes folder for that process?  That is what happens in my very simple test of creating a note under a child process and then shutting down the process from command and menu of right-cltrl click a bar.   
There is the also checkbox on Notes configuration tab of advanced dialog to automatically close and save the note in its category folder (instead of the open folder) if the note is open on ppro shutdown.
See my response to your note,open bug for more background detail.

As you say, many ways to kill a cat... and the solution I am working on prohibits editing of the pcf file. Thus my use of script files. All that aside, I would still like to see  deinit support added to the procsess.create function.

To isolate the secondary process, this is how i do.

• I create a new folder with my secondary pcf (pictured as isolated) inside curent pprofolder then create process like
• process.create("debug","isolated\\debug.pcf") 
  • If isolated is inside current pprofolder, you can use this as base if not you can use a full path.
  • for the secondary process, base pprofolder will be the path of the pcf file !
  • I do not use ini command as all is already defined in my pcf in the startup event from the scheduller.
  • since 38d, You can define also an isolated\plugins folder just call exec.setPluginFolder(pprofolder++"\\plugins") in startup
• The shutdown mechanism can be defined in the pproShutdown command list. 
  • Also about note, the note plugin receive a shutdown message and can probably save changes automatically. If you use a dedicated folder you will not mix main process notes and isolated ones.
  • let say you want to call a deinit.powerpro during shutdown
    • place deinit.powerpro inside isolated\script folder 
    • inside your init script you define a global variable like global onClose = ".deinit" 
    • in your pproshutdown command list you call do( onClose ) deinit should be called 

Having the ability to call a command or a script is nice but this does not add any isolation as you can define all you want inside pcf and dedicated and isolated script. if you want to share variable in init and shutdown , you can create a single script with @init and @deinit functions. 
AS usual you have many way to do your stuff and powerpro helps you every day to make your life easier !
I use debug to not crash main process, and other processes to call/receive WM_copydata with other programs with separated scripts folders. 

I will have to experiment with that but I am motivated to wonder why the existing secondary process creation function, i.e.,

hProc = process.create(name, config.pcf, init_command, running_flag)

has that "init_command" argument. I assumed this was to provide an opportunity to fully isolate a secondary process from other Powerpro/main process dependencies. I could be wrong about that and it really is just extraneous. If it is used, however, it may require some follow-up deinitialization.

For instance, if one creates a Note in the initialization script and during the life of the process that Note is edited, it will be necessary to close that note before the process is shutdown or the changes to the note will be lost. I do not see how that can be done from the functions you have mentioned. However, I may be wrong and will give it some thought. At this point I am using a deinit.powerpro script and calling it with

process.Call("procname", "deinit.powerpro")

which uses

shutdown(shutdown.process)

to do the process termination.

That works well so I my suggestion is exactly that: just a suggestion. I think it would make coding the secondary process flow a bit more intuitive and maybe remove a line of code or two.

On startup, you can use scheduller with startup event. (no close event)
But you can define yourself a PProShutdown command list in your secondarry process pcf. 
This should meet your expectation.

it is call by direct close/shutdown and also when the main process quit.
you can also do some exception look in the help for restartinp powerpro