After "Restore defaults", settings seem to be saved even after canceling

Started by Scott, November 04, 2008, 10:04:26 AM

Previous topic - Next topic

Scott

Installed PL 3.20 to see how it would work for me.  Found a non-serious but slightly annoying bug straight off:

I have custom ProBalance settings in place.  Having installed a new version, I wanted to see what the defaults were (as I know they sometimes change).  I went into ProBalance settings, clicked "Restore defaults", and then intended to cancel my changes.  I clicked Cancel, of course.  I was prompted "Save settings?", to which I clicked No.

But after going back into the settings, they appeared to still be set to the defaults.

Fortunately, I was monitoring the INI file, and noted that it had not changed.  Closing and reopening the PL GUI is what was required to view my actual ProBalance settings.  In other words, the GUI kept showing that the defaults were in effect, when they were not.  The Cancel worked, but the GUI didn't seem to know it.

Hopefully that made sense.  I'm of no mind for quality writing at the moment.

Jeremy Collake

Thanks for the report. I'll issue a fix for this soon. If you notice anything else, just let me know.
Software Engineer. Bitsum LLC.

Scott

Thanks.  I'm still seeing the issue of firefox.exe being stuck at priority class 6.

Jeremy Collake

Quote from: heterodox on November 05, 2008, 01:36:52 PM
Thanks.  I'm still seeing the issue of firefox.exe being stuck at priority class 6.

I have a debug build, if you like I can provide it to you and we can see what exactly Process Lasso is doing, or not doing. I think this is the only way to get to the bottom of the problem.
Software Engineer. Bitsum LLC.

Jeremy Collake

The issue with aborted changes to ProBalance parameters reappearing when that dialog is reopened is fixed in v3.21 beta 1.
Software Engineer. Bitsum LLC.

Scott

Thanks.  I've sent an email to support at bitsum d0t c0m regarding the debug build.

Scott

I found out the hard way that ProcessLasso.exe needs to be running in order for debug info to be caught.

I normally do not run the GUI.

One day lost.

Jeremy Collake

Hmm... it shouldn't need to be running, both processes emit their debug info separately using the Windows API. Regardless, there is no rush.

Thanks
Software Engineer. Bitsum LLC.

Scott

When I had only ProcessGoverner.exe running, the only entries ever logged by DebugView had to do with the system tray:

QuoteShowing Balloon Text
systray window not found.

Jeremy Collake

I'll check things out, I may need to issue another debug build to fix that.
Software Engineer. Bitsum LLC.

Scott

I let it run for a day with both EXEs running.  Nothing pertinent was ever logged in DebugView.  There were other entries besides the two I show above, but nothing that seemed important.

I gave up and installed the regular version, and excluded Firefox.exe from restraint.

Jeremy Collake

Ok, thanks. I'll work on improving the debug output in the future here. The governor may not have been emitting full debug output, according to your report. I actually had checked this before-hand, but perhaps it got packaged wrong. Alternatively, perhaps there is some other reason you aren't seeing the debug output. So much to do..
Software Engineer. Bitsum LLC.

Scott

Thanks.  If you create a new debug build, and you remember, please shoot me an email.  I'm just asking--no hurry.