RFC: RegWrite Warning

Request for Comment:

With the new builder come the opportunity to change and enhance existing behavior. I for one would like to see the amount of warnings issued to the log decrease in order to make the Warning status more meaningful. With commands like RegWrite automatically issuing a warning entry every time a key is overwritten leads to so much "white noise" it can be difficult to sort out events that actually require attention.

I see the value of having a warning present if you are trying to see if another plugin overwrites a value you set earlier, but how often is this actually a valid case in a project with hundreds of RegWrites?

Some changes to behavior that could help cleanup the logs and reduce "white noise"while still allowing for extended visibility if required.

Per-Key Opt-In Method: Submitted by Homes32
Change the default behavior of options like RegWrite to not issue a warning unless a Warn flag is issued for that key/value.To make this work project wide PEBakery would need to maintain a build-time database of key/values with Warn defined in order issue a warning when required.

Compatibility is not effected as existing behavior of plugins using the NoWarn parameter doesn't change (it just does nothing) and code need not be modified until the NoWarn parameter is depreciated. If a developer is concerned about a specific key, he can set the Warn flag to monitor it.

Global All-or-nothing Opt-out Submitted by Homes32
Leave the current behavior of logging a warning by default alone, but add a PEBakery setting to disable logging of reg overwrite.

Again compatibility is not affected. A user only needs to choose if they want to log such warnings or not.

Per-Key Opt-In with global override Submitted by Homes32
Change the default behavior of options like RegWrite to not issue a warning unless a Warn flag is specified. In addition add a global PEBakery setting to ignore this and log warnings on overwrite.

Group file/reg overwrite into a special category  Submitted by lancelot
Example

Code: [Select]

[FileOverWriteInfo]
[RegOverWriteInfo]

Throw em out! Submitted by ied206
Get rid of overwrite warnings and log them as general info or not at all.
The downside is that it could hide valuable troubleshooting information.

Logging Level's Submitted by Homes32
Implement various levels of logging containing increasing levels of information.
This could be done as a logging restriction via existing Log Debug Level setting or a log viewer filter.

Example:

• Level 1 - Normal Production
• Level 2 - Extended Logging
• Level 3 - Developer Logging
• Level 4 - Exception Logging
• Level 5 - Stack Trace

Do nothing.
Lots of warnings make me happy so "noisy" logs are fine. Leave well enough alone.

I'm interested in hearing from other developers their opinion is and whether or not the default per write opt-out warning is preferred.

Hi ied206,

Low important Requests for log 3 :

There are too many Warnings ...

When you have time, can you split some of them (and on html with Blue Info icon you use with Info ):

[FileOverWriteInfo]
[RegOverWriteInfo]

--> This is something we missed and workaround on winbuilder bad designed log .......

ps: There are other things to write about them later, I believe above 2 is enough for begining.

7. Warning Logs

There are too many Warnings ...

When you have time, can you split some of them (and on html with Blue Info icon you use with Info ):

[FileOverWriteInfo]
[RegOverWriteInfo]

Yes, there are too many file/registry overwrite warning. I am curious why they did not appear in WinBuilder 082.

There are options:
1) Do not log overwrite as warning.
2) Fix System,ErrorOff in PEBakery and add lots of them to plugins to prevent overwrite warning.
3) Group overwrite warning to special category, like [FileOverWriteInfo] and [RegOverWriteInfo].

I am tempted to do option 1, but it can hide potential error, any ideas?

Thanks ied206,
 

*

Yes, there are too many file/registry overwrite warning. I am curious why they did not appear in WinBuilder 082.

Because we could not update closed source winbuilder to give only info for
[FileOverWriteInfo]
[RegOverWriteInfo]
we update design bug of winbuilder with System,ErrorOff

Code: [Select]

IniRead,%ProjectDir%\script.project,IniVariables,NoWarnRegOverWrite,%NoWarnROW%
...
If,%NoWarnROW%,Equal,True,System,ERROROFF

IniRead,%ProjectDir%\script.project,IniVariables,NoWarnRegOverWrite,%NoWarnROW%
..
If,%NoWarnROW%,Equal,True,System,ERROROFF,4

If you want to see warnings on winbuilder build:
SE\Main Configuration -> Advanced -> Click buttons:
NoWarnRegOverWrite
NoWarnFileOverWrite
--> buttons will appear "unchecked" , than make your build.

This will create MANY warnings on wb log, which is VERY scary for Normal Users.
Keep in mind, Normal Users never use Compilers that produce warnings. 

