vistafirewallcontrol.freeforums.org

[john980]

An annoying Blocked Events balloon pops up at the lower right of my screen whenever I click on a website. It refers to the Port Scanning Prevention Filter. The balloon frequently blocks a place on the screen that I need to see or on which I need to type. Can this nuisance be turned off, or do I have to uninstall the software to get rid of it?

[VistaFirewallControl]

The balloon can be switched off in the Settigns pane. The particular events are suppressed since 4.0.200. The latest is 4.1.7

[ninveh]

In the "Edit Application" panel there is a checkbox entry "Disable Blocked Notification baloon", but there is no UI to "Apply" this setting. If I check this box and exit the panel, my selection does not "stick".
I do I disable blocked notification per application then?
I'm running V. 4.1.13

[VistaFirewallControl]

"Disable Blocked Notification balloon" option and zone are applied to application at once. So pressing “apply” sets the option to the application.

[ninveh]

1. I checked the Disable "Block Notifications" Baloon, clicked on the "Apply" in the "Apply Permissions" group - but when returning to that edit screen, the Disable "Block Notifications" Baloon was again unchecked.

2. May I humbly suggest to consider moving the "Apply" button to a general form location - not inside a specific sub group. This will then be conforming to standard UI practices.

[VistaFirewallControl]

1. Just verified 4.1.14. worked fine. No related changes were made since 4.1.13
Could you please verify
HKEY_LOCAL_MACHINE\SOFTWARE\sphinx-soft\Vista-Wall\1.0\AppList\TheApplication
NoBalloon value should reflect the applied changes.

Is the W7FC installation able to keep applied zone correctly? The zone information is stored under the same registry key.

Is the problem application dependent?
Could you please provide more details on the problem (if any). Actually the behavior is not typical.

2 the groups on the right are sorted by the use frequency.
- Quick Apply
- General apply (apply permissions from the list)
- Specific zone creating and applying
Any confirming the dialog button pressing saves the check state actually. “Cancel” does not only. Your suggestion is reasonable; however the realization would require the resorting and moving the group with less usability higher. Could you suggest a compromise?

[ninveh]

1. The registry key did not change - stayed at "0" - regardless of my changes.
However, playing a bit with this I found the bug:
a. If I modify that checkbox by editing the application when it is listed in the "Blocked Event" tabbed screen, the change does *not* hold.
b. If I modify that checkbox by editing the application when it is listed in the "Programs" tabbed screen, the change *does* hold.
If you can not reproduce, please let me know and I will provide additional details.

2. I would propose the screen layout per the attached. I did not fully understand you comment about the "Cancel", but I hope that my changes will make that screen more logical. Specifically:
- Saving space by linking the "Read" to the AV hook faq
- Moving the AV check button to where it belongs on the left, and freeing space for an global OK button that will register and apply all groups selections.

Regards.

[VistaFirewallControl]

1. Thank you. please stay tuned we will fix the problem ASAP
2. So "OK" would just duplicates "apply" ?
"apply what" is unclear and ambiguous.
Apply a zone from the zone combobox or apply the specific zone from the lowest group (it's not grayed always)?
OK would not touch "Quick apply " obviously.
Any ideas for how to make it clear?

[ninveh]

2a. Per UI standards, command buttons outside groups' regions do not specifically relate to any group, but control the whole panel (screen) - while command buttons inside a group control only the selectors inside that group. Therefore, the "Apply" in the middle group applies only to the selectors in that middle group.
However, I agree with you that the new "OK" button would be a little ambiguous: it supposes to process the two checkboxes, and also to "process" the other selections or choices on the screen - but since there are none (unless you want to change the 2 buttons in the middle group - "Apply" and "Apply Once" to radio button selectors), the user may be left wondering. But I think that this approach may be a borderline acceptable - especially if we consider the better layout proposal as in 2b below.

2b. Attached is, in my opinion, a better layout proposal: the grouping of App name/info appears more logical (the App Details text area made a bit shorter, since the displayed info is a bit superfluous), and now the "OK" button conveys a better association to the checkboxes. There is still a slight ambiguity about the duplicate use of the "OK" button in relation to the other "Apply" buttons, but without going to a majot screen redesign I can not think of a better layout.

Regards.

[VistaFirewallControl]

2a. Using radio buttons alongside of a unified “apply” is not the best idea. It would require 2 clicks instead of a single one.

2b Your layout is more “classical” definitely. However the OK functionality is foggy regardless of the check related associations. OK would confirm the checks only, without a zone? Or with a zone? If so, which zone?
The entire screen may be redesigned, there is no problems of that.
The problem is keeping the balance between UI standards/expectations, W7FC related functionality and minimal clicks required to change any application related option.
So we have no strict complete idea for how to improve the dialog unfortunately at the moment.