Than we update old plugins that really use System,ErrorOff with other ways.

So shortly :
System,ErrorOff not required on PEBakery, only improvments on Log is enough. 
It will be time saver for PEBakery development.



==> Above also replies to your question:

There are options:
1) Do not log overwrite as warning.
2) Fix System,ErrorOff in PEBakery and add lots of them to plugins to prevent overwrite warning.
3) Group overwrite warning to special category, like [FileOverWriteInfo] and [RegOverWriteInfo].

I am tempted to do option 1, but it can hide potential error, any ideas?

3) solves troubles. 

-->

1) log provides special info for overwrites
but do not put log as warning, put log as info :
[FileOverWriteInfo]
[RegOverWriteInfo]

2) with [FileOverWriteInfo] [RegOverWriteInfo] -> System,ErrorOff will not be required.
( when found can be updated with other ways)



*

PS)
Starting from next release, let's seperate release news thread and bug thread.

I agree,
open a topic at:
http://theoven.org/index.php?board=38.0
Topic Subject:
PEBakery Release

After open topic, You will notice "Lock Topic" and "Set Topic Sticky" buttons at the bottom of your new topic.

<====>
This is ChrisR  way on SE Release topics.   
<====>


******
More later.....

Logging Level's Submitted by Homes32
Implement various levels of logging containing increasing levels of information.
This could be done as a logging restriction via existing Log Debug Level setting or a log viewer filter.

Example:

• Level 1 - Normal Production
• Level 2 - Extended Logging
• Level 3 - Developer Logging
• Level 4 - Exception Logging
• Level 5 - Stack Trace

Wow, I like this idea.
We can add more levels like this:
- Level 1 : Do not log overwrite warning
- Level 2 : Group overwrite warning into [FileOverWriteInfo], [RegOverWriteInfo]
- Level 3 : Log overwrite as warning (current model)

I hope we can talk more about grouping, and which level grouping should go.

I hope we can talk more about grouping, and which level grouping should go.

Instead of level grouping, you can provide options for Log, so anyone create personal level by setting options.
ex:
a) enable/disable [FileOverWriteInfo]
b) enable/disable [RegOverWriteInfo]
c) + Do not log plugin option ex: MacroLibray
d) + Do not export plugin option ex: MacroLibray
etc.

I would enable a and b, disable c, and enable d for projects.



If that is the road map :

Let us have syntax or option .... for projects so we can set default log level or log behaviour of builder via plugin or whatever

-->
wb have .ini file to store configurations.
When end users play debug level options of builder (so far useless anyway) we shortly say them use default projects and extract zip again.
 ( no need to spend valuable time which levels or options of debug option end user play with)


*
Having default single log behaviour providing all required info is enough for batch projects when log organized nicely.
proof: we never need to ask end users to change log settings and provide a new log.


PEBakery providing different log behaviour options is fine, but I hope this do not waste your valuable time.

In the end we will use only 1 set of log options all the time without changing others.

Instead of level grouping, you can provide options for Log, so anyone create personal level by setting options.
ex:
a) enable/disable [FileOverWriteInfo]
b) enable/disable [RegOverWriteInfo]
c) + Do not log plugin option ex: MacroLibray
d) + Do not export plugin option ex: MacroLibray
etc.

Something like filters in the log view (that could be saved as profiles and easily toggled between) would combine the best of both these ideas I think

Something like sysinternals likes to use.


The warnings/commands/actions could be grouped and the groups included/excluded by filter and/or stringMatch.

full logs are always generated so project supporters don't have to be concerned with getting users to change settings, or changing the settings for them without their approval, however the extended filtering capabilities would clean up the log and let you focus on what was important to you.

I added experimental log type Overwrite.
FileCopy/RegWrite will produce [Overwrite] logs instead of [Warning] logs, reducing number of Warning logs.
I chose this method because the modification could be done in shortest time.

Inspect attached log export for more actual implementation.

Thanks ied206,

something we wait 8 - 10 years now, I hope we will not need to workaround anymore. 

*
Reply 133 : http://theoven.org/index.php?topic=2271.msg24965#msg24965

When you have time, can you split some of them (and on html with Blue Info icon you use with Info ):

I like to see Blue info etc. icon (other than current [Info] icon) (not red not yellow) to avoid end users start to report things.
 Think about impression "Overwrite" having "Red icon"
->
 Think about impression "Overwrite" having "Blue icon" will give better impression it is normal than Red saying "something to alert